RE: [fltk.general] Compiler for Windows 95 target [General Use]

[MacArthur, Ian (Leonardo, UK)]

> Another question that I'm interested in...

> On Saturday, February 18, 2017 at 11:35:34 PM UTC+1, Ian MacArthur
> wrote:
> > However; this may not be as bad as it sounds. I'm pretty sure (though
> > not certain) that in these places, rather than calling the "problem"
> > API's directly, we attempt to load them dynamically at runtime. If the
> > load fails, then some fallback option is followed.
> > Now, on WIN95 loading these API's will fail, but the fallback code,
> > assuming it does come into play, should mean the code still "works".

> Could someone explain me, what exactly will happen if my application
> calls a function of FLTK 1.3.4 that have a higher Windows API version
> requirement? How will the fallback step in? What extra work is necessary
> from my side, to guarantee the stability of my application?


If it works at all, then you should not have to do anything, really.

For example, in the multi-screen code under WIN32, rather than just assuming that the host PC provides the necessary API's to query the number of screens and their respective sizes, instead we attempt to dlopen() the DLL that provides the features at run time (actually, under WIN32 we use GetModuleHandle() and GetProcAddress(), but it is analogous to what dlopen et al do on a posix-like system...)

If that works, we then use these "later" API's to manage the screen layout etc.

If that fails, we fallback to assuming a single screen and use the legacy GetSystemMetrics() API to determine its size.

So if you do this on WIN95, the call to load the extended API's (EnumDisplayMonitors() and GetMonitorInfoA() in this case) will most likely fail, but we will then return "sensible" values for a single-display and all should be well!

Something like that, anyway...




Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[MacArthur, Ian (Leonardo, UK)]

> WAtcom sounds interesting. What do you mean by that minor massaging?

Earlier fltk versions supported Watcom "out of the box", but it wasn't very actively supported (neither the compiler itself, nor our support for it) so some of the #ifdef's and so forth may have "withered" over the years.

It "should" more or less work with 1.3, I think, though you may need to catch a few loose ends. Not sure.

[MacArthur, Ian (Leonardo, UK)]

> > At the MinGW build, it was intentional to build all examples so that
> I
> > could try them out on my Windows 95 box. It's not just Checkers that
> > fails with the error about *InterlockedExchangeAdd*. All of them fail
> > with missing exactly the same kernel library call. This is why I
> thought
> > it must be something to do with MinGW or GCC, at least binaries
> should
> > not use these calls.
>
> I have no idea where this function call comes from. I can only say that
> FLTK does not call this function from its source code.


The actual "function call" is performing an atomic add; it's probably being used to implement a simple mutex or sema for managing some access.
It's not done by fltk's own code, but the compiler may well be doing something to manage resources or to enforce serialisation of i/o or some such.

IIRC the call appeared in the Windows API circa 0x0501 or 0x0502, that sort of level. Win95 will likely not have it, then.

I say "function call" above because it's the sort of thing that is often implemented as an intrinsic by many compilers, not as an actual function call at all, so I'd be slightly surprised here if it actually was a real function call here.

That being said, it would be (almost) trivial to make a header file of inline functions that would implement that (and a few more of the related Interlocked* functions from later WIN32 API's) well enough to get it to work on Win95.

I haven't tried searching, but such a thing may well be kicking about the web already.

Whether that's a useful way forward... I can not say.


My preference would be to dig out an older version of mingw32 - probably something from around the gcc-3.4 era still worked with Win95, IIRC?

[MacArthur, Ian (Leonardo, UK)]

> AFAIK the Windows 95 unicode is a two byte unicode "wide char", but
> FLTK
> 1.3 uses utf8 unicode! You can use all kinds of compiler flags or
> definitions, but I don't think this will help to solve the basic
> difference in design. Probably you will need to patch 1.1.10 for use of
> widechar to realise unicode for Win95, IMHO.


All Windows versions (that can do extended character sets) use 16-bit wide chars with surrogate pairs to handle Unicode. That is true now just as much as it was for Win95.

Internally, fltk handles all that, so that the fltk internals are UTF8 but the OS API (on Windows) handles the conversion to 16-bit chars (usually UTF16 on later Windows...)

[MacArthur, Ian (Leonardo, UK)]

> Seems like I would make the whole FLTK codebase compatible
> with MSVC++ 6.0 earlier than I can get a working MinGW32.
> This mingw-get-setup installer is just crap. It can't connect
> to the network under my virtual machine while other applications
> can. No reasonable error messages or anything that could help me
> solve the problem.  It's the shame of the entire open-source
> community that MinGW32 doesn't have a normal (offline) installer.


Hmm, that is curious: I've not had any problems with the mingw-get tool under various Windows hosts (XP, 7, 10) in VirtualBox; indeed I was rebuilding my Win10 VM just 3 days ago and it all Just Worked.

That said, I thought you were looking for a mingw version that "matched" Win95? If so, you'd be wanting something older, maybe from around the gcc-3.4 period.

I'm pretty sure that in those days mingw was distributed as tarballs, there was no mingw-get tool at all back then.

[MacArthur, Ian (Leonardo, UK)]

> Meanwhile I made two separate FLTK builds, one with -DWINVER=0x0400 and
> the other with -D_WIN32_WINNT=0x0400. Then took the examples from both
> builds folder and tried some of them on Windows 95. None of them worked.
> Same happens as with newer MinGWs. Program starts and hangs while
> consuming 100% CPU. No window is displayed.


Which version of gcc did you use in the end? And what type of CPU was used to do the build?

Not really sure this is relevant, but I ask because I have (on occasion) seen a similar effect where we are cross compiling from a modern machine but running the binary on older hardware.

The upshot is that the compiler is emitting instruction sequences that make sense on the host machine (which the compiler detects when it runs) but which are producing unexpected behaviours on (very old) the target hardware.

Now, we worked around this by judicious use of the -march, -mtune, -mcpu, (etc... I forget the details) flags to "advise" the compiler what target we wanted and that helped.

This may be hitting a similar issue?

Is your Win95 box a physical machine or a VM on something modern? If it is a physical machine, and you are using a more recent compiler version, it might be something like this.

FWIW, I still think it'd be worth a stab at getting a suitable ancient mingw tarball and trying that, rather than using something recent and depending on their installer.

They still seem to have the old tarballs up on SF:

https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version3/Current%20Release_%20gcc-3.4.5-20060117-3/


gcc-3.4.5 is possibly too modern for Win95 too (gcc-3.4.5 is about 2008 or so, IIRC?) but will be closer than gcc-5.something which would be pretty recent.

I'm pretty sure I was using gcc-3.4.something to build code for Win98 and NT4, back in the day, which have broadly the same API level as Win95.


> I don't know how the hell
> the creator of Dillo for Win32 managed to do it, nor have I any idea how
> to get in touch with him.

Can't offer any suggestions for that...

[MacArthur, Ian (Leonardo, UK)]

> Build was successful. However, no sample application would launch
> under Windows 95. The program starts, nothing happens that could be
> seen but the application stays in the background and consumes 100% CPU.


Can you get the debugger on it and see where it is spinning?


Without that information, it's hard to know what to suggest... Is it getting through the initialization of the CRT and into our winmain at all? Or spinning somewhere prior to that?

If it is getting into fltk's core, is it spinning in a specific initialization routine, or...?