From: vtailor AT gte DOT net
Subject: Re: Win32s/mingw32
29 Apr 1998 06:28:13 -0700
Sender: root AT cygnus DOT com
Message-ID: <199804281350.IAA09915.cygnus.gnu-win32@smtp1.mailsrvcs.net>
To: gnu-win32 AT cygnus DOT com
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=windows-1252


>>   vtailor AT gte DOT net
>>   Thu, 23 Apr 1998 21:21:02 -0500 (CDT)
>>
>>>   Peter Dalgaard BSA (p DOT dalgaard AT biostat DOT ku DOT dk)
>>>   23 Apr 1998 11:09:18 +0200
>>>Gunther Ebert  writes:
>>>>
>>>> win32s doesn't support Win32 console programs. GUI programs that
>>>> were built with the mingw32 compiler should work fine if they don't
>>>> use anything that Win32s doesn't support (like multiple threads,
>>>> console). Look into the Win32 API docs to see which Win32 functions
>>>> are supported by Win32s and which are not.
>>>> I don't believe that the mingw32 compiler produces a wrong exe format,
>>>> the programs do even run under Windows95 :-)
>>
>>win32s is still a 16-bit executable system, and the code for generating
>>loads and stores is different than under MINGW32 or CYGWIN32.  I'd be
>>surprised if you could get any kind of a gcc program to load under
>>win32s.
>>>
>This is to forestall a response to this mailing list in the form of an
>email reply that I received from p.dalgaard.
>
>Win32s is just an extension of Windows 3.1 and uses the same executable
>format, which is an extension of the Dos executable format and uses
>16-bit registers to form a 32-bit address, something that will cause an
>immediate exception if it appears within a `flat-model' program for
>Windows 95/NT.
>
>Windows 95/NT programs use a set of registers that was added to the Intel
>CPU architecture after the Windows 3.0 and 3.1 series was designed. These
>registers are not used for Windows 3.0 and 3.1 programs.  Hence, the
>incompatibility.
>
>To get Windows 3.1 executables from gcc, you have to change code-
>generation templates to generate the earlier non-flat-model code.
>
>>>#include
>>>int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
>>>LPSTR lpCmdLine, int nCmdShow)
>>>{
>>>        MessageBox (NULL, "Hello Win32", "First App", MB_OK);
>>>return 0;
>>>}
>
>In case you look at the Wine distribution, you'll find the above program
>that I sent in when we were testing first versions of libwine.so over a
>year ago.
>>>
>>>the RSXNT executable runs under WINE on Linux, but the mingw32 one
>>>dies with
>>>
>>>No handler for Win32 routine CRTDLL.107: _fpreset (called from 00401055)
>>>
>>That just means that Wine has a built-in crtdll.dll emulation, and
>>someone forgot to include a stub for _fpreset.  If you go to the Wine
>>source code and add such a stub, and there are no other problems, then
>>you ought to get mingw32 programs to load and run.
>>
The originator of this thread has been sending wildly abusive email to
anyone responding to the thread.  There are two points missing in the
above: 1. To port a library like curses or libslang to Win3/31, you
need some kind of a conio library that lets you set text color attributes
and move the cursor to predefined locations.  2.  You still have the
interesting question of whether any Win3/31 program has ever used the
flat addressing model registers successfully, including for function calls.

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".