1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
|
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (X11; I; SunOS 5.5.1 sun4u) [Netscape]">
<TITLE>TAO Release Information and TODO List</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
<!-- $Id$ -->
<CENTER>
<HR></CENTER>
<CENTER>
<H3>
Release Information for The ACE ORB (TAO)</H3></CENTER>
Information is available on the following topics related to the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/VERSION">current
release</A> of <A HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</A>:
<UL>
<LI>
<A HREF="orbcore.html">ORB & ORB Core</A></LI>
<LI>
<A HREF="#idl">IDL Compiler</A></LI>
<LI>
<A HREF="ec.html">Event Channel</A></LI>
<LI>
<A HREF="#apps">Test & Example Applications</A></LI>
<LI>
<A HREF="#poa">Portable Object Adapter</A></LI>
<LI>
<A HREF="#nservices">CORBA Naming Service</A></LI>
<LI>
<A HREF="#tservices">CORBA Trader Service</A></LI>
<LI>
<A HREF="#pservices">CORBA Property Service</A></LI>
<LI>
<A HREF="#cservices">CORBA Concurrency Control Service</A></LI>
<LI>
<A HREF="#av">CORBA Audio/Video Control Service</A></LI>
<LI>
<A HREF="#ace">ORB-related ACE Changes</A></LI>
<LI>
<A HREF="#dove">The DOVE Demo</A></LI>
<LI>
<A HREF="#vc">How to add IDL files into your Visual C++ projects</A></LI>
</UL>
<!--#include virtual="orbcore.html" -->
<HR>
<H3>
<A NAME="idl"></A>IDL Compiler</H3>
Point of contact: <A HREF="mailto:gokhale@cs.wustl.edu">Aniruddha Gokhale</A>
<P>Current status: (As of March 15th, 1998.)
<UL>
<LI>
Completely redesigned the IDL compiler using the Visitor patterns. Many
incomplete issues have been resolved. These include support for "sequence
of typecodes", passing object references as in, inout, and out parameters.
Code generation for sequences is also properly handled i.e., for a named
sequence such as "typedef sequence <char>CharSeq;", we now generate
a new class (and hence a type) called "class CharSeq". Arrays are still
being worked out and will be done soon. An important difference in the
generated code is that the skeletons now use a table driven approach very
similar to the stubs.</LI>
<LI>
Support for the "native" keyword added.</LI>
<LI>
Introduced tests for object references to TAO. Still incomplete.</LI>
<LI>
Param_Test example is able to test string sequences, fixed structs, variable
sized structs and nested structs</LI>
<LI>
Param_Test test suite can now test fixed structs and string sequences.This
needed bug fixes to TAO ORB core.</LI>
<LI>
A new test to test all the parameter passing modes for a number of data
types has been added. At this point in time, it tests primitive types and
strings. Other tests will be added. Bugs discovered thru these tests have
been fixed.</LI>
<LI>
Very preliminary support for arrays. Not working yet.</LI>
<LI>
Many bugs associated with stub generation fixed. This included support
for return values that are variable sized IDL types. Unions improved.</LI>
<LI>
Support for sequences of strings and object references added. However,
it is not tested yet so there may be some bugs. We should have these fixed
in a day or so.</LI>
<LI>
Support for handling exceptions added. TAO does not use direct C++ exceptions.
Instead it uses the CORBA::Environment based approach.</LI>
<LI>
Sequences as out parameters have been tested in the IDL_Cubit example.
A test suite is currently being built to test all the parameter passing
modes on a variety of IDL data types.</LI>
<LI>
Support for attributes completed. Not tested yet.</LI>
<LI>
The problem of incorrect code generation for typedefs defined in an imported
file is resolved.</LI>
<LI>
Problems when interfaces use single or multiple inheritance solved. The
problem was with the demultiplexing code, the generated operation tables,
and the dispatching mechanism. We are currently testing this with the Event
Channel code.</LI>
<LI>
The problems arising due to public virtual inheritance when casting from
an interface class to CORBA::Object_ptr has been solved. We do this casting
inside the stubs/skeletons rather than first converting an interface class
pointer to a void*, storing it in an Any, and casting it to CORBA::Object_ptr
in the encode/decode methods. The casting inside the stubs/skeletons work
because the compiler has knowledge of both types.</LI>
<LI>
The compiler generates correct code for COSS Naming service and it runs
properly. Correct code also gets generated for the Event Channel program</LI>
<LI>
Include files are handled properly. So are the definitions used inside
the include files that are used in the currently parsed files.</LI>
<LI>
IN, INOUT, and OUT object reference parameters are now supported properly.
We think the same approach should work for sequences, structs, and unions.</LI>
<LI>
Many IDL constructs supported including primitive types, typedefs, sequences,
structures, and unions.</LI>
<LI>
Generates C++ stubs and skeletons that use TAO's <A HREF="http://www.cs.wustl.edu/~schmidt/HICSS-97.ps.gz">interpretive
IIOP protocol engine</A>.</LI>
<LI>
Generated code closely follows the C++ Mapping specified in the POA Specification
(ORBOS/97-05-15).</LI>
<LI>
Support dynamic libraries on NT, i.e., marking classes for DLL export was
added. Two backend options control the name of the export macro, and the
name of an extra include file were the macro is defined; the options are
<TT>-Wp,export_macro=MACRO_NAME</TT> <TT>-Wp,export_include=INCLUDE_NAME</TT>.</LI>
</UL>
Known bugs/unimplemented constructs:
<UL>
<LI>
Generation of Managed types must somehow be moved to the ORB Core</LI>
<LI>
We need support for ``TIEs'' (i.e., the object form of the Adapter pattern).</LI>
<LI>
TypeCode generation for multidimensional arrays and indirected typecodes
is still a problem.</LI>
<LI>
Unions with default cases yet to be handled</LI>
<LI>
The <<= and >>= operators for user-defined types are not generated
yet.</LI>
<LI>
Deal with names in the IDL definition that are C++ keywords.</LI>
<LI>
IDL is case-insensitive. However, it looks like our front-end is case-sensitive.
Thanks to Anil Gopinath (anil@ittc.ukans.edu) for pointing this out.</LI>
<LI>
tao_idl generates code for a *.idl file only inside the directory where
the *.idl resides. However, it may be required to generate code elsewhere
i.e., in the directory where the compiler was invoked. Thanks to Tom Richards
(tomr@MCMEnterprise.com) for this suggestion.</LI>
</UL>
Future work:
<UL>
<LI>
Need to relocate the various libraries used by the IDL compiler out of
the ACE directory. Having them here can cause problems when working with
multiple versions of TAO and a single version of ACE.</LI>
<LI>
Improve IDL compiler to generate compiled form of stubs/skeletons.</LI>
<LI>
Fix bugs in the SunSoft IDL front-end we've uncovered. These primarily
include support for Unions.</LI>
<LI>
Add command line options to TAO IDL. These options will decide what strategy
to use for operation name demultiplexing. Another option may decide whether
to use the interpretive IIOP engine or generate compiled stubs/skeletons.</LI>
<LI>
Use <A HREF="http://www.cs.utah.edu/projects/flux/flick/">Flick</A> (from
the University of Utah) to generate compiled stubs.</LI>
<P>Goal is to measure the code size of the interpretive stubs generated
by TAO IDL compiler <I>vs</I> code size of compiled stubs. Then compare
the performance of each. We want to prove the thesis that TAO IDL compiler
generated interpretive stubs have a small code size, yet are comparable
in performance (or slightly less) than compiled stubs. Hence, it will be
useful for small distributed equipment such as handsets, PDAs, etc.
<P>In doing the above, improvements to the IIOP protocol engine in terms
of size/performance/determinism will be made.
<LI>
Tweak the IDL compiler to generate code that's more easily integrated back
into the ORB Core, e.g., POA, etc. This will depend largely on our ability
to generalize the changes necessary to generated code.</LI>
</UL>
<HR><!--#include virtual="ec.html" -->
<HR>
<H3>
<A NAME="apps"></A>Test & Example Applications</H3>
Point of contact: <A HREF="mailto:naga@cs.wustl.edu">Nagarajan Surendran</A>
<P>Current Status:
<P>The TAO IDL_Cubit test application makes use of the Naming Service and
the server holds a TAO_Naming_Server component.Just running server and
client is enough to test the application.
<P>The various tests in the tests/POA test the different features of the
Portable Object Adapter interface like Explicit Activation, On Demand Activation,etc..
<P>Future work:
<P>Developing a one-buttoned test for all the different TAO tests similar
to the ACE-one buttoned test.
<P>MT_Cubit:
<P>Current status:
<P>The TAO MT_Cubit test application is meant to serve as a starting point
for real-time tests on the TAO system. It comprises the following parts:
<UL>
<LI>
<I>Server.</I> The server creates multiple CORBA objects (servants), each
with different real-time priorities. This priority is implemented by using
real-time thread support provided by the operating system. Thus, requests
sent to a high-priority servant are handled by a high-priority real-time
thread, and those sent to a lower priority servant are handled by correspondingly
lower priority threads.</LI>
<LI>
<I>Client.</I> The client component binds to the servants, and sends a
stream of CORBA requests to the servants. It measures the response time,
i.e. the time taken for the request to complete successfully. In particular,
it measures the time taken for requests sent to the high priority servant
to complete. The volume of lower priority requests is configurable. The
client is thus able to measure the performance of the high-priority servant
in the presence of competition from several lower-priority servants.</LI>
</UL>
Clearly, if the ORB endsystem handles the priorities of the various requests
correctly, increasing the volume of lower priority requests should not
affect the performance seen by the higher priority requests. The application
thus serves as a tool to measure and confirm this behavior.
<P>Future work:
<UL>
<LI>
Study the impacts of scheduling & concurrency strategies on performance.</LI>
<LI>
Evolve into a testbed for discovering sources of performance non-determinism
& priority inversion.</LI>
</UL>
<HR>
<H3>
<A NAME="poa"></A>Portable Object Adapter</H3>
Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A>
<P>Current Status:
<UL>
<LI>
The POA mostly complete. There are remaining pieces to be implemented,
but much of the POA framework exists. This section will carry updates as
available.</LI>
</UL>
Known issues:
<DL>
<DT>
<I>Support for collocation is not complete.</I></DT>
<DD>
If an object which should be collocated is created via <TT>string_to_object</TT>,
it is created as a remote object rather than collocated.</DD>
<DT>
<I>The stubs and skeletons are not needed.</I></DT>
<DD>
The library includes stubs and skeletons for the Portable Server interfaces,
since all this interfaces have locality constraints the stubs and skeletons
are effectively dead code and should be removed.</DD>
</DL>
Critical work:
<UL>
<LI>
None.</LI>
</UL>
Future work:
<UL>
<LI>
Determine the degree to which we will support the full semantics of remote
objects on a collocated object. The spec mandates that collocated object
should behave <I>exactly</I> like remote objects, but that means that request
will have to be queued rather than calling a method directly, and this
could be hazardous to our quest for real-time ORB status.</LI>
<LI>
Provide extensions of the specification to ensure real-time delivery of
messages.</LI>
</UL>
<HR>
<H3>
<A NAME="nservices"></A>CORBA Naming Service</H3>
Point of contact: <A HREF="mailto:sergio@cs.wustl.edu">Sergio Flores-Gaitan</A>
and <A HREF="mailto:marina@cs.wustl.edu">Marina Spivak</A>
<P>Current status (as of Feb 27th):
<UL>
<LI>
The Naming Service implementation is complete.</LI>
</UL>
Future work:
<UL>
<LI>
Currently the bindings are stored as a table in memory. Future work will
include a persistent database to store the bindings.</LI>
<LI>
Replication of the bindings to other Naming Service's currently running.
It will probably be modeled after the LDAP Multi-Master Replication Protocol.
For more information on this replication protocol please read <A HREF="ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-02.txt">LDAP
Multi-Master Replication Protocol</A></LI>
</UL>
For general documentation on the Naming Service please read <A HREF="ftp://www.omg.org/pub/docs/formal/97-07-12.pdf">The
Naming Service Specification</A>.
<P>
<HR>
<H3>
<A NAME="tservices"></A>CORBA Trading Service</H3>
Point of contact: <A HREF="mailto:sbw1@cs.wustl.edu">Seth Widoff</A>
<p>
Development is complete, and testing and debugging have commenced on
the TAO Trading Service. Currently, it
meets the Linked Trader conformance requirements, in that it supports
the Lookup, Register, Admin, and Link interfaces. The Lookup interface supports
subtype searching, preference sorting, dynamic property evaluation, federated queries,
and concurrent queries as a multi-threaded servant.
<p>
The Trading Service uses the Object Space implementation of the Standard
Template Library.
<p>
Future Work: <p>
<ul>
<li> The Proxy Interface.
<li> Persistent storage of service types and offers.
</ul>
<P>For general documentation of the Trading Service, please read <A HREF="http://www.omg.org/corba/sectrans.htm#trader">The
Trading Service Specification.</A>
<P>
<HR>
<H3>
<A NAME="pservices"></A>CORBA Property Service</H3>
Point of contact: <A HREF="mailto:alex@cs.wustl.edu">Alexander Babu Arulanthu</A>
<P>Current status (as of Mar 19, 1998)
<BR>
<BR> It is under development and testing. TAO's
AVStreams, which is currently being developed will make use of the
Property Service. The primary PropertySet interface
and the Iterator interfaces have been implemented and currently AVStreams'
test application has started using them.
<P>For general documentation of the Property Service, please read <A HREF="http://www.omg.org/corba/sectrans.htm#prop">The
Property Service Specification.</A>
<P>
<HR>
<H3>
<A NAME="cservices"></A>CORBA Concurrency Control Service</H3>
Point of contact: <A HREF="mailto:tworm@cs.wustl.edu">Torben Worm</A>
<P>Current status (as of March 19th):
<UL>
<LI>The service is currently under development. The parts depending
on the Transaction Service, are not implemented in the first version
</UL>
<P>Future Work:
<UL>
<LI>Implementation of the Transaction Service dependent parts
</UL>
<P>For general documentation of the Concurrency Control Service, please read <A HREF="http://www.omg.org/corba/sectrans.htm#concur">The
Concurrency Control Service Specification.</A>
<P>
<HR>
<H3><A NAME="av"></A>CORBA Audio/Video Control Service</H3>
Point of contact: <A HREF="mailto:sumedh@cs.wustl.edu">Sumedh
Mungee</a> and <A HREF="mailto:naga@cs.wustl.edu">Nagarajan
Surendran</a> <p>
This is an implementation of the OMG spec addressing the <a
href=http://www.cs.wustl.edu/~sumedh/research/corbaav.pdf>Control and
Management of Audio/Video Streams</a>. <p>
We are currently implementing the various interfaces defined in the
above spec. We are also working on building a audio/video streaming
demo that will use the above service as the control mechanism and JAWS
as an efficient transport and protocol processing framework. <p>
Current Status: <p>
<ul>
<li> Implemented the handshake mechanism between the consumer and
supplier of the stream.
<li> Implemented a simple version of the stream controller
(StreamCtrl).
<li> Implemented the VDev and StreamEndPoint base class
functionality.
<li> Implemented the MMDevice interface, which is a factory for
StreamEndPoint and VDev objects.
</ul>
Work in progress: <p>
<ul>
<li> Implementing the SFP protocol
<li> Porting the distributed audio/video player developed at <a
href=http://www.cse.ogi.edu/~scen/Player>OGI</a> to ACE (and in the
future to JAWS)
<li> Implementing the CORBA Stream controller for the above
audio/video player
</ul>
<HR>
<H3>
<A NAME="ace"></A>ORB-related ACE Changes</H3>
Points of contact: <A HREF="mailto:cleeland@cs.wustl.edu">Chris Cleeland</A>
and <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyrarli</A>
<P>Recently Completed Work:
<UL>
<LI>
Added special declaration to OS.h for <TT>inet_ntoa</TT> and other functions
because VxWorks doesn't provide full argument prototypes for these library
functions.</LI>
<LI>
The current caching connector behaves properly in the face of a non-blocking
connect request. The "fix" is simply to not support non-blocking connects
through the cache. When the <TT>connect()</TT> fails with <TT>EWOULDBLOCK</TT>,
morph the error to -1 and clean up the request.</LI>
<LI>
Service handlers obtained from the caching connector are now cleaned up.
The application needs to be able to signal that it's not using it any longer,
and, when the application encounters an error, needs to effectively close
down that connection for good so that a new connection can be initiated.</LI>
<BR>Added the ability for a Svc_Handler to recycle itself. idle() can be
called when the Svc_Handler is done serving a particular connection and
can how be recycled. The Svc_Handler now also has a pointer to a recycler
that is responsible for managing the connections. The recycler is usually
a Cached_Connector.
<BR>Added new class ACE_Recycling_Strategy. It defines the interface (and
default implementation) for specifying a recycling strategy for a Svc_Handler.
This strategy acts as a consular to the Svc_Handler, preparing it for the
tough times ahead when the Svc_Handler will be recycled.
<BR>Added new class ACE_NOOP_Concurrency_Strategy. It implements a no-op
activation strategy in order to avoid calling open on a recycled svc_handler
multiple times.
<BR>ACE_Cached_Connect_Strategy now implements the ACE_Connection_Recycling_Strategy
interface. This allows Svc_Handlers to cache themselves with ACE_Cached_Connect_Strategy
when they become idle. It also allows them to purge themselves from the
connection cache when the Svc_Handlers close down.
<BR>Also added ~ACE_Cached_Connect_Strategy that will cleanup up the connection
cache.</UL>
Future work:
<BLOCKQUOTE><I>None currently scheduled.</I></BLOCKQUOTE>
<HR>
<H3>
<A NAME="dove"></A>The DOVE Demo</H3>
Point of contact: <A HREF="mailto:mk1@cec.wustl.edu">Michael Kircher</A>.
<P>
DOVE is described in detail on the following site:
<A HREF="http://www.cs.wustl.edu/~schmidt/dove.html">DOVE documentation</A>
<P>
We focus on the following goals at the moment:
<UL>
<LI>
Have a DOVE Browser running using Java Beans as vizualization components
<LI>
Have the Event Channel as DOVE Agent running with an Event Consumer
in the DOVE Browser.
<LI>
Having a MIB which dumps all events transfered on the Event Channel
into a file on persistent storage for later reuse. (Not implemented yet)
</LI>
</UL>
<P>
Two demos are available right now:
<UL>
<LI>
One using a fixed set of visualization components and the
Event Channel as DOVE Agent.
<LI>
A new demo using independent visualization components (Java Beans)
and the Event Channel as DOVE Agent. Connections can be established
between monitored metrics and the visualization components.
</LI>
</UL>
<P>
In the concept of the new demo we have three major components:
Observables (monitored metrics), Observers (a Java Bean
for displaying the metric) and a DataHandler (for demultiplexing the
monitored metrics to the appropriate Observables).
Each component inherits from a base class, so that a certain behavior
of the components can be assured for each component. Relationships
between components are based on these base classes.
<P>
The used Java Beans are required to conform to some standards, as
they have to support a function called "getProperty" which allows
the DOVE Browser to determine if the vizualization capabilities of
a specific Java Bean are sufficient to display the metric.
A JavaBean is for example a Java Panel which shows a Graph of
the delivered doubles. So all metrics can be displayed by this visualization
component which can be expressed by a single double.
<P>
The DataHandler is connected to the Event Push Consumer (PUSH, because
we use the push concept of the Event Service). The Event Push Consumer
does not know what kind of data is transported. The only component
knowing all the details about the dependencies of the metrics is
the DataHandler. This separation allows easy extension and change
of the demo.
<P>
<A HREF="http://students.cec.wustl.edu/~mk1/dove.html">Object Diagrams</A>
are available about this new concept.
<P>
Future work includes:
<UL>
<LI>
Having the DOVE demo properly running on NT
<LI>
Add MIB functionality
</LI>
</UL>
<P>
<HR>
<H3>
<A NAME="#VC"></A>How to add IDL files into your Visual C++ projects</H3>
Point of contact: <A HREF="mailto:nw1@cs.wustl.edu">Nanbor Wang</A>.
<P>Each IDL file generates .h, .i and .cpp files. Here is an example of
adding an IDL file named foobar.idl into a VC project.
<OL>
<LI>
Create/open the workspace. Create server project and client project if
you haven't had them ready. Add the IDL file <foobar.idl> and other
non-IDL generated files into both client and server projects.</LI>
<LI>
Added foobarC.h, foobarC.i, foobarC.cpp, foobarS.h, foobarS.i, and foobarS.cpp
into the server project and foobarC.h, foobarC.i, and foobarC.cpp into
the client project.</LI>
<LI>
Now open the project setting window (Project -> Setting... or just press
Alt-F7.) Select the IDL files in both client and server projects. Choose
to set the setting for "All Configuration." Make sure the "Exclude from
build" under the "General" tab is unchecked.</LI>
<LI>
Click on the "Custom Build" tab. Add this entry as the build command for
IDL files:</LI>
<PRE>..\..\..\TAO_IDL\tao_idl $(InputName).idl</PRE>
Notice that your absolute path to TAO_IDL may vary.
<LI>
Now add the following entries as "Output file(s)."</LI>
<PRE> $(InputName)S.h
$(InputName)S.i
$(InputName)S.cpp
$(InputName)C.h
$(InputName)C.i
$(InputName)C.cpp</PRE>
Add only one entry in each line.
<LI>
We are all set. Click OK.</LI>
<LI>
Add foobarC.cpp to client project and foobarC.cpp and foobarS.cpp to server
project.</LI>
</OL>
Notice that these procedures only setup the IDL compiler to perform correctly.
<P>p.s. If anyone knows how to set a default setting in VC so we don't
need to perform these procedures every time a new project gets set up,
please let us know. Thanks.
<P>
<HR>
<P>Back to the TAO <A HREF="../index.html">documentation index</A>. <!--#include virtual="/~schmidt/cgi-sig.html" -->
</BODY>
</HTML>
|
