Microsoft KB Archive/167800

-

The information in this article applies to:


 * Microsoft Visual C++, 32-bit Editions, version 5.0

-

SUMMARY
This is part 2 of 2, of the Win32 Software Development Kit (SDK) readme that is compatible with the SDK that was included with Visual C++ 5.0. This article includes the original text of the readme. This document contains references to directories that are on the CD the SDK originally shipped on, not the Visual C++ CD.

Microsoft Win32 SDK for Microsoft Windows August, 1996

- Contents: -

Sections 1 through 6 can be found in the article titled,

"README for the Win32 Software Development Kit, Part 1 of 2"

7. RPC and MIDL 8. OLE 9. Known Issues

MORE INFORMATION

=
===

--- 7. RPC and MIDL ---

7.1 RPC Run Time

New datagram features: The datagram transport protocols, ncadg_ipx and ncadg_ip_udp now support security (on Windows NT) and cancel operations (on both Windows NT and Windows 95).

Support for Banyan Vines SPP transport: The RPC run time includes support for the Banyan Vines SPP transport protocol on Windows NT 4.0 clients and servers, and on MS-DOS and Windows 3.x clients. Support on Windows NT requires the Windows NT edition of Banyan Enterprise Client version 5.56 [30] or newer. Please contact Banyan Systems, Inc., for questions relating to the Banyan software. For more information on using the transport protocol, see the online SDK topics "ncacn_vns_spp" in the MIDL Language Reference, and "String Bindings" in the RPC Reference.

New run time support for port restrictions and selective binding to NICs: A new RPC data type and a set of Extended RpcServerUseProtseq functions let you restrict port allocation for dynamic ports and allow multihomed computers to selectively bind to Network Interface Cards. For more information, see the online SDK topic "RPC_POLICY" in the RPC Reference.

DCE pipes are supported on all transport protocols on 32-bit Windows platforms. For more information, see the "Pipes" overview in the RPC Reference.

7.2. MIDL Compiler -- MIDL/ODL merge: The Microsoft Interface Definition Language (MIDL) now includes the Object Description Language (ODL) attributes, statements, and directives, allowing you to use the MIDL compiler to generate type library files for OLE applications. This replaces the type library generation tool MKTYPLIB.EXE. For more information, see the online SDK topic "Generating a Type Library With MIDL" in the MIDL documentation.

New default mode for MIDL compiler: The /ms_ext and /c_ext modes for the MIDL compiler are now the default mode. It is not necessary to specify these two switches when you compile an IDL script that includes Microsoft extensions to the OSF-DCE IDL. A new compiler option, /osf, is available to force strict compatibility with OSF-DCE. For more information, see the online SDK topic "/osf" in the MIDL Command-Line Reference.

Compiler options /Oic and /Oif offer interpreted methods for marshaling stub code between client and server. For more information, see the online SDK topic "/Oi" in the MIDL Command-line Reference.

Pipe support: The new MIDL compiler and the RPC run time support DCE pipes to pass large or incrementally produced quantities of data in remote procedure calls. This release has some restrictions related to pipe types and non-pipe arguments in pipe calls. For more information see the online SDK topic "pipe" in the MIDL Language Reference and the "Pipes" overview in the Overviews node of the RPC documentation.

Performance attributes for data marshaling: Two new attributes, [wire_marshal] and [user_marshal], permit faster, more efficient marshaling of datatypes that are difficult to remote. For more information see the online SDK topics "The wire_marshal Attribute" and "The user_marshal Attribute" in the RPC documentation, and the topics "wire_marshal" and "user_marshal" in the MIDL Language Reference.

Array attributes accept multiple parameters: You can use this feature to specify a sized array of pointers or a multidimensional section of a multidimensional array. For more information on this, and on how to use [out, size_is] to allow the server to return a dynamically sized array, see the online SDK topics "size_is" in the MIDL Language Reference, "Multiple Levels of Pointers" in the RPC documentation, and the sample programs "dynout" and "strout" in the \mstools\samples\rpc directory of the Win32 SDK CD.

