![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rpcread.me CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [WindowsNT SDKs] / mstools / samples / rpc|
Return to rpcread.me CVS log | Up to [WindowsNT SDKs] / mstools / samples / rpc |
1.1 root 1: More Information about Microsoft RPC version 1.0
2: ____________________________________________________________
3:
4: This document contains important information about Microsoft RPC version
5: 1.0 that is not included in the Microsoft RPC Programmer's Guide and
6: Reference or in help.
7:
8: Using Notepad to View This Document
9:
10: To move through this document, press PAGE UP and PAGE DOWN or click the
11: arrows at the top and bottom of the scroll bar along the right side of
12: the window.
13:
14: To print this document, choose the Print command from the File menu.
15:
16: For help on using Notepad, press F1.
17:
18: ____________________________________________________________
19:
20: Introduction
21:
22: Microsoft RPC version 1.0 is a toolkit for developing network-aware
23: distributed applications in C/C++. The RPC toolkit includes:
24:
25: o MIDL compilers for Microsoft Windows NT and MS-DOS
26:
27: o C/C++ language header files (.H) and run-time libraries
28: (.LIB and .DLL) for Microsoft Windows NT, Microsoft
29: Windows, and MS-DOS
30:
31: o Sample programs for Microsoft Windows NT, Microsoft
32: Windows, Microsoft Windows for Workgroups, and MS-DOS
33:
34: o RPC reference Help files and PostScript(TM) files
35:
36: The Microsoft Windows NT SDK contains the Microsoft Windows NT and
37: Microsoft Windows 3.x/MS-DOS versions of the RPC SDK.
38:
39: Installation
40:
41: The Microsoft Windows NT SDK installs the components of the Microsoft
42: Windows NT RPC SDK as part of its standard installation. No additional
43: installation is required.
44:
45: To develop client-side distributed applications for MS-DOS, Microsoft
46: Windows 3.x, and Windows for Workgroups version 3.1, you must install
47: the Microsoft Windows 3.x/MS-DOS version of the RPC toolkit. Cross-
48: compilation of Windows 3.x and MS-DOS clients on Windows NT requires a
49: 16-bit C compiler in the Microsoft Windows NT environment. This
50: development environment is not installed during RPC SDK setup. The
51: Microsoft RPC SDK for MS-DOS and Microsoft Windows requires:
52:
53: o Microsoft C/C++ version 7.0
54:
55: o DOS protected-mode interface (DPMI) server that
56: supports version 0.9 or later of the DPMI specification and
57: the MS-DOS extensions to the DPMI (Microsoft Windows or
58: Windows for Workgroups versions 3.1)
59:
60: o Either Microsoft Windows for Workgroups version 3.1 or
61: Microsoft LAN Manager version 2.1 with NetBEUI, Named Pipes,
62: or TCP/IP
63:
64: To install the Microsoft Windows and MS-DOS version of the RPC toolkit,
65: run the Setup program in the directory MSTOOLS\ RPC_DOS\NSETUP. To start
66: the Setup program, choose the Run command from the File menu in the
67: Microsoft Windows 3.x Program Manager
68:
69: When you install the RPC SDK in a directory different from the directory
70: you used for Microsoft C/C++ version 7.0, you must set the environment
71: variables INCLUDE, LIB, and PATH to point to the directories that
72: contain the RPC header files, libraries, and DLLs and binaries,
73: respectively. When you install the RPC SDK in the same directory as the
74: directory you used for Microsoft C/C++ version 7.0, these environment
75: variables are already set by the C/C++ version 7.0 installation program.
76:
77: RPC Documentation
78:
79: The following Microsoft RPC version 1.0 reference materials are
80: available in published book form and in PostScript file format:
81:
82: Microsoft RPC Programmer's Guide and Reference
83: Part I: Programmer's Guide
84: Part II: Run-time API Reference
85: Part III: MIDL Language Reference
86:
87: Use the PostScript files to print individual chapters of the
88: documentation on your PostScript printer.
89:
90: The following run-time and MIDL reference Help files are available on
91: line:
92:
93: RPC10WH.HLP WinHelp run-time API reference
94: RPC10QH.HLP QuickHelp run-time API reference
95: MIDL10WH.HLP WinHelp MIDL reference
96: MIDL10QH.HLP QuickHelp MIDL reference
97:
98: RPC sample-program source files are available in the directory
99: MSTOOLS\SAMPLES\RPC. MS-DOS and Microsoft Windows versions of some
100: samples are available when you install the MS-DOS and Microsoft Windows
101: 3.x version of the RPC SDK. You must compile the client samples on the
102: client computer. The file MSTOOLS\SAMPLES\RPC\README.TXT describes each
103: sample.
104:
105: ____________________________________________________________
106:
107: Contents
108:
109: These release notes contain additional information on the following
110: topics:
111:
112: 1.0 DCE interoperability issues
113:
114: 2.0 Gateway required for DCE NSI API interoperability
115:
116: 3.0 Using Microsoft RPC with Microsoft Windows for Workgroups
117:
118: 4.0 Packing and alignment considerations
119:
120: 5.0 MIDL switch "-env generic" not supported
121:
122: 6.0 C stub source code causes compilation warnings
123:
124: 7.0 Updated command line help for the MIDL compiler
125:
126: 8.0 Creating installation disks for your application
127:
128: 9.0 Running the locator and endpoint mapper
129:
130: 10.0 Updating RPC registry entries for new NetBIOS configurations
131:
132: 11.0 Support for multiple locators
133:
134: 12.0 NetBIOS requires larger MS-DOS application stack
135:
136: 13.0 Using the new C _stdcall calling convention with RPC
137:
138: 14.0 RpcWinSetYieldInfo not supported for Win32 applications
139:
140: 15.0 Uuidgen utility provided for Microsoft Windows NT
141:
142: 16.0 Use NULL security descriptor with RpcUseAllProtseqs
143:
144: 17.0 Leading zeroes in version numbers do not create unique values
145:
146: 18.0 Const initialization
147:
148: 19.0 Include three header files in your distributed applications
149:
150: 20.0 Context handle issues
151:
152: 21.0 Only one error_status_t parameter allowed
153:
154: 22.0 Unsized arrays issues
155:
156: 23.0 Separate in, out parameters to avoid memory orphaning
157:
158: 24.0 Small model application development not supported
159:
160: 25.0 Single process cannot be client, server using NetBIOS
161:
162: 26.0 Escape sequences not correct in the generated header files
163:
164: 27.0 Ncalrpc transport issues
165:
166: 28.0 RpcNsBindingExport requires non-null interface parameter
167:
168: 29.0 Configuring RPC name service for LAN Manager networks
169:
170: 30.0 Length_is applied to pointer causes error
171: ____________________________________________________________
172:
173: 1.0 DCE interoperability issues
174:
175: The Microsoft RPC endpoint mapper and run-time libraries are compatible
176: with the DCE endpoint mapper interface.
177:
178: When you use the DCE Cell Directory Service, you must use a gateway to
179: the DCE server (see release note 2.0).
180:
181: Full pointers (pointers associated with the attribute [ptr]) are not
182: completely implemented in Microsoft RPC version 1.0. To allow
183: portability of DCE applications, the MIDL compiler treats full pointers
184: as unique pointers, which means that aliasing is not supported. The use
185: of full pointers that cause aliasing can lead to undefined results.
186:
187: DCE host names are case-sensitive. Specify the hostname exactly as it
188: appears or the client will not be able to locate the host server.
189:
190: In DCE-compatibility mode, the MIDL compiler provided with this beta
191: release of Microsoft RPC version 1.0 incorrectly accepts handles in
192: positions other than the first parameter. The MIDL compiler in DCE-
193: compatibility mode incorrectly does not accept BOOLEAN as a switch type.
194:
195: This beta release does not support the name service environment variable
196: RPC_DEFAULT_ENTRY_NAME, but it does provide an alternate method to
197: specify the default syntax. Microsoft RPC configuration settings are
198: available in the Microsoft Windows NT registry and in the MS-DOS and
199: Microsoft Windows 3.x file RPCREG.DAT. To change the default syntax, set
200: the registry entry SOFTWARE\Microsoft\Rpc\NameService\DefaultSyntax.
201:
202: Other differences between the Microsoft and DCE implementations are
203: documented in the RPC Programmer's Guide and Reference.
204:
205: 2.0 Gateway required for DCE NSI API interoperability
206:
207: When using Microsoft RPC version 1.0 for Microsoft Windows in an OSF DCE
208: environment, the DCE Cell Directory Service (CDS) is used as the RPC
209: name service. However, the OSF has not yet released a specification of
210: the protocol used to access the CDS. To allow interoperation between DCE
211: computers and RPC client applications that call RPC name service API
212: functions, you must use a gateway to the DCE CDS.
213:
214: To help you develop such a gateway, the Microsoft RPC SDK provides an
215: interface for a gateway protocol in the files SAMPLES\NS\CDS\NSICLT.IDL,
216: NSSVR.IDL, and NSICOM.IDL, and provides the client-side implementation
217: of this gateway protocol in RPCNS.DLL. One such implementation of the
218: server side gateway is currently available in the Digital Equipment
219: Corporation DCE Starter Kit.
220:
221: To use the gateway so that your RPC application can interoperate with
222: DCE RPC applications:
223:
224: 1) Verify that the gateway is started on the DCE host
225:
226: 2) Verify that the client is running the TCP/IP transport
227:
228: 3) (Microsoft Windows NT only) Set the registry entry
229: Software\Microsoft\Rpc\NameService\ServerNetworkAddress to a string of
230: the form "<ip address of gateway 1>; <ip address of gateway 2>...",
231: where <ip address of gateway n> is the ip address of the nth gateway in
232: the list.
233:
234: 4) Set the following registry entries under Software\
235: Microsoft\Rpc\NameService to the following values:
236:
237: Entry Value
238:
239: Protocol ncacn_ip_tcp
240: NetworkAddress <ip addr gateway 1>; <ip addr gateway 2>...
241: Endpoint <empty string>
242:
243: To change registry entry settings on Microsoft Windows NT, use the
244: REGEDIT utility. On MS-DOS and Microsoft Windows, edit the text file
245: RPCREG.DAT.
246:
247: 3.0 Using Microsoft RPC with Microsoft Windows for Workgroups
248:
249: To successfully run Microsoft RPC distributed applications with
250: Microsoft Windows for Workgroups version 3.1, you must use the Windows
251: for Workgroups network services. Stop all real-mode network services
252: before starting Windows for Workgroups. At the MS-DOS prompt, enter:
253:
254: net stop workstation /y
255: win
256:
257: 4.0 Packing and Alignment Considerations
258:
259: You must use the same packing and alignment settings (/Zp switch) with
260: both the C compiler and the MIDL compiler. Using different packing
261: levels for each compiler causes undefined results. Default values are
262: set for each target operating system. You can specify the /Zp switch to
263: verify that the correct packing and alignment settings are used on both
264: compilers.
265:
266: For Microsoft Windows 3.x and MS-DOS-based distributed applications, use
267: one of the following two methods:
268:
269: a. Compile using /Zp2 with both the MIDL and C compilers
270:
271: b. Compile using any /Zp level (use the same level for both the MIDL
272: and C compilers; the level /Zp4 produces the most efficient marshalling
273: code) and add the following code to the files RPC.H and RPCNDR.H:
274:
275: #pragma pack(2) /* at start of rpc.h and rpcndr.h */
276: ...
277: #pragma pack () /* at end, restore default level */
278:
279: 5.0 MIDL switch "-env generic" not supported
280:
281: The MIDL compiler environment switch "-env generic" is not supported in
282: this version. When your target operating system is the same as the
283: development environment, you do not have to specify an environment
284: switch; the default settings are correct. Otherwise, use the specific
285: environment switch that corresponds to your target application
286: environment: "-env win32", "-env win16", or "-env dos".
287:
288: The MIDL compiler can generate C code for other platforms when you use
289: these switches. However, to cross-compile the C code for other
290: platforms, you must configure your C development environment. For
291: example, to cross-compile MS-DOS applications on a Microsoft Windows NT
292: computer, you must set up your computer to use a 16-bit C compiler,
293: include the correct header files, and link with the appropriate
294: libraries. A development environment that supports MS-DOS cross-
295: compilation is not provided during Microsoft Windows NT installation.
296:
297: 6.0 C Stub Source Code Causes Compilation Warnings
298:
299: The stub files generated by the MIDL compiler may generate warnings when
300: they are compiled at compiler warning level 3 and higher. These warnings
301: can generally be safely ignored.
302:
303: Unsigned character string arguments generate "incompatible pointer
304: assignment warnings" when you compile the stubs. The C run-time library
305: functions use char * arguments rather than unsigned char * arguments.
306:
307: When your C compiler does not use the same default character sign as the
308: MIDL compiler, use the MIDL compiler switch /char to generated explicit
309: declarations in the generated file. For more information, see the Microsoft
310: RPC Programmer's Guide and Reference.
311:
312: Compiler warning messages about unreferenced local variables, mismatched
313: comparisons between integral types, and mismatched pointer assignments
314: in stubs can be safely ignored.
315:
316: 7.0 Updated command line help
317:
318: The updated help text for the MIDL compiler appears as follows:
319:
320: -MIDL COMPILER OPTIONS-
321: -MODE-
322: /ms_ext Microsoft extensions mode
323: /app_config Application configuration mode
324: /implicit_local Assume non-remote data is [local]
325:
326: -INPUT-
327: /acf filename Specify the attribute configuration file
328: /I directory Specify directory for import and include files
329: /import ms_ext Support only used types; one file
330: /import ms_nt Support only used types; multiple files
331: /import osf Assume imported IDL files are compiled separately
332: /no_def_idir Ignore the current and the INCLUDE directories
333:
334: -OUTPUT FILE GENERATION-
335: /client all Generate client stub and aux files
336: /client aux Generate client auxiliary file only
337: /client none Generate no client files
338: /client stub Generate client stub file only
339: /out directory Destination directory for output files
340: /server all Generate server stub and aux files
341: /server aux Generate server aux file only
342: /server none Generate no server files
343: /server stub Generate server stub file only
344: /syntax_check Check syntax only; do not generate output files
345: /Zs Check syntax only; do not generate output files
346:
347: -OUTPUT FILE NAMES-
348: /caux filename Specify client auxiliary file name
349: /cstub filename Specify client stub file name
350: /cswtch filename Specify switch stub file name
351: /header filename Specify header file name
352: /saux filename Specify server auxiliary file name
353: /sstub filename Specify server stub file name
354:
355: -C COMPILER AND PREPROCESSOR OPTIONS-
356: /cpp_cmd cmd_line Specify name of C preprocessor
357: /cpp_opt options Specify additional C preprocessor options
358: /D name[=def] Pass #define name, optional value to C preprocessor
359: /no_cpp Turn off the C preprocessing option
360: /U name Remove any previous definition (undefine)
361:
362: -ENVIRONMENT-
363: /char signed C compiler default char is signed
364: /char unsigned C compiler default char is unsigned
365: /char ascii7 Char values limited to 0-127
366: /env dos MS-DOS client
367: /env win16 Microsoft Windows 16-bit (Win 3.x)
368: /env win32 Microsoft Windows 32-bit (NT)
369: /env generic Produce one header for all environments
370:
371: -ERROR AND WARNING MESSAGES-
372: /error all Check for all types of errors
373: /error allocation Check for out of memory errors
374: /error enum Check for errors converting long, short enum
375: /no_warn Suppress compiler warning messages
376: /W{0|1|2|3|4} Warning level 0-4 (default = 1)
377: /warn{0|1|2|3|4} Warning level 0-4 (default = 1)
378: /WX Treat all warnings as errors
379:
380: -OPTIMIZATION-
381: /pack {1|2|4|8} Designate packing level of structures
382: /Zp{1|2|4|8} Designate packing level of structures
383:
384: -MISCELLANEOUS-
385: @response_file Accept input from a response file
386: /? List MIDL compiler switch settings
387: /confirm Display options without compiling MIDL source
388: /help Display a list of MIDL compiler switches
389: /prefix "s1" "s2" Replace default suffix "s1" with prefix "s2"
390:
391: 8.0 Creating installation disks for your application
392:
393: Your distributed application's installation program must set up the RPC
394: runtime for users. Two batch files help you create RPC run-time
395: installation disks that can accompany your distributed application.
396: These batch files create installation disks that contain the Setup
397: program and the Microsoft RPC run-time libraries, allowing you to
398: distribute the Microsoft RPC run-time libraries with your distributed
399: application. The following two batch files are provided:
400:
401: wrundisk.bat creates Microsoft Windows/MS-DOS run-time install disk
402: drundisk.bat creates MS-DOS-only run-time install disk
403:
404: 8.1 Creating installation disks for Microsoft Windows applications
405:
406: Insert a formatted, blank floppy disk in the destination drive. Start
407: the installation disk utility by typing "wrundisk" followed by the
408: optional source and destination drive names. The wrundisk.bat file uses
409: the following syntax:
410:
411: wrundisk [source:[path] [dest:]]
412:
413: where
414:
415: source is a disk or directory that contains the compressed files that
416: are provided in the Microsoft Windows NT SDK directory
417: \mstools\rpc_dos\disk1.
418:
419: dest is a drive name specifying the drive that contains the formatted,
420: blank floppy disk.
421:
422: For example,"wrundisk c:\nt\mstools\rpc_dos\disk1 a:" copies the
423: compressed files to the floppy disk in the drive A.
424:
425: Your application user can then insert the resulting installation disk in
426: her computer's floppy drive and run its Setup from Microsoft Windows to
427: install the RPC run-time libraries for Microsoft Windows and MS-DOS.
428:
429: 8.2 Installation disks for MS-DOS Distributed Applications
430:
431: The drundisk utility copies files from an installed RPC SDK. To ensure
432: that all MS-DOS loadable transports are present on the run-time
433: installation disk, you must select all loadable transports at the time
434: you install the Microsoft RPC SDK.
435:
436: Insert a formatted, blank floppy disk in the destination drive. Start
437: the installation utility by typing "drundisk" followed by the optional
438: source and destination drive names. The drundisk.bat file uses the
439: following syntax:
440:
441: drundisk [directory [dest:]]
442:
443: where directory is the name of the directory that contains all loadable
444: transport (.RPC) files and all name service dynamic link libraries.
445:
446: For example, the command "drundisk c:\lanman.dos\netprog a:" copies the
447: MS-DOS run-time libraries, the loadable transport files, and name
448: service DLLs from the C hard drive to the floppy disk in drive A. Your
449: application user can then use the Setup program on the run-time
450: installation disk to install the RPC run-time libraries.
451:
452: 9.0 Running the locator and endpoint mapper
453:
454: In this release of Microsoft RPC version 1.0, the locator and endpoint
455: mapper are not provided as services but as programs that you must start
456: from the Microsoft Windows NT command line. The locator is the Microsoft
457: implementation of the RPC name service independent API functions (NSI).
458: The endpoint mapper allows the use of dynamic endpoints.
459:
460: Start the locator using the following command syntax:
461:
462: locator /noservice
463:
464: Start the endpoint mapper on the RPC server using the following syntax:
465:
466: rpcss noservice
467:
468: Start the locator and endpoint mapper before starting the server
469: application.
470:
471: Note: These services are not complete in this beta release of Microsoft
472: RPC version 1.0. The endpoint mapper does not support dynamic endpoints
473: for the TCP/IP transport on MIPS computers and does not support dynamic
474: endpoints for NetBIOS transports. The locator service does not start
475: automatically in this beta release. In a LAN Manager network
476: environment, you must start the locator service on the primary domain
477: controller and on each RPC server. For more information about
478: configuring the RPC Name Service, see release notes 2.0 and 29.0.
479:
480: 10.0 Updating RPC registry entries for new NetBIOS configurations
481:
482: The Microsoft RPC Setup program automatically maps protocol strings to
483: NetBIOS lana numbers and writes these settings in the registry. These
484: mappings work as long as you only have one network card and one network
485: protocol. If this is not the case, or if you change your network
486: configuration after installing Microsoft RPC, you must update the
487: registry to indicate the new correspondences between protocol strings
488: and NetBIOS lana numbers.
489:
490: For Microsoft Windows NT, the mapping string appears in the registry
491: tree under \Software\Microsoft\Rpc\NetBios. For MS-DOS, the mapping
492: string appears in the registry file RPCREG.DAT.
493:
494: The mapping string uses the following syntax:
495:
496: ncacn_nb_<protocol><digit> = <lana_number>
497:
498: where
499:
500: <protocol> indicates the protocol type. For MS-DOS, the valid <protocol>
501: value is "nb". For Microsoft Windows NT, valid <protocol> values are as
502: follows:
503:
504: <protocol> Protocol type
505:
506: xns XNS
507: nb NetBEUI
508: tcpip TCP/IP
509:
510: <digit> indicates a unique digit associated with each instance of a
511: protocol. Use the value 0 for the first instance of a protocol and use
512: the next consecutive digit for each additional instance of that
513: protocol. For example, assign the value ncacn_nb_nb0 to the first
514: NetBEUI entry; assign the value ncacn_nb_nb1 to the second NetBEUI
515: entry.
516:
517: <lana_number> indicates the NetBIOS lana number. A unique lana number is
518: associated with each network adapter present in the computer. For LAN
519: Manager networks, the lana numbers for each network card are available
520: in the configuration files LANMAN.INI and PROTOCOL.INI. For more
521: information about the lana number, see your network documentation.
522:
523: For example, the following mapping string describes a configuration that
524: uses the NetBEUI protocol over an adapter card that is assigned lana
525: number 0:
526:
527: ncacn_nb_nb0=0
528:
529: When you install a second card that supports both XNS and NetBEUI
530: protocols, the mapping strings appear as follows:
531:
532: ncacn_nb_nb0=0
533: ncacn_nb_nb1=1
534: ncacn_nb_xns0=2
535:
536: 11.0 Support for multiple locators
537:
538: This release supports cooperation among multiple locators when the
539: primary locator is an i386 computer. Each locator passes its request to
540: the computer specified in the registry entry
541: "SOFTWARE\Microsoft\Rpc\NameService\NetworkAddress". The default value
542: for this registry entry specifies the primary domain controller as the
543: primary locator.
544:
545: For more information about the locator, see release notes 2.0 and 29.0.
546:
547: 12.0 NetBIOS requires larger MS-DOS application stack
548:
549: The NetBIOS transport provided with this release of Microsoft RPC
550: version 1.0 for MS-DOS requires a 4K stack. You can set a 4K stack for
551: your applications with the linker option "/stack:4096" or with the
552: exehdr utility.
553:
554: The link /stack option that sets the size of the stack to 4K is as
555: follows:
556:
557: link /stack:0x1000
558:
559: The exehdr utility uses the following syntax:
560:
561: exehdr /stack:0x1000 appname
562:
563: where
564:
565: appname is the name of your application. For example, to set the
566: required NetBIOS stack size for the helloc.exe sample program, enter the
567: command:
568:
569: exehdr /stack:0x1000 helloc.exe
570:
571: See your Microsoft C/C++ version 7.0 documentation for more information
572: about these options.
573:
574: 13.0 Using the new C _stdcall calling convention with RPC
575:
576: Microsoft Win32 API functions (including the Microsoft RPC API
577: functions) are defined using the C language keyword _stdcall. This
578: keyword specifies a calling convention in which arguments are pushed
579: onto the stack in the same order as the C language calling convention,
580: but the called function (rather than the caller) pops the arguments.
581:
582: Functions defined with _stdcall cannot use a variable number of
583: arguments. The new C calling convention is also applied when you use the
584: C compiler switch /Gz.
585:
586: The old C language calling convention is specified using the C language
587: keyword _cdecl or the C compiler switch /Gd.
588:
589: When your application combines old C and new C calling conventions, you
590: must take care to specify the correct function prototypes, C compiler
591: switches, and linker options for these calling conventions.
592:
593: This beta release of the Microsoft RPC MIDL compiler generates C code
594: stub files that do not specify the _stdcall calling convention keyword
595: (or macros that map to _stdcall). When you compile the server stubs with
596: the old C calling convention, calls from the RPC server run-time library
597: to the server stubs do not operate correctly.
598:
599: A workaround is to specify the C compiler switch /Gz to select the
600: _stdcall calling convention at compile time. Because the main() routine
601: takes a variable number of arguments, it cannot be declared as _stdcall.
602: You must explicitly declare main() as old C calling convention by using
603: either the _cdecl keyword or the _CRTAPI1 macro. The RPC sample programs
604: and makefiles demonstrate this workaround.
605:
606: For more information about the _stdcall and _cdecl calling conventions,
607: see the Microsoft C/C++ compiler documentation provided with Microsoft
608: Windows NT.
609:
610: 14.0 RpcWinSetYieldInfo not supported for Win32 applications, TCP/IP
611:
612: The RPC API function RpcWinSetYieldInfo is provided for use with Win 3.x
613: applications only. The ability to yield during RPC calls in the
614: Microsoft Windows 3.x environment provides the following benefits:
615:
616: o other Windows 3.x applications are not blocked during
617: a lengthy remote procedure call
618:
619: o the application that makes the remote call can
620: continue to process messages such as WM_PAINT
621:
622: o users can choose to cancel the remote call
623:
624: The function RpcWinSetYieldInfo is not supported in the Win32
625: environment in this release. The yield capability provided by this
626: function is not as important in the Win32 environment as it is in the
627: Windows 3.x environment. The Win32 preemptive multitasking environment
628: lets you design your application to use multiple threads and allows your
629: applications to run with other applications.
630:
631: In this beta release, the function RpcWinSetYieldInfo has no effect when
632: RPC calls are made over the TCP/IP transport.
633:
634: 15.0 Uuidgen utility provided for Microsoft Windows NT
635:
636: This release of the Microsoft RPC SDK includes a version of the uuidgen
637: utility for Microsoft Windows NT. If the endpoint mapper has not been
638: started, you must start the endpoint mapper before you start the uuidgen
639: utility. To run uuidgen, enter:
640:
641: rpcss noservice
642: uuidgen
643:
644: After the endpoint mapper has been started once, you can start the
645: uuidgen utility by entering "uuidgen." The "rpcss noservice" step is not
646: required for the MS-DOS version of uuidgen.
647:
648: 16.0 Use NULL security descriptor with RpcUseAllProtseqs
649:
650: The RpcUseAllProtseqs security descriptor parameter must be set to NULL
651: in this beta release of Microsoft RPC version 1.0. The NULL parameter
652: indicates that the default ACL is applied.
653:
654: In this beta release, you should not use the "system" account with the
655: named pipe transport because this account has a default ACL.
656:
657: 17.0 Leading zeroes in version numbers do not create unique values
658:
659: The period between the major and minor numbers is a delimiter and does
660: not represent a decimal point. For example, the version setting 1.11
661: represents a major value of one and a minor value of eleven. Version
662: 1.11 does not represent a value between 1.1 and 1.2. Version 1.11
663: represents a value between 1.10 and 1.12. Do not use leading zeroes in
664: the minor version value.
665:
666: 18.0 Const initialization
667:
668: The MIDL compiler accepts void pointer initialization in some cases when
669: it should report an error, as in the following:
670:
671: void * v = 1;
672:
673: Although accepted by this release of the MIDL compiler, this
674: initialization is not valid.
675:
676: 19.0 Include three header files in your distributed applications
677:
678: With this version of the Microsoft RPC SDK, your distributed application
679: should include the following header files, in the following sequence:
680:
681: #include <RPC.H>
682: #include <RPCNDR.H>
683: #include "mystub.h"
684:
685: where mystub.h is the stub file generated by the MIDL compiler.
686:
687: 20.0 Context handle issues
688:
689: An [in, out] context handle can be NULL on input only if another,
690: explicit, handle is used as the binding handle.
691:
692: Context handles cannot be used as function return values, as in the
693: following example:
694:
695: [context_handle] long * MyFunc(...);
696:
697: 21.0 Only one error_status_t parameter allowed
698:
699: The Microsoft RPC implementation of the type error_status_t is
700: equivalent to the DCE error_status_t associated with the attributes
701: [fault_status, comm_status].
702:
703: Unlike the DCE specification, which allows multiple parameters of type
704: error_status_t, the MIDL compiler supports only one parameter of type
705: error_status_t in each remote procedure.
706:
707: 22.0 Unsized arrays issues
708:
709: In this release of Microsoft RPC version 1.0, IDL files that feature
710: unsized arrays with the size_is attributes can cause the MIDL compiler
711: to generate C language stubs that contain errors. As a workaround for
712: this software error, specify a maximum array size and use the length_is
713: attribute.
714:
715: 23.0 Separate in, out parameters to avoid memory orphaning
716:
717: When your distributed application uses an [in, out, unique] pointer
718: parameter, the server side of the application can change the value of
719: the pointer parameter to NULL. When the server returns the NULL value to
720: the client, memory referenced by the pointer before the remote procedure
721: call is still present on the client side but is no longer accessible
722: from that pointer. This memory is said to be "orphaned."
723:
724: Memory can also be orphaned even when the server returns a non-null
725: value for the pointer parameter. For example, if the parameter points to
726: a complex data structure such as a tree, the server side of the
727: application can delete nodes of the tree without modifying the value of
728: the pointer to the root node of the tree.
729:
730: Repeated orphaning of memory on the client without freeing the unused
731: memory can lead to a situation where the client runs out of available
732: memory resources. You can prevent such a client "memory leak" by
733: maintaining pointers to the allocated memory. One method that maintains
734: pointers to allocated memory on the client is to use separate [in] and
735: [out, unique] parameters rather than a single [in, out, unique]
736: parameter.
737:
738: By using separate [in] and [out] parameters, you can force the
739: distributed application to allocate memory on both the client and server
740: each time the client application calls the remote procedure. The server
741: stub allocates memory for [in] data when the client calls the remote
742: procedure. The client stub allocates memory for [out] data during return
743: from the remote procedure.
744:
745: This technique, like double-buffering, can use twice as much memory as
746: needed for each data structure. To reduce memory use, your client
747: application can free the memory associated with the [in] parameter after
748: making the remote procedure call.
749:
750: 24.0 Small model application development not supported
751:
752: This beta release of Microsoft RPC version 1.0 for MS-DOS and Microsoft
753: Windows 3.x supports development of large model applications only. The
754: link libraries and dynamic link libraries supplied with this release are
755: large-model libraries.
756:
757: In this beta release, you cannot create small-model applications that
758: use RPC.
759:
760: 25.0 Single process cannot be client, server using NetBIOS
761:
762: This beta release of Microsoft RPC version 1.0 does not support
763: applications that use the NetBIOS transport and that are designed as a
764: single process that makes calls to both the client and server run-time
765: libraries.
766:
767: 26.0 Escape sequences not correct in the generated header files
768:
769: The MIDL compiler provided with this beta release of Microsoft RPC
770: version 1.0 does not correctly produce escape sequences in generated C
771: language header files.
772:
773: Character constants that use hexadecimal notation in the IDL file
774: incorrectly appear as null characters in the generated header file. For
775: example, the IDL file statement:
776:
777: const char HexNotationChar = '\x10';
778:
779: generates the incorrect definition in the generated .H file:
780:
781: #define HexNotationChar '\0'
782:
783: Strings that contain the escaped double-quote character appear in the
784: generated header file without the escape character. For example, the
785: string "an escaped double quote\"" is incorrectly generated as the
786: string "an escaped double quote"".
787:
788: As a workaround, define escape sequences in a common header file that
789: can be directly included by your application.
790:
791: 27.0 Ncalrpc transport issues
792:
793: In this beta release of Microsoft RPC version 1.0, client applications
794: that use the protocol ncalrpc with implicit handles must include code to
795: handle exceptions before the client can connect to the server. The
796: number of exceptions raised during binding is related to the number of
797: times a client has connected to the server. Exception 0x6E6 is raised.
798: After handling this exception as many times as it is raised, the client
799: can connect to the server.
800:
801: The ncalrpc transport supplied in this beta release does not support
802: callbacks and does not support buffers larger than 32K.
803:
804: 28.0 RpcNsBindingExport requires a non-null interface parameter
805:
806: In this release of Microsoft RPC version 1.0, the RPC API function
807: RpcNsBindingExport requires a non-zero value for the parameter IfSpec.
808: When you supply a NULL value for IfSpec, the function incorrectly
809: returns the value RPC_S_NAME_SERVICE_UNAVAILABLE.
810:
811: 29.0 Configuring RPC name service for LAN Manager networks
812:
813: To run the locator service on LAN Manager networks, you must run a
814: primary locator on a domain controller and you must run a locator on
815: each computer that runs an RPC server.
816:
817: When the primary locator runs on the primary domain controller (PDC), no
818: configuration is needed. The default registry settings assume that the
819: primary locator runs on the PDC.
820:
821: When the primary locator runs on a computer other than the primary
822: domain controller, change the registry entry
823: SOFTWARE\Microsoft\Rpc\NameService\NetworkAddress to the names of the
824: computers that run the locator service. Separate computer names with the
825: semicolon character ";".
826:
827: The NameService registry entry NetworkAddress is used by clients during
828: name service lookup operations. The NameService registry entry
829: ServerNetworkAddress is used by servers during name service export
830: operations.
831:
832: For Microsoft Windows NT, use the regedit utility to change the registry
833: entry. For MS-DOS and Microsoft Windows 3.1, use a text editor to change
834: the entry name \Root\Software\Microsoft\Rpc\NameService\NetworkAddress
835: in the file RPCREG.DAT.
836:
837: For information about using the RPC name service with DCE host
838: computers, see the instructions provided in release note 2.0, "Gateway
839: required for DCE NSI API interoperability."
840:
841: 30.0 Length_is applied to pointer causes error
842:
843: The MIDL compiler supplied with this beta release of Microsoft RPC
844: version 1.0 generates incorrect stub code for an IDL file that applies
845: the length_is attribute to a pointer that represents an unsigned array.
846: For example, in the following example, the data size is specified as 1
847: rather than the value represented by the variable s:
848:
849: void foo( [length_is(s)] long * pl, short s);
850:
851: -----------------------------------------------------------
852: PostScript is a registered trademark of Adobe Systems, Inc.
853:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.