home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / mswindo / programm / misc / 5429 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.5 KB  |  51 lines
  1. Newsgroups: comp.os.ms-windows.programmer.misc
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!att-out!cbnewsd!cbnewsc!tjr
  3. From: tjr@cbnewsc.cb.att.com (thomas.j.roberts)
  4. Subject: Re: Far Pointer Problem in DLLs
  5. Organization: AT&T
  6. Date: Tue, 26 Jan 1993 16:13:31 GMT
  7. Message-ID: <1993Jan26.161331.5931@cbnewsc.cb.att.com>
  8. References: <1993Jan26.110458.29522@unipalm.co.uk>
  9. Lines: 40
  10.  
  11. From article <1993Jan26.110458.29522@unipalm.co.uk>, by johnt@unipalm.co.uk (John Taylor):
  12. > Andrew Joseph Kompanek <ak10+@andrew.cmu.edu> writes:
  13. >>All of this code is my own source I'm porting from Unix.  Is there a way
  14. >>for it to automatically handle these file pointers properly even though
  15. >>it doesn't look like there are far versions of fopen, etc.??  It seems
  16. >>to me, the compiler should be smart enough to swap in right data segment
  17. >>and convert the pointer to a near pointer... assuming the function doesn't
  18. >>need "near" data from more than one segment.
  19. >>any advice out there on a transparent portable way to fix the problem with
  20. >>the file pointers?  Use less "data" is unfortunately not a good answer...
  21.  
  22. Use LARGE model for your DLL. As long as you don't use REAL MODE of
  23. Windows 3.0, you'll be OK (and many Windows C/C++ compilers won't handle
  24. real mode anyway - for the same reason). Porting from UNIX is often
  25. difficult in MS-DOS/Windows/80x86 because the segmentation limits
  26. are so small (64 kb) - most UNIX code pretty much assumes 4Gb segments
  27. (and int is 32 bits, etc.).
  28.  
  29. > 
  30. > I've not got normal file handling to work in a DLL at all.
  31. > You need to use the Windows File handling routines, or _lopen,_lclose etc ...
  32. > depending on what best fits what you are trying to do.
  33. > 
  34. > As far as the portablitiy issues - give up.
  35. > DLL and portable are not two things you normally say in the same sentance.
  36. > There are a lot of standard functions that just don't work in DLL's, for no
  37. > real reason that I can see, except to make things difficult.
  38.  
  39. Offhand, I don't know of any routines that won't work in a large-mode
  40. DLL. Of course, I haven't tried every lib routine....
  41. I have a complicated real-time multimedia program that is implemented
  42. as a DLL (and a small prog that merely calls the DLL) - everything
  43. I tried to do has worked (the interrupt handlers need to be in a DLL,
  44. and as I did not want to split C++ classes between the DLL and the
  45. application, I put everything into the DLL [only the interrupt
  46. code gets GlobalPageLock()-ed]).
  47.  
  48. Of course, "portable DLL" is an oxymoron - DLLs are very Windows specific.
  49.  
  50. Tom Roberts    att!ihlpl!tjrob        TJROB@IHLPL.ATT.COM
  51.