Support for international characters: Where appropriate, the MIDL compiler now accepts the entire ANSI character set in the input file.

Floating-point constants: The MIDL 3.0 compiler supports floating-point constants in IDL and ACF files.

32-bit int: The MIDL compiler recognizes the int data type as a 32-bit remoteable element on 32-bit platforms.

Object interface methods return type: Nonlocal object interface member functions must have a return type of HRESULT or SCODE. Earlier versions of MIDL allowed member functions to have a return type of void. For more information, see the online SDK topic "object" in the MIDL Language Reference.

Version control: To guard against using MIDL features that are not supported on older platforms, the MIDL compiler generates target macros that facilitate compatibility checking during C compilation. For more information, see "Targetting Stubs for Specific 32-Bit Platforms" in the MIDL Programmer's Reference.

7.3. Known Problems --- Static C run time libraries may cause problems with the RpcSm memory package: The new CRT library for Windows NT 4.0 may create problems for RPC applications that use the RpcSm/RpcSs memory management package instead of MIDL_user_allocate and MIDL_user_free, and link with the static version of the C run time libraries(LIBCMT.LIB or LIBC.LIB). Note that the dynamic library (MSVCRT.LIB and DLL) does not create this problem.

The problem is this: When an RPC application links to the static versions of the C run time libraries, and it uses the RpcSm package, it will have a heap that is separate from the one used by RPC run time and stubs. When this happens, the RPC application cannot free memory blocks that were allocated by the stubs, and the stubs cannot free blocks that were allocated by the RPC application. Because the stubs and the application operate on different heaps, these cross references cause an access violation in the memory package that is executing the free operation on a pointer. Note that this is a problem only if your application causes cross- referenced free operations as described earlier.

There are two ways to handle this problem:

1. If you must link to the static versions of the C run time libraries, use MIDL_user_allocate and MIDL_user_free, and don't compile in /osf mode or use the [enable_allocate] attribute. Implement these memory management routines so they operate on your application's heap. 2. If you must use the RpcSm memory management package, link to the dynamic version of the C run time library (MSVCRT.LIB and DLL).Linking to the dynamic version of the C run time library ensures that your application shares the same heap with the RPC run time. In some situations non-pipe [out] arguments are corrupted when there is an [in] pipe but no [out] pipe. Use an [in,out] pipe or an empty [out] pipe as a work-around.

The compiler doesn't generate correct mixed-mode (/Os) stubs for some cases with multidimensional array attributes. If this happens, use one of the interpreted modes (compiler option /Oi) instead.

When you define a coclass and a library in an IDL file, but you do not define an interface, MIDL fails to generate the .H and _I.C files. You need to use the /h compiler switch to generate these files.

--- 8. OLE Release Notes for Windows NT 4.0 ---

Applications that use OLE should note the following restrictions and features available in the Windows NT 4.0 Shell Update Release.

* Availability of DCOM (Distributed COM) Changes from Windows NT 4.0 Beta 2/DCOM Preview MIDL/RPC/OLEAUT32.DLL provide marshaling support for VARIANTs Receiving OR_INVALID_OXID (0x80070776) Extensive Delays on Initial Remote Activation TreatAs on Remote Server Applications using CLSCTX_SERVER/CLSCTX_ALL do not run on     Windows 95 or previous versions of Windows NT if compiled with _WIN32_DCOM or _WIN32_WINNT>=0x0400. * MkParseDisplayName enables : syntax * Overriding the binding behavior of monikers: Class Moniker, IClassActivator, BINDOPTS2 * New APIs Help Avoid Race Conditions in Multithreaded COM Servers * New CoRegisterPSClsid API enables proxy/stub usage without registration * New OleCreateXXXEx APIs avoid multiple launch and shutdown of servers * Property Set Interfaces Available * Compound File Optimization APIs Available as Redistributable Component for Windows 95, Windows NT 3.51 and Windows NT 4.0 * Asynchronous Storage interfaces and functions available * Component Categories Manager available as redistributable component * OLEPRO32.DLL Available in Windows NT 4.0 * OLE Tutorial Code Samples in mstools\samples\ole\com * Marshaling code for OLE Control and ITypeLib2/ITypeInfo2-Interfaces

