🚀 go-pugleaf

From article <1993Jan26.110458.29522@unipalm.co.uk>, by johnt@unipalm.co.uk (John Taylor):
> Andrew Joseph Kompanek <ak10+@andrew.cmu.edu> writes:
>>All of this code is my own source I'm porting from Unix.  Is there a way
>>for it to automatically handle these file pointers properly even though
>>it doesn't look like there are far versions of fopen, etc.??  It seems
>>to me, the compiler should be smart enough to swap in right data segment
>>and convert the pointer to a near pointer... assuming the function doesn't
>>need "near" data from more than one segment.
>>any advice out there on a transparent portable way to fix the problem with
>>the file pointers?  Use less "data" is unfortunately not a good answer...

Use LARGE model for your DLL. As long as you don't use REAL MODE of
Windows 3.0, you'll be OK (and many Windows C/C++ compilers won't handle
real mode anyway - for the same reason). Porting from UNIX is often
difficult in MS-DOS/Windows/80x86 because the segmentation limits
are so small (64 kb) - most UNIX code pretty much assumes 4Gb segments
(and int is 32 bits, etc.).

> 
> I've not got normal file handling to work in a DLL at all.
> You need to use the Windows File handling routines, or _lopen,_lclose etc ...
> depending on what best fits what you are trying to do.
> 
> As far as the portablitiy issues - give up.
> DLL and portable are not two things you normally say in the same sentance.
> There are a lot of standard functions that just don't work in DLL's, for no
> real reason that I can see, except to make things difficult.

Offhand, I don't know of any routines that won't work in a large-mode
DLL. Of course, I haven't tried every lib routine....
I have a complicated real-time multimedia program that is implemented
as a DLL (and a small prog that merely calls the DLL) - everything
I tried to do has worked (the interrupt handlers need to be in a DLL,
and as I did not want to split C++ classes between the DLL and the
application, I put everything into the DLL [only the interrupt
code gets GlobalPageLock()-ed]).

Of course, "portable DLL" is an oxymoron - DLLs are very Windows specific.

Tom Roberts	att!ihlpl!tjrob		TJROB@IHLPL.ATT.COM