Mail Archives: djgpp/1996/05/24/22:09:02
"A.Appleyard" <A DOT APPLEYARD AT fs2 DOT mt DOT umist DOT ac DOT uk> wrote:
> In the course of trying to find how to write Windows programs in djgpp that
>can create windows and menu boxes etc like Visual C does, I have waded at
>length through several large expensive comprehensive-looking books on the
>inner workings of Windows and I am at the end of what I can track down myself.
> (0) I have found that Windows functions are in a number of tables of them,
>e.g. GetFilePortName is number 343 in the table USER, and that it is called as
>`WORD FAR PASCAL GetFilePortName(LPOSFTRUCT) LPOFSTRUCT lpofstruct; (display a
>"print to file" box and return the chosen file's details in arg `lpofstruct').
> (1) Where is FTP or WWW info about special interrupts that only work in
> Windows?
You can try the Ralph Brown interrupt list, but I'm not sure there are
many.
> (2) Where on FTP or WWW is a full listing of these Windows functions (names,
>arg patterns, what they do, what number position in which table)? The
>information on (0) is from `Undocumented Windows', which does not describe
>`documented' functions (documented where (including number and table name)?).
Get hold of a windows.h file. The only free ones that I know of are
the one with the cygnus port and the one with the wine development
(part of linux). As for the position in the table, the only easy way I
can think of is to take a look at kernal.dll or user.dll with a viewer
of some sort and take a look at the export section of the file. This
will have a long list of all the functions exported, and they should
be the same as your tables (that's where they come from). The export
list is the one that doesn't start with a dll.
> (3) Please: If one of these functions is the n'th function in the table
>QWERTY, and it has such and such an arg pattern, how do I call it from djgpp?
>If someone could write an interface that will let a djgpp program start under
>Windows (not in a DOS box) and call just one of these functions, say the
>abovementioned GetFilePortName, I can (given a source of information (2)) do
>the rest of the donkey work and make altered copies of GetFilePortName's
>interface matter to call each of the many other such Windows functions.
Declare it as __stdcall__ as far as I now this is the calling
convention for most of the Win32 API.
Having said all this it would be far easier for you to use the RSX
package. The work required to get it going will probably be far less
than the work you look like your letting yourself in for. Otherwise
working towards full Win32 support (as in linking to PE's so that the
dynamic linking is handled by windows) might be more worthwhile.
Malcolm
- Raw text -