Availability of DCOM (Distributed COM) -- Distributed COM (previously referred to as Network OLE) is now an integral part of Windows NT 4.0. Distributed COM allows you to use any 32-bit COM component across machine boundaries with rich features in concurrency and scalability, security, and robustness. For a complete discussion of the new interfaces and APIs, please refer to the online SDK documentation.

Changes from Windows NT 4.0 Beta 2/DCOM Preview --- If you were using Windows NT 4.0 Beta 2, please note the following differences between Beta 2 and the final version. * The COSERVERINFO structure has been changed as follows: typedef struct _COSERVERINFO { DWORD          dwReserved1; LPWSTR         pwszName; COAUTHINFO *   pAuthInfo; DWORD          dwReserved2; } COSERVERINFO; The dwSize member has been removed and the pszName member has been renamed to pwszName. The additional parameters are described in   detail in the online SDK documentation. To obtain compatibility with Beta 2, the additional members have to be initialized to 0 and NULL, respectively.

If you were on the DCOM preview program or attended the Professional Developers Conference in March where the DCOM preview for Windows NT 4.0 Beta 1 was distributed, please note the following differences between the Beta 1 preview and the final release.

* CoInititializeEx can now be called with different COINIT flags from different threads, which supports the mixing of apartment-model and free-threaded objects.

* CoInitializeSecurity now takes additional arguments which merge the functionality of CoRegisterAuthenticationServices, which has been removed. A call to CoInitializeSecurity(pSD, dwAuthnLevel,   dwImpLevel, pReserved) can be replaced with a call to    CoInitializeSecurity(pSD, -1, NULL, NULL, dwAuthnLevel, dwImpLevel,    NULL, 0, pReserved).

* Additional levels of impersonation and authentication are now supported by DCOM. The SECURE sample application (\mstools\samples\ole\dcom\secure) demonstrates the use of these security settings.

* The OLECNFG command-line tool that supported configuring RunAs applications has been replaced with a graphical tool, DCOMCNFG, which displays information about and configures groups of classes packaged together (within the same executable [EXE] or library   [DLL]) according to their APPID (see following). Run the DCOMCNFG tool directly from the command line or by clicking Run on the Start menu and typing DCOMCNFG in the Run dialog box.

* The LaunchPermissions, AccessPermissions, RunAs, ActivateAtStorage, RemoteServerName, LocalService keys/values that were stored under each class's CLSID key (HKEY_CLASSES_ROOT\CLSID\{...}) are now all named values of a new key associated with the CLSID key known as an   APPID. Each CLSID has a reference to its APPID key as a named value ("AppID") whose value is the stringized GUID that is their APPID. The APPID keys are kept under HKEY_CLASSES_ROOT\APPID\{...}, and their named values are the attributes and security settings for the collection of classes (possibly only one) associated with the APPID. This assures that a process exposing multiple class factories obtains the same security settings regardless of which CLSID is   initially used to launch the process initially.

* In the beta 1 preview release of DCOM, the security information associated with the LaunchPermissions and AccessPermissions keys was managed with the registry security APIs. These configuration entries are now named values that contain Win32 security descriptors. See the Win32 documentation for more information on manipulating security descriptors.

MIDL/RPC/OLEAUT32.DLL Provide Marshaling Support for VARIANTs - The marshaling code for IDispatch, dual, and oleautomation interfaces has been changed to use standard MIDL generated proxy/stubs. As a by-product of this change, VARIANTs, BSTRs, and so on can now be used in any non-Ole Automation COM interface, that uses MIDL generated proxy/stubs. However, this new marshaling support requires additional functionality in the RPC run time, so that MIDL generated proxy/stubs that use VARIANTs will not run on previous versions of COM/RPC, including Windows 95 and Windows NT 3.51. The only way to marshal VARIANT parameters on non-Ole Automation interfaces on Windows 95 and Windows NT 3.51 remains to hand-code the proxy/stubs using MIDL's call-as mechanism.

