Mail Archives: djgpp/1995/03/16/12:40:53
[snip]
>And Windows 3.1 please: a great lot of people still have Windows 3.1 .
That could be a problem from 32bit code; you'ld need to switch modes
with every system call and every system callback (I think... still not
real clear on protected vs (real?) mode operations, since I never needed
to worry about it before). Win32s should be freely available via ftp from
numerous sites, which'll give you a 32-bit Win3.1, and the space cost is
only a few MB :-); eventually you'll need to go 32-bit anyway, whenever
Chicago gets out and prevalent. (I'm having a little trouble calling it
Win95)
>
>> The catch is that we don't have the right libraries and executable
>> converter, nor do we have a resource compiler (which isn't as big a deal).
>
>How long would it likely take for someone who knows more about Windows than I
>do, to write the required routines etc? I have a copy of a book "Windows 3.1
>Programmer's Reference" by James W.McCord (ISBN 0-88022-787-7, publ. 1992 by
>Que Corporation, page numbers up to 1354), which describes at great length how
>to call a great lot of the routines needed to call the various things that
>happen in Windows.
As far as system calls and callbacks are concerned, the big problem is calling
sequences. If there's a way to force Gnu to generate 'FAR PASCAL' sequences,
no problem; if you can't, big problem writing interface stubs for every Windows
routine (and then allocating an additional proc_instance thunk for each callback
in addition to any which Windows may or may not require, to massage parameters)
For linking to the Windows system DLLs, 'ld' might need to be modified to fool
it into thinking DLLs are 'shared objects'... (just a guess) ...although now
that I think of it, I'm really not clear on how DLL routines are accessed at
the assembly level.
And, of course, you need a stub to load COFF. Seems like a lot of work.
- Raw text -