home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / os2 / programm / 3877 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  2.6 KB
  1. Path: sparky!uunet!gatech!rutgers!concert!sas!mozart.unx.sas.com!sasdgh
  2. From: sasdgh@cedar.unx.sas.com (Glenn Horton)
  3. Newsgroups: comp.os.os2.programmer
  4. Subject: Re: Help! Need to link 16bit LIB with 32bit Application
  5. Message-ID: <Bs6428.D9L@unx.sas.com>
  6. Date: 29 Jul 92 20:39:44 GMT
  7. References: <anderson.16.712435941@mayo.edu>
  8. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  9. Organization: SAS Institute Inc.
  10. Lines: 57
  11. Originator: sasdgh@cedar.unx.sas.com
  12. Nntp-Posting-Host: cedar.unx.sas.com
  13.  
  14.  
  15. In article <anderson.16.712435941@mayo.edu>, anderson@mayo.edu (Alfred I. Anderson) writes:
  16. |> Sybase distributes a .LIB file that is linked in with a C appliaction to 
  17. |> allow access to their data base on the network.  Apparently it is not 
  18. |> possible (?) to link this file against an application developed with the IBM 
  19. |> CSet/2 compiler in 32 bit mode??
  20. |> 
  21. |> Apparently the OS/2 2.0 linker can only call 16bit DLLs and cannot 
  22. |> incorporate 16bit LIBs!  For our application, we must access this 16bit .LIB.
  23. |> 
  24. |> Does anyone have a suggestion how we can link to this 16bit LIB??
  25. |> 
  26. |> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  27. |> Alfred Anderson                Internet:    anderson@Mayo.edu
  28. |> Mayo Foundation - Rochester MN 55905
  29. |> 
  30. |> NOTE:  PLEASE INCLUDE YOUR RETURN ADDRESS IN THE BODY OR .SIG FILE
  31. |> OF ANY NOTE SENT TO ME --- THE SOFTWARE ON MY END DOES NOT PASS 
  32. |> YOUR RETURN ADDRESS FROM THE MESSAGE HEADER TO ME!
  33. |> -----------------------------------------------------------------
  34.  
  35.     We don't use IBM's compiler so this may not help but you can 
  36. give it a try.
  37.  
  38.     Most .lib files are stub libraries that just serve to resolve
  39. external references to functions that actually live in a dll. What we
  40. did to get around this is 
  41.  
  42. (1) determine what functions live in what 
  43. DLLs. You can most likely so this by dumping the DLL as a text file.
  44.  
  45. (2) use IMPORT statements on the linker to resolve the external 
  46. references. This is the part that your system may not support.
  47.  
  48.  
  49.  
  50.     An alternate technique to step 2 is as follows.
  51. (1) Use DosLoadModule to load a DLL and get a handle for it, for example...
  52.  
  53. DosLoadModule((PSZ)&buf, sizeof(buf), "NETAPI", &dllptr))
  54.  
  55. (2) Use DosQueryProcAddr to get the addresse of the function you want to
  56. call, for example...
  57.  
  58. DosQueryProcAddr(dllptr, 0, "NETBIOSENUM", (PFN FAR *)&nbenum))
  59.  
  60. (3) Call the functio through a function pointer, for example...
  61.  
  62. (*nbenum)(...);
  63.  
  64.  
  65.     I hope this helps. If you have any more questions just send e-mail.
  66. I can't guarantee I'll read this newsgroup again soon.
  67. -- 
  68.  
  69. Glenn Horton            SAS Institute Inc.
  70. sasdgh@unx.sas.com      919-677-8000 x6640
  71.