It is important to realize that the wire representation used by proxy/stubs is part of the interface contract and cannot be changed without changing the interface identifier. Before Distributed COM, this has not been of practical concern, since updating the proxy on a machine forcibly updated the corresponding stub. Any proxy/stub that is installed on a DCOM-enabled system (Windows NT 4.0) effectively freezes the wire format for this interface. For designers of new interfaces, this leaves several options in dealing with VARIANTs:

* Use hand-coded proxy/stubs on Windows NT 3.51 and Windows NT 4.0: this will preclude any future use of MIDL/RPC's VARIANT marshaling.

* Use MIDL generated proxy/stubs on Windows NT 4.0 and hand-coded proxy/stubs on Windows NT 3.51: installation programs have to guarantee that no Windows NT 3.51 proxy is ever installed on a DCOM-enabled machine. When upgrading a system from Windows NT 3.51 for Windows NT   4.0, the hand-coded proxies must fail, requiring a new installation of    the application. * Use intelligent proxy/stubs that test for the presence of the new marshaling support and use either hand-coded marshaling on Windows NT 3.51 or MIDL-based marshaling on Windows NT 4.0: this is the most flexible but most complicated option.

Receiving OR_INVALID_OXID (0x80070776) -- When using COM creation APIs (such as CoCreateInstance, CoCreateInstanceEx, or CoGetClassObject) to create remote objects (objects on other machines), incorrectly configured network settings that otherwise appear to support file or print sharing properly may cause Distributed COM to fail with the distinguished error, OR_INVALID_OXID (0x80070776). This is typically not a problem with COM, but this network configuration problem that is not exposed by other networking operations that have fall-back behavior that differs from COM over improperly configured protocols.

This failure can occur when a machine has been configured with TCP/IP as well as another network transport, such as IPX/SPX, or NetBeui, but the TCP/IP configuration is improperly configured. For example, it may be configured to be dynamically assigned an IP address using DHCP, yet a DHCP server may not be available, so it has no IP address. The solution is to properly configure TCP/IP networking.

Extensive Delays on Initial Remote Activation - When establishing an initial DCOM connection between two machines, a significant delay -- typically in the order of 30 seconds -- can be perceived, if the primary protocol (default: TCP/IP - UDP) is not configured correctly.

DCOM attempts remote activation using one protocol at a time. If a protocol indicates a failure, DCOM uses the next configured protocol. If a machine is configured to use TCP/IP and IPX/SPX for DCOM, with TCP/IP being the primary transport, a faulty TCP/IP configuration (missing DHCP server, for example) will not prevent the object from being activated, but the activation will succeed only after the TCP/IP transport's time-out of approximately 30 seconds.

To solve this problem, you must either correct the configuration of the primary transport or remove the protocol by using the Network Control Panel.

TreatAs on Remote Server

During a remote activation for a specific class, the server does not correctly use the TreatAs mappings. Although the correct server process gets launched, COM still expects the original CLSID instead of the mapped CLSID. If the server does not provide a class factory (through CoRegisterClassObject) for the original CLSID, the activation times out after 30 seconds.

Applications using CLSCTX_SERVER/CLSCTX_ALL do not run on Windows 95 or previous versions of Windows NT if compiled with _WIN32_DCOM or _WIN32_WINNT>=0x0400. The new definitions of CLSCTX_SERVER and CLSCTX_ALL include CLSCTX_REMOTE_SERVER. Applications using these flags will not run on Windows 95 or previous versions of Windows NT when compiled with the header files included in this SDK. Previous versions of COM/OLE validate the flags passed to CoCreateInstance/CoGetClassObject and fail with E_INVALIDARG when CLSCTX_REMOTE_SERVER is specified. When targeting both Windows NT 4.0 and Windows 95 or previous versions of Windows NT, you need to make sure the _WIN32_WINNT preprocessor symbol is defined to be less than 0x0400 and the _WIN32_DCOM preprocessor symbol is not defined.

