home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / mswindo / programm / tools / 2274 < prev    next >
Encoding:
Internet Message Format  |  1993-01-29  |  2.8 KB
  1. Path: sparky!uunet!gradient!kevin
  2. From: kevin@gradient.gradient.com (Kevin Farrington)
  3. Newsgroups: comp.os.ms-windows.programmer.tools
  4. Subject: RE: borlandc++ and MSC++ DLLs
  5. Keywords: DCE borland MSC DLL
  6. Message-ID: <353@gradient.gradient.com>
  7. Date: 27 Jan 93 15:38:59 GMT
  8. Organization: Gradient Technologies Inc., Hudson MA
  9. Lines: 55
  10.  
  11. In <C0wsLI.Dwy@fig.citib.com> ghica@fig.citib.com (Renato Ghica) writes:
  12.  
  13. >I have a third party DLL (pc-dce from Gradient), which they say
  14. >has been linked under microsoft c++ API. This library does not
  15. >work (undefined symbols when linking) in a BC++ 3.1 environment.
  16. >The third party vendor is stumped. They have tried and can't get it
  17. >to work under BC.
  18.  
  19. >Has anyone gotten a MSC /API dll to link in a BC++ 3.1 application?
  20.  
  21.     First, I would like to apologize for being so late in responding to
  22. this question.  We have been extremely busy finishing up the next
  23. release of our PC-DCE product and were unable to follow this 
  24. thread.
  25.  
  26.     Although this question has led to a very interesting discussion
  27. concerning C++ incompatibilities between the MSC and Borland 
  28. compilers with regard to DLLs, it misrepresents the problem.
  29.  
  30.     The problem is not with linking to DLLs, but with static libraries.
  31. Our product consists of a very small static library and a large DLL.  The
  32. static library is used to transparently hide some data sharing that takes
  33. place between the user's application and our DLL.  The linker is complaining
  34. about some symbols in the static library.  
  35.  
  36.     This static library is built using the Microsoft LIB utility that 
  37. is included in the C 7.00 toolkit.  The object modules are also compiled
  38. with the C 7.00 compiler.  Neither our static library nor our DLL is 
  39. built using C++, it is straight C code.  As far as our DLL is concerned, 
  40. we do use the _pascal keyword on our entry points wherever possible. 
  41.  
  42.     We are investigating various options to remove this problem.  One is
  43. to ship Borland versions of the static library.  Of course, this 
  44. conversation would then take place again whenever someone wants to use
  45. a compiler other than Borland or Microsoft.  Another alternative would
  46. be to remove the static library altogether and expose a lot of messy
  47. details to the application developer.
  48.  
  49.     So, I guess we should rewrite the question as "Has anyone gotten a
  50. MSC static library to link with a BC++ 3.1 application?"  
  51.  
  52.     We do want to solve this problem so that we can provide Borland 
  53. toolkit users with the same level of support that we currently provide 
  54. with the Microsoft toolkit.  
  55.  
  56.     Any suggestions or comments regarding our products are welcome.
  57.  
  58. ----------------------------------------------------------------------
  59. Kevin Farrington            (kevin@gradient.com)
  60. PC-DCE Project Leader
  61. Gradient Technologies, Inc.
  62. -- 
  63. Kevin Farrington            (kevin@gradient.com)
  64. PC-DCE Project Leader
  65. Gradient Technologies, Inc.
  66.