3 — Migration Notes

[Previous] [Next] [Contents] [Index]

This chapter contains information on how to migrate applications developed for environments other than 32 bit Windows, or with other DCE vendors. It contains the following sections:

3.1 Migrating UNIX DCE Applications to PC-DCE
3.2 Migrating Applications Developed With Compaq DCE for Windows NT
3.3 Migrating 16 bit Windows Applications To 32 bit Windows
3.4 Migrating Applications Developed Using Earlier Releases of PC-DCE

3.1 Migrating UNIX DCE Applications to PC-DCE

Keep the following in mind when porting your existing DCE applications from a UNIX system to PC-DCE:

• Time Synchronization within a Cell

  If a DTS Clerk is running on the client, it functions like its UNIX counterpart. If such a clerk isn't running in Windows 98, our dce32init program will automatically synchronize your clock with a DTS Server running on the Security Server. Windows 2000 and Windows NT have a similar program called timesync.exe that does the same thing without the clerk running.

• Thread Scheduling

  Although the pthreads library on UNIX systems has many possible scheduling methods, the Windows environments PC-DCE supports only support the Win32 thread scheduling method. This method is a modified round robin technique that increases priority for waiting threads, decreases priority for running threads, and increases priority for threads holding resources required by higher priority threads. Any thread that receives a Win32 message also has its priority raised. Applications can use the Win32 API to change thread priority attributes.

• Integrated Login

  PC-DCE provides the integrated login function, in which logging into a Windows account also logs you into a mirror DCE account.

• Partitioning and Security

  If you are using NTFS partitioning on a Windows 2000 or Windows NT system and plan to migrate existing applications from a UNIX environment, you will have comparable security to what was previously available. However, this security is tied to Windows user accounts and not to DCE accounts. If you are using the FAT file system, you will have minimal security.

• On UNIX systems, rpc_ss_allocate() and rpc_ss_free() can be used as callback arguments in DCE API calls. With PC-DCE, you may need to wrap these calls and create __cdecl versions as shown below so that they match argument prototypes for the API call used.

  #if defined(WIN32)
  

  /* wrap rpc_ss_allocate in a __cdecl call so arg pointers will work */
  static idl_void_p_t rpc_ss_allocate_cdecl(idl_size_t size)
  {
  return rpc_ss_allocate(size);
  }
  #define rpc_ss_allocate rpc_ss_allocate_cdecl
  

  /* wrap rpc_ss_free in a __cdecl call so arg pointers will work */
  static void rpc_ss_free_cdecl(idl_void_p_t ptr)
  {
  return rpc_ss_free(ptr);
  }
  #define rpc_ss_free rpc_ss_free_cdecl
  #endif /* WIN32 */
  

  You can also use the cdecl_rpc_ss_allocate, cdecl_rpc_ss_free and cdecl_rpc_ss_client_free calls from the dce32.dll library.

In PC-DCE applications, failed pthread API calls (and other failed DCE API calls) return an error to the application via the Win32 API call GetLastError() rather than by setting the errno variable as expected in UNIX DCE implementations.

This mechanism for PC-DCE error retrieval is necessary because there is no way to set the errno variable from the PC-DCE runtime that works reliably for all C compilers or for all versions of a particular compiler's C runtime library. To retrieve the errno value of the most recent failed DCE API call, you must use GetLastError().

3.2 Migrating Applications Developed With Compaq DCE for Windows NT

Applications developed using Compaq DCE for Windows NT will have to be recompiled and relinked with PC-DCE ADK to be compatible with PC-DCE.

Developers who previously used Compaq's IDL compiler to generate stubs or header files may notice that PC-DCE's IDL compiler assigns a different calling convention to the function prototypes. PC-DCE's IDL compiler defaults the convention as being __cdecl whereas Compaq's IDL compiler defaults it to __stdcall. This may lead to some unresolved function prototype issues when applications are migrated to a PC-DCE development environment.

PC-DCE uses the -mgr_call_seq and -ptr_call_seq command line options to enable a developer to choose calling conventions. To force the call convention to be a __stdcall only, call the PC-DCE IDL compiler with the following parameters:

idl.exe -ptr_call_seq __stdcall -mgr_call_seq __stdcall

3.3 Migrating 16 bit Windows Applications To 32 bit Windows

Please keep the following in mind when porting your existing PC-DCE for Windows 3.1 (16-bit) applications to PC-DCE (32-bit):

• Unlike 16-bit versions of PC-DCE (PC-DCE for Windows 3.1), PC-DCE (Windows 2000, Windows NT, and Windows 98 supported) does not employ a blocking function. To execute asynchronous RPCs, you must use pthreads as demonstrated in the Greet sample application. Be aware that use of the Winsock blocking function is not supported by threads making DCE RPCs.

• To conserve resources, the default stack size in 16-bit PC-DCE for Windows 3.1 is set to 12 KB. This value, however, commonly needs to be increased to accommodate many DCE applications, especially those that issue a lot of Security calls. In PC-DCE, the default stack size is set to 32 KB. In most cases, you should no longer need to increase the stack size.

• Remove all the Entegrity-specific DCE API extension calls such as DCEGetLastError, DCERegisterServerName, DCESetBlockingHook, DCETaskDestroy, DCETaskInit, DCEUnhookBlockingHook, and DCEYield.

• Change all of the header files to their full names since they were abbreviated in Windows 3.1. Please refer to Appendix C of your PC-DCE for Windows 3.1 Application Developer's Guide for translations.

• The sec_login_certify_identity call is supported as long as the user is running with dced.

• The client and server stubs have the _cstub and _sstub extensions, respectively (instead of the cs and ss extensions). All IDL files will need to be recompiled using the new 32-bit IDL compiler.

• Remote Procedure Calls (RPCs) are not limited to 64K.

• On Windows 2000 and Windows NT, the local file system may be considered secure if you are using NTFS.

• Memory models are irrelevant.

• If you were using pthread_yield or DCEYield to maintain multitasking ability, these are no longer necessary.

• Unlike in Windows 3.1, threads in PC-DCE cannot freely look at the Windows message queue of any other thread or the main process, nor can they automatically share resources from other processes. Please see the AttachThreadInput Win32 API call for a workaround to this issue.

• All PC-DCE programs you may have developed with pre-3.1 releases should run without any problems on PC-DCE Version 3.1 Client Runtime Kit.

• A version 3.1-compiled program may not work on previous PC-DCE releases; Entegrity does not support forward compatibility.

• Regarding DTS: If no external time provider is in use in the cell, all times will have infinite inaccuracy.

• ONC RPC Interoperability: ONC RPCs and DCE RPCs will neither affect nor interact with each other.

PC-DCE fully supports recursive (MUTEX_RECURSIVE_NP), nonrecursive (MUTEX_NONRECURSIVE_NP) and fast (MUTEX_FAST_NP) mutexes, with fast mutexes set as the default. As a result, any code from a previous PC-DCE release that tries to lock a mutex more than once in the same thread should be rewritten to unlock the mutex before it tries to relock it, unless the recursive mutex is explicitly selected.

The pthread_mutexattr_getkind_np() and pthread_mutexattr_setkind_np() routines are also supported, allowing you to set and retrieve the mutex kind attribute for recursive, nonrecursive, and fast mutexes.

[Previous] [Next] [Contents] [Index]

To make comments or ask for help, contact support@entegrity.com.

Copyright © 1997-2003 Entegrity Solutions Corporation & its subsidiaries