MkParseDisplayName enables : syntax --- MkParseDisplayName has been expanded to first check for a " :" prefix in the display name to be parsed. If such a prefix is found, MkParseDisplayName proceeds as for the existing "@progid!" syntax. This change simplifies the usage of display names: "@file:\\myserver\myshare\myfile.doc" can now be changed to "file: \\myserver\myshare\myfile.doc", effectively unifying the URL name space with OLE's moniker name space. The protocol prefix of a URL maps to a ProgID while the remainder of the URL is handled by the object corresponding to the protocol prefix. See the online SDK documentation for details.

Class Moniker, IClassActivator, BINDOPTS2 - The File Moniker now allows monikers to be composed to its left. Previous versions of File Moniker simply failed any bind operation when they detected a moniker to their left. In Windows NT 4.0, the file moniker's IMoniker::BindtoObject method delegates either both the detection of the CLSID and the instantiation of the object, or merely the instantiation of the object to the moniker to its left.

The File Moniker does this by calling IMoniker::BindtoObject on the moniker to its left. If this object exposes IClassActivator, the file moniker calls IClassActivator::GetClassObject to obtain the uninitialized instance. Otherwise, if the object exposes IClassFactory, the file moniker calls IClassFactory::CreateInstance. If the object exposes neither, the bind operation fails.

Custom monikers should be changed to enable this kind of extensibility, where applicable. Typically, this mechanism does not apply for monikers that already require or support a moniker to their left, like Item Monikers.

The new Class Moniker for Windows NT 4.0 uses this extensibility mechanism. It can be composed with a file moniker to override the CLSID. The Class Moniker can be created using the new CreateClassMonikerAPI, using CoCreateInstance (..., CLSID_ClassMoniker, ..., IID_IParseDisplayName) or through MkParseDisplayName with a display name of the form "clsid:xxxxxxxx- xxxx-xxxx-xxxx-xxxxxxxx".

The file moniker also accepts a new BINDOPTS2 structure, an extension of the current BINDOPT structure. Clients can use this new structure to IBindCtx::SetBindOptions to request additional behavior for a bind operation.

Note: Currently, only File Moniker uses the new bind options. COM's new Class Moniker does not currently support the pServerInfo flag. pServerInfo and the pointers included in pServerInfo are not copied when IBindCtx::SetBindOptions is invoked. Thus, these pointers need to be kept valid until the last release to the bind context.

See the online SDK documentation for more details on any of these new mechanisms.

New APIs Help Avoid Race Conditions in Multithreaded COM Servers

Multithreaded local servers (apartment- or free-threaded) face a synchronization problem with regard to their class factory objects. While a class factory is being revoked, another thread can simultaneously be using this same class factory. Applications thus have to validate, that after revoking the class-factory object(s) during normal shutdown (after the global reference count went to 0), no new references have been created.

To facilitate this, applications can use the new COM APIs CoAddRefServerProcess, CoReleaseServerProcess, CoSuspendClassObjects and CoResumeClassObjects. See the online SDK documentation for details.

New CoRegisterPSClsid API Enables Proxy/Stub Usage Without Registration --- COM typically obtains the proxy/stub for a given interface from entries under the HKEY_CLASSES_ROOT\Interface registry key. When a COM object does not have write privileges to the registry (it may be untrusted code running in a restricted process), it can use the CoRegisterPSClsid API to temporarily register an IID to CLSID mapping for its process. See the online SDK documentation for details.

New OleCreateXXXEx APIs Avoid Multiple Launch/Shutdown of Servers - Existing instantiation functions, (OleCreate, OleCreateFromFile, OleCreateFromData, OleCreateLink, OleCreateLinkToFile, and OleCreateLinkFromData) create only a single presentation or data format cache in the default cache location during instantiation. Most applications require caching at least two presentations (screen and printer) and may require caching data in a different format or location from the handler. Because of this, applications must typically launch and shut down the object server multiple times to prime their data caches during object creation (Insert Object, Insert Object from File, and Paste Object).

Extended versions of these creation functions solve this problem. See the online SDK documentation for details on OleCreateEx, OleCreateFromFileEx, OleCreateFromDataEx, OleCreateLinkEx, OleCreateLinkToFileEx, and OleCreateLinkFromDataEx.

Property Set Interfaces Available - If your applications formerly created OLE property sets on their compound files by writing the binary property format according to the "OLE 2 Property Set Binary Format Specification," look in the SDK documentation for information about the IPropertyStorage and IPropertySetStorage interfaces new to Windows NT 4.0. Use of these interfaces to create and manipulate property sets on compound files is preferred over manually reading and writing the binary format.

Compound File Optimization APIs Available as Redistributable Component -- Compound Files provide a file system within a file. The data within a compound file is allocated in blocks of 512 bytes, which can be fragmented (noncontiguous) just like files on any file system. The Compound File Optimization Tool (DFLAYOUT.EXE) provides a way of optimizing the order of the data sectors within a Compound File similar to a hard disk defragmentation/optimization tool. Unlike a hard disk optimization tool, DFLAYOUT.EXE arranges the data according to the access pattern of the application that loads the Compound File. It launches the application and monitors any read/write accesses to the file. It then places data that was used first by the application at the beginning of the file.

The tool's primary use is in conjunction with asynchronous storage (see following), where it allows applications to do optimal progressive rendering while a file is being downloaded asynchronously. An optimized file also provides performance advantages in standard network access and even local access scenarios as it minimizes seek operations and takes advantage of read-ahead caching. Access on compact discs or other storage media with high seek latency also benefit greatly from an optimized file layout.

The tool provides a simple, dialog-based UI that allows the user to select multiple Compound Files that are to be optimized. When the user clicks the Optimize button, the tool will obtain the CLSID from each Compound File, launch the associated application (using CoCreateInstance) and initialize it using IPersistStorage. The tool monitors the activity of the application and writes an optimized Compound File based on this activity.

The tool uses the following Layout Optimization interfaces and APIs that are implemented in DFLAYOUT.DLL.

* StgOpenLayoutDocfile

* ILayoutStorage

These APIs enable application-specific optimization tools and even integrated optimization support within applications.

Please refer to the online SDK documentation for more information on the layout optimization interfaces and APIs. The DFLAYOUT.DLL is NOT part of Windows NT 4.0. Instead it is provided in the Win32 SDK as redistributable code in the form of a self-extracting executable DFLAYDLL.EXE. It is ONLY redistributable through the use of this executable (MSTOOLS\BIN\ \DFLAYDLL.EXE for Windows 95, Windows NT 4.0, and Windows NT 3.51). See details on redistribution rights in REDIST.TXT in the \License directory.

Asynchronous Storage Interfaces/APIs Available -- The following interfaces and APIs are available in OLE32.DLL:

* StgOpenAsyncDocfileOnIFillLockBytes

* StgGetIFillLockBytesOnILockBytes

* StgGetIFillLockBytesOnFile

* IFillLockBytes

* IProgressNotify

Please refer to the online SDK documentation for information on Asynchronous Storage.

Component Categories Manager Available as Redistributable Component --- The Component Categories Manager enables enumeration of COM components by their capabilities and by the capabilities they require from their containers. It implements the Component Category Standard (refer to the ActiveX SDK for more details), which extends the existing tagging mechanism ("Control", "Insertable" and so on) to a GUID-based categorization mechanism.

The Component Categories Manager is an in-process COM-object (COMCAT.DLL) that exposes the ICatInformation and ICatRegister interfaces. See the ActiveX SDK for a description of these interfaces and for header files (COMCAT.IDL/H).

The Component Categories Manager is provided as a self-extracting, self- registering executable. It is ONLY redistributable through the use of this executable (MSTOOLS\BIN\ \CCDIST.EXE for Windows 95 and Windows NT 4.0, MSTOOLS\BIN\ \CCDIST35.EXE for Windows NT 3.51). For details on redistribution rights see the REDIST.TXT file in \License.

OLEPRO32.DLL Available in Windows NT 4.0

The OLEPRO32 library, which offers APIs to assist in the writing of OCX's and ActiveX controls, is now shipped with Windows NT 4.0. In Beta 1 of Windows NT 4.0, this library was offered as a redistributable in the SDK. Before the Beta 1 release of Windows NT 4.0, this library was offered as a redistributable part of the Microsoft Visual C++ Control Developers Kit for Windows 95 and Windows NT.

OLE Tutorial Code Samples in mstools\samples\ole\com

This release includes a new tutorial series of OLE code samples. Though individual samples can be extracted as a framework for further development, the series is a graduated sequence illustrating Win32 coding techniques using the COM Component Object Model and OLE services. The series covers COM object construction using custom interfaces, component object construction in a server housing, in-process servers, licensing of component objects, standard marshaling of custom interfaces, out-of-process servers, multithreaded apartment model construction, Distributed COM (DCOM), multithreaded clients of free-threaded component objects, connectable component objects, and structured storage using the compound file services of OLE. Extensive comments are provided in the source code. Comprehensive tours of the internal behavior of the samples are also provided in separate .TXT files. These new tutorial samples are located in branch \MSTOOLS\SAMPLES\OLE\COM of the installed Win32 SDK. See TUTORIAL.TXT in the COM directory for more details.

Marshaling Code for OLE Control and ITypeLib2/ITypeInfo2 Interfaces --- Application writers need to know that in order to use any of the following new features in OLEAUT32.DLL, they must cause OLEAUT32.DLL to register itself. This can be done in one of two ways:

1. regsvr32 oleaut32.dll (regsvr32 is provided in the Win32 SDK).

2. Call the DllRegisterServer entrypoint in oleaut32.dll directly (this is what regsvr32 does):

HMODULE hmodule;  FARPROC pfn;   hmodule = LoadLibraryA("oleaut32.dll");  pfn = GetProcAddress(hmodule, "DllRegisterServer");   pfn;      // call the DllRegisterServer routine in oleaut32.dll FreeLibrary(hmodule);

This enables the following new functionality in oleaut32.dll: and to their remoting code.
 * Enables remoting of the new ITypeLib2 and ITypeInfo2 interfaces
 * Enables the OLE Controls interfaces to be accessed in remote clients
 * Enables access to the Standard Font and Standard Picture objects,

OLE Automation for Windows NT 3.51 -- An update to the OLE Automation components for Windows NT 3.51 and Windows 95 is available in the \MSTOOLS\OA351 directory. This DLL and TLB are installed on Windows 95 by SDK setup. See LICENSE\REDIST.TXT for information on redistribution rights. These two files are already built into Windows NT 4.0.

--- 9. Known Issues ---

In order to put the Win32 SDK headers, libraries, and tools first on the search path, the INCLUDE, LIB, and PATH environment variables are modified. Doing this on Windows 95 may overflow the environment space of COMMAND.COM. To work around this, either add the following line to CONFIG.SYS:

SHELL=c:\command.com c:\ /e:2048 /p

or open the Properties dialog box from the COMMAND.COM window, select the Memory tab, and set the "Initial environment" to the maximum value.

APIMON is a new tool in the Win32 SDK that will run only on Windows NT 4.0. It is provided as a replacement for the old WAP and LOGGER32 tools. APIMON provides an easy to use, graphical interface for gathering information on API calls and page faults. It is documented in apimon.hlp.

On the MIPS processor, the values listed in the time column of the API Counters window are invalid. Selecting the graph button when a graph is already displayed causes APIMON to fail.

The Z*.DLL files (e.g. zernel32, zser32, zdi32, ...) that were provided on previous releases of the SDK were to support the WAP and LOGGER32 tools. These DLL files are no longer present since the WAP and LOGGER32 tools have been replaced by APIMON. The apfcvt and apf32cvt tools are still provided for use with FERNEL32.DLL and the FIOSAP tool (see the online SDK documentation for more information). The apf32cvt tool will not work correctly on Windows 95.

The MIB compiler (MIBCC.EXE) requires MGMTAPI.DLL in order to run. This DLL is distributed with the operating system, and will be installed when you install the SNMP service on your machine. See the "Network" item in the Control Panel for more information.

The message compiler (mc.exe) does not compile Japanese-language strings correctly when run on the Japanese version of Windows 95. The recommended work-around is to use the Japanese version of Windows NT.

The \MSTOOLS\SAMPLES\MAPI\DOCFILE.MS sample does not compile correctly with Microsoft Visual C++ version 4.1 or version 4.0a for RISC. This is a recognized limitation in that version of the VC++ compiler, and it is fixed in version 4.2 and later.

Win32s has been removed from the Win32 SDK. It is available on another Microsoft Developer Network compact disc.

The WINDBG debugger no longer supports Win32s.

The mssetup environment variables are no longer registered by default. To build the mssetup sample and other code that uses the mssetup toolkit, run \mstools\mssetup\setenv.bat first. Notice that there is now a \mstools\include\setupapi.h header file that is different than the older \mstools\mssetup\include\setupapi.h header with the same name. If you are building code that uses mssetup, be sure that you use the older file. Some of the sample code in the Win32 SDK requires LIBCMT.LIB in order to build. This library is distributed with Microsoft Visual C++, but it is not installed by the minimum installation. If your code will not build because the linker is not able to locate this library, either grab it from the VC++ distribution media or reinstall VC++ making sure that this library is included.

The documentation indicates that the szKey member of the String and StringTable structures located in version resources can use the decimal value 1200 to indicate the Unicode character set. This is not correct. You should use the hexadecimal value 04b0 to indicate the Unicode character set. See the BLOCK string in the version resources of \mstools\samples\win32\deb\deb.rc for one example.

There, online documentation includes references to "ActiveX." This should not be confused with the ActiveX SDK that is available on the internet and that will be provided to MSDN customers later this year.

As in previous releases of the Win32 SDK, the DBG symbols for some of the Windows NT system components are provided on the SDK compact disc, in \SUPPORT\DEBUG\*. The Win32 SDK setup logic has been changed slightly so that if you run setup on a machine with a build number that matches the build of the DBG symbols, you will not be prompted for the location of the symbols. If you set up the SDK on a machine with a build number that does not match, you will be prompted, as has been the case in the past, for the location of the correct DBG symbols.

To fit all of the new material on a single compact disc, the debug symbols and the libraries have been compressed on the compact disc. The regular SDK setup will expand these files automatically as part of setup. If you copy the debug symbols or the libraries without using SDK setup, you will need to run EXPAND.EXE to decompress the files. The EXPAND utility is built into Windows NT, and is provided in the SDK for Windows 95.

The install batch file for the Software Compatibility Test (SCT) has been significantly changed to make it easier to debug 16-bit applications on Windows NT. See \SCT\SCT.HLP for additional information on using install, setdebug, and nondebug utilities. Note that SCT installation now requires you to reboot at the end of the process.

The client dynamic-link libraries for the licensing API (LSAPI32.DLL and MSLSP32.DLL) are still beta code. They are provided here for development purposes only. They are not redistributable. The interfaces may change in the future, requiring applications to be recompiled. Additional query words: sdk win32sdk win32prg

Keywords         : kbprg Version          : 5.0 Platform         : NT WINDOWS Issue type       : Last Reviewed: June 25, 1999