Compiler for Windows 95 target

[Pál Ács]

Hi,

I would like to develop an application that would be used in a legacy environment (specifically Windows 95 and 98). Installing external enhancements like KernelEx are not an option. I tried to solve this in the following ways.

• Tried to compile FLTK with Visual Studio 6.0. This is the last Visual Studio that officially supports Windows 95. I suppose it is supported because there are VS 6.0 workspace files in the ide/VisualC6 folder. I started VS 6.0, then loaded the workspace file ide/VisualC6/fltk.dsw. It loaded successfully. However, when I tried to build FLTK it gave me errors like this.

Fl_Scroll.cxx

../..\FL/Fl_Image.H(58) : error C2258: illegal pure syntax, must be '= 0'

../..\FL/Fl_Image.H(58) : error C2252: 'ERR_NO_IMAGE' : pure specifier can only be specified for functions

../..\FL/Fl_Image.H(59) : error C2258: illegal pure syntax, must be '= 0'

../..\FL/Fl_Image.H(59) : error C2252: 'ERR_FILE_ACCESS' : pure specifier can only be specified for functions

../..\FL/Fl_Image.H(60) : error C2258: illegal pure syntax, must be '= 0'

../..\FL/Fl_Image.H(60) : error C2252: 'ERR_FORMAT' : pure specifier can only be specified for functions

../..\FL/Fl_Device.H(121) : error C2258: illegal pure syntax, must be '= 0'

../..\FL/Fl_Device.H(121) : error C2252: 'matrix_stack_size' : pure specifier can only be specified for functions

../..\FL/Fl_Device.H(129) : error C2258: illegal pure syntax, must be '= 0'

../..\FL/Fl_Device.H(129) : error C2252: 'region_stack_max' : pure specifier can only be specified for functions

At almost all FL_* base classes. I suppose this is some kind of incompatibility, as MSVC 6 would expect a stricter or different syntax than these declarations were made with. Since I didn't know what to do about these errors, I gave up on MSVC 6.0.

• My next candidate was MinGW. I tried with the latest MinGW (using the online installer from mingw.org). It did not work. Then I also tried an older version of MinGW-w64 (a 32-bit i686 build of it) version 4.8.1. In both cases I got the following kinds of errors.
  
  
  
  
  

I think I should somehow tell MinGW not to use these calls to the Windows API for they're not present in the NT kernel of Windows 95. However, I don't know how. So I gave up. However, somehow it must be possible with MinGW because Dillo for Win32 uses FLTK and it runs on my Windows 95 test environment without problems.

Any thoughts on this?

Is there anyone who has an experience building for an ancient system like Windows 95?

Best,

Pál Tamás Ács

[Albrecht Schlosser]

On 18.02.2017 19:52 Pál Ács wrote:

> I would like to develop an application that would be used in a legacy
> environment (specifically Windows 95 and 98). Installing external
> enhancements like KernelEx are not an option.

Some facts: The official FLTK policy is that we support Windows 2000 and
later [1], at least since FLTK 1.3.0. Earlier Windows versions may or
may not work. FLTK 1.4.0 may set higher requirements, but that is not
yet necessary.

If you don't need UTF-8 (which is very likely since you target Windows
95) then FLTK 1.1.10 might be an option. If you also use an old compiler
or are willing to ignore, fix, or switch off several compiler warnings
of more modern compilers, this _might_ work.

I assume you tried the latest release FLTK 1.3.4[-1] ?

> I tried to solve this in the following ways.
>

> * Tried to compile FLTK with Visual Studio 6.0. This is the last

> Visual Studio that officially supports Windows 95. I suppose it is
> supported because there are VS 6.0 workspace files in the
> ide/VisualC6 folder.

It's no longer officially supported by the FLTK team but we didn't want
to delete it without a concrete reason. I'm not sure, but there may be
other VS versions between VS6 and VS 2008 that can open this old
solution (but not the VS2008 ide files).

FLTK 1.4 no longer distributes bundled IDE solutions, you must use CMake
to generate them. IIRC CMake dropped support for VS6 (and more?)
recently, but you may get an older CMake version...

> I started VS 6.0, then loaded the workspace
> file ide/VisualC6/fltk.dsw. It loaded successfully. However, when I

> tried to build FLTK it gave me errors like this. [...]

Very old compiler...

> My next candidate was MinGW. I tried with the latest MinGW (using
> the online installer from mingw.org). It did not work.

MinGW works well on current Windows versions. It's one of the build
tools the FLTK team recommends for Windows. However ...

> Then I also
> tried an older version of MinGW-w64 (a 32-bit i686 build of it)
> version 4.8.1. In both cases I got the following kinds of errors.
>

> <https://lh3.googleusercontent.com/--EeH547ue7g/WKiWmDjC7aI/AAAAAAAAAEs/lHkBLJjFowssPHpNQ3jEtXU4hU1oGXE2gCLcB/s1600/fltk-fluid-error-win95.png>
>
> <https://lh3.googleusercontent.com/-VSm65WzNT2Y/WKiWcJafkwI/AAAAAAAAAEo/1BelAiFemVURTj55r5lQlZTlE8jsGGRDgCLcB/s1600/fltk-checkers-error-win95.png>

>
> I think I should somehow tell MinGW not to use these calls to the
> Windows API for they're not present in the NT kernel of Windows 95.

Yep. See below.

> However, I don't know how. So I gave up. However, somehow *it must be
> possible *with MinGW because Dillo for Win32
> <https://sourceforge.net/projects/dillo-win32/files/> uses FLTK and *it
> runs *on my Windows 95 test environment*without problems*.
>
> Any thoughts on this?

It's very likely that dillo uses an older (1.3.x) release or a (maybe
patched) svn version. But I don't know what they're doing (although we
have sometimes contact/questions and dillo is an interesting project).

> Is there anyone who has an experience building for an ancient system
> like Windows 95?

Probably not.

Now, if you still want to use FLTK 1.3.4, this may help you:

The first error message (screenshot) shows missing export GetFileSizeEx.
The only usage of this is in fluid in a very recent extension:
fluid/ExternalCodeEditor_WIN32.h and fluid/ExternalCodeEditor_WIN32.cxx.
You may try to disable this feature by removing or disabling the
offending (part of the) source code.

Since this code is pretty new, I think that dillo uses an older version.

I have no idea why the other error message is present, but checkers is a
demo program (game) and not necessary for the FLTK library, you can
remove it from test/Makefile. I don't think that there is an option to
disable the build of all test programs with configure, but you can
switch off building the test programs if you configure your build
environment with CMake (set OPTION_BUILD_EXAMPLES OFF).

[1] Background info: there are a few places in the code where we
explicitly enable Windows 2000 features by setting _WIN32_WINNT to
0x0500 (which means: enable declarations and allow usage of Windows
functions that are available in Windows 2000 or later). You can find
more info here:
<https://msdn.microsoft.com/en-us/library/6sehtctf.aspx>

You should try to compile with 0x0400 or less, but you would need to
find and change the code where _WIN32_WINNT is set to 0x0500 and
disable/remove the functions used in that code. But maybe it's only
necessary to remove fluid's external code editor feature or remove fluid
from the build altogether if you don't need it.

[imm]

On 18 February 2017 at 20:54, Albrecht Schlosser wrote:

 

You should try to compile with 0x0400 or less, but you would need to find and change the code where _WIN32_WINNT is set to 0x0500 and disable/remove the functions used in that code. But maybe it's only necessary to remove fluid's external code editor feature or remove fluid from the build altogether if you don't need it.

​(From memory: I did not check...) There are a few places in the library code where we assert 0x0500 as a minimum NT version​ (and it is entirely likely that I added some or all of them!)

Places that I can remember are in the WIN32 text handling, and in the multiple-screens support logic.

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".

Though it is a long time since I had a box old enough to test this on; I know I used to see this happen on Win2k and WinXP machines if they did not have the multilingual support packages installed, for example (which is why we did this in the WIN32 text handling in the first place!) but any recent WinXX usually Just Works, so...

Whether for Win95 this will *actually* work I do not know. It might.

[Albrecht Schlosser]

On 18.02.2017 23:35 imm wrote:
> On 18 February 2017 at 20:54, Albrecht Schlosser wrote:
>
>
> You should try to compile with 0x0400 or less, but you would need to
> find and change the code where _WIN32_WINNT is set to 0x0500 and
> disable/remove the functions used in that code. But maybe it's only
> necessary to remove fluid's external code editor feature or remove
> fluid from the build altogether if you don't need it.
>
>
>
> ​(From memory: I did not check...) There are a few places in the library
> code where we assert 0x0500 as a minimum NT version​ (and it is entirely
> likely that I added some or all of them!)

Actually I found 4 or 5, depending on how you count (files or ...).

> Places that I can remember are in the WIN32 text handling, and in the
> multiple-screens support logic.
>
> 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".

Yep, I believe you're right. Hence the default compilation which will
define these constants to be 0x0500 (on MinGW: just checked) may work.

The only place I know of where we definitely use the function in
question directly w/o fallback code is fluid's new external code editor
feature (which showed one of the posted error messages of the OP).

> Though it is a long time since I had a box old enough to test this on; I
> know I used to see this happen on Win2k and WinXP machines if they did
> not have the multilingual support packages installed, for example (which
> is why we did this in the WIN32 text handling in the first place!) but
> any recent WinXX usually Just Works, so...

I still have WinXP available, but that system is not up-to-date with
FLTK. Maybe I'll give it a try when I have the time.

> Whether for Win95 this will *actually* work I do not know. It might.

An interesting question.

FWIW: I built FLTK 1.1.x (svn, so it's the never released version
1.1.11) with _WIN32_WINNT and WINVER == 0x0400 on my Win10 box with
MinGW and this worked well (except the expected compiler warnings).
Whether the executables will run on Win95 I do not know.

FLTK 1.3.4 did not build with 0x0400 (as expected) because we use some
constants that are not defined with 0x0400. However, as you said, it
should likely not be necessary to use 0x0400, the default (0x0500)
should work.

[Pál Ács]

Thank you for the thorough answers.

I tried the latest release, 1.3.4-1.

CMake was not involved when I tried to compile FLTK in the VisualC6 workspace, only at the MinGW build. I only used the bundled .dsw file. You mentioned a Visual Studio between 6.0 and 2008, well, there is 2005 which I also tried out today. It does compile everything fine but it won't start on Windows 95 as MSVC 2005 doesn't support Windows 95 any more. VisucalC6 is the last. However, MSVC doesn't matter anyways. I would like to go on with MinGW/GCC. It's more mature and actively maintained, has its own runtime libraries which may result in less glitches when targeting platforms like Windows 95. Still I need to figure out how I can make GCC produce binaries with lower Windows API version.

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 would need UTF-8 or at least some kind of unicode, but I would target it via UNICOWS. Like Dillo for Win32 does. I don't even know whether this is possible, just a plan.

If it turned out that the only solution is to use an older FLTK (e.g. 1.3.0 or 1.1.10), what about bugs I run into from the FLTK side? I guess they will probably never get fixed, only in the newer releases. Or do you have a special maintenance policy on older subversions? If not, how long 1.3.4 will be maintained? Do you plan to have an LTS branch that won't receive new features, just fixes?

[ed...@tantec.de]

> If it turned out that the only solution is to use an older FLTK
> (e.g. 1.3.0 or 1.1.10), what about bugs I run into from the FLTK
> side? I guess they will probably never get fixed, only in the newer
> releases.

You should use 1.1.10, because it is the final and most debugged release
of this branch. 1.3.0 starts a new branch with new features and probably
there are more bugs.

I used 1.1 branch for several software developments targeted to Win98
and NT4 and until today I need to maintain this software, because it is
still in use on current machines. But I don't need to maintain bugs,
there are just new requirements to realise.

When FLTK 1.1.5 was current version, I used MinGW 3.1.0-1,
mingw32-make-3.80.0-3, gdb-5.2.1-1 and MSYS 1.0.11 to build the
software. It is no problem to use old versions of MinGW, because the new
versions add new features, but most of the old versions are without
serious bugs.

[imm]

If you need UTF8 in an older FLTK, it may be worth looking out the old oksid port (forked from roughly 1.1.6 to 1.1.8 ish.)

There was also a port that Mikko did (IIRC) that tweaked the API'S used to be usable on WINCE too, though whether that is any better for Win95, well...

Might be worth a look!

--
Ian
From my Fairphone FP2
   

[Pál Ács]

You should use 1.1.10, because it is the final and most debugged release
of this branch. 1.3.0 starts a new branch with new features and probably
there are more bugs.

Yes, I like this way of thinking: the more less features fixed for the longer time, the more robust the code will be. However, I will definitely need Unicode, also via unicows.dll, so I don't think 1.1.10 would be the best solution for me.

 

I used 1.1 branch for several software developments targeted to Win98
and NT4 and until today I need to maintain this software, because it is
still in use on current machines. But I don't need to maintain bugs,
there are just new requirements to realise.

Interesting. Haven't you run into bugs of FLTK 1.1.10 that is fallen into the "never expected to be fixed" category?

[Pál Ács]

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?

[Martin McDonough]

You might also try the Watcom compiler, with only minor massaging I have had FLTK compile with it.

[Pál Ács]

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

[Martin McDonough]

FLTK doesn't quite compile as is with Watcom, but the changes I have had to make are always pretty minor, usually just related to Watcom only supporting slightly older syntax.

[Albrecht Schlosser]

On 19.02.2017 01:51 Pál Ács wrote:
> Thank you for the thorough answers.

Welcome.

> I tried the latest release, 1.3.4-1.

Okay, good so far.

> 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.

> I would need UTF-8 or at least some kind of unicode, but I would target
> it via UNICOWS. Like Dillo for Win32 does. I don't even know whether
> this is possible, just a plan.

FLTK 1.3 and later expects all internal strings (labels, any text, etc.)
to be UTF-8. If you use only the ASCII subset (0-127) everything might
look okay, but users may enter arbitrary UTF-8 encoded text.

> If it turned out that the only solution is to use an older FLTK (e.g.
> 1.3.0 or 1.1.10), what about bugs I run into from the FLTK side? I guess
> they will probably never get fixed, only in the newer releases.

That's true. FLTK 1.1.10 is the last release that uses "code pages"
(i.e. plain 8-bit characters). It is not maintained any more since its
release.

> Or do
> you have a special maintenance policy on older subversions? If not, how
> long 1.3.4 will be maintained? Do you plan to have an LTS branch that
> won't receive new features, just fixes?

Unfortunately not. Our team is too small to maintain several branches in
parallel. FLTK 1.3.4 is intended to be the last 1.3.x release. We don't
plan to release further 1.3.x versions, but if we encounter severe bugs
we _might_ consider releasing security fixes.

Back to your issues: The only way to tell your Windows build that you
target an older Windows version would be to set _WIN32_WINNT to a lower
version than 0x0500, e.g. 0x0400 for Windows NT 4.0. As Ian explained
this should not be necessary for FLTK since we load newer function code
dynamically - with one exception in the new external code editor feature
in fluid. If you want to use 1.3.4 then you will definitely have to
patch FLTK not to use GetFileSizeEx. This is an oversight in this pretty
new code.

FWIW: I compiled FLTK 1.1.10 with _WIN32_WINNT = 0x0400 and it worked
without errors or warnings except some "normal" compiler warnings
created by recent compilers.

Again, if you want to use 1.3.4, I suggest that you do the following for
a proof of concept:

Step 1: Try release 1.3.3 and see if this works. The Dillo docs seem to
show that they used 1.3.3 for their latest release. If this works for
you, that is a first success.

Step 2: Edit the FLTK 1.3.4 code to test if it builds and runs on your
target system. You need to replace all occurrences of 0x050X in the FLTK
source code with 0x0400 (or any lower version you may need). This WILL
definitely issue warnings and compilation errors. Most of the errors
will likely be easy to fix (from what I saw when I did it). Example:
There are additional VK_something constants that were not used in FLTK
1.1 somewhere in the keyboard handling code. These constants are not
defined in older Windows versions. You can either find the definitions
in online docs or just #ifdef that code out: if these constants were not
defined in Windows 95 then they can't be generated in that Windows
version, so you won't lose much. If you removed all offending code and
FLTK builds successfully you can try to execute the test programs on
Windows 95. If this still shows errors (InterlockedExchangeAdd) then
this results from the compiler or build tool and I don't know how to fix
that. You may try to use an older MinGW version or, as suggested by
someone else, the Watcom compiler.

Step 3: If this doesn't help, use a Win95 system with an installed
compiler of that time to build FLTK...

[Pál Ács]

On Wednesday, February 22, 2017 at 12:50:00 AM UTC+1, Albrecht Schlosser wrote:

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.

It's added by newer GCC versions. For example, TDM-GCC 4.52 doesn't add it but 5.X does.

 

FLTK 1.3 and later expects all internal strings (labels, any text, etc.)
to be UTF-8. If you use only the ASCII subset (0-127) everything might
look okay, but users may enter arbitrary UTF-8 encoded text.

Is this behavior compatible with unicows.dll? If not, would it be a lot of work to make it compatible?

 

Unfortunately not. Our team is too small to maintain several branches in
parallel. FLTK 1.3.4 is intended to be the last 1.3.x release. We don't
plan to release further 1.3.x versions, but if we encounter severe bugs
we _might_ consider releasing security fixes.

I'm only talking about applying bug fixes for 1.3.4 while leaving its features intact while paying the most attention to 1.4. FLTK is a minimalist toolkit and is a very good choice for those who want to develop their applications for legacy systems. I think it would be vital to have a branch containing a frozen FLTK release that has grown stable over time and gets only maintenance fixes. This way we would not be forced to upgrade to even newer versions with raising system requirements. If system requirements raise (e.g. Windows 95 to Windows 2000, then Windows 2000 to XP or 7), there should be an LTS branch that is supported and is compatible with even legacy systems.

Back to your issues: The only way to tell your Windows build that you
target an older Windows version would be to set _WIN32_WINNT to a lower
version than 0x0500, e.g. 0x0400 for Windows NT 4.0. As Ian explained
this should not be necessary for FLTK since we load newer function code
dynamically - with one exception in the new external code editor feature
in fluid. If you want to use 1.3.4 then you will definitely have to
patch FLTK not to use GetFileSizeEx. This is an oversight in this pretty
new code.

Fluid is not a problem. It's only necessary for creating the GUI. This can be done on a newer system. I already tried setting WINVER and _WIN32_WINNT to 0x0400. It failed. GCC complained about VK_ symbols not found in WinAPI headers.

 

FWIW: I compiled FLTK 1.1.10 with _WIN32_WINNT = 0x0400 and it worked
without errors or warnings except some "normal" compiler warnings
created by recent compilers.

That is good news, thanks for letting me know. However, 1.1.10 is without unicode. Unfortunately it's not an option to go without it. :(

 

Thanks for the PoC idea, I'll try my best.

Step 3: If this doesn't help, use a Win95 system with an installed
compiler of that time to build FLTK...

I have already done this using Visual Studio 6.0. I did this on my Windows XP box which I mainly use for building for Windows 95. All programs built with VS6 would work on Windows 95 as VS6 generates binaries with full support for  Windows 95. Here is my configuration.

Then clicked Generate, entered the build folder and executed nmake.

Fl.cxx

NOTE: WINVER has been defined as 0x0500 or greater which enables
Windows NT 5.0 and Windows 98 features. When these headers were released,
Windows NT 5.0 beta 1 and Windows 98 beta 2.1 were the current versions.

For this release when WINVER is defined as 0x0500 or greater, you can only
build beta or test applications.  To build a retail application,
set WINVER to 0x0400 or visit http://www.microsoft.com/msdn/sdk
to see if retail Windows NT 5.0 or Windows 98 headers are available.

See the SDK release notes for more information.

C:\Test\fltk-1.3.4-1\FL/Fl_Image.H(58) : error C2258: illegal pure syntax, must be '= 0'
C:\Test\fltk-1.3.4-1\FL/Fl_Image.H(58) : error C2252: 'ERR_NO_IMAGE' : pure specifier can only be specified for functions
C:\Test\fltk-1.3.4-1\FL/Fl_Image.H(59) : error C2258: illegal pure syntax, must be '= 0'
C:\Test\fltk-1.3.4-1\FL/Fl_Image.H(59) : error C2252: 'ERR_FILE_ACCESS' : pure specifier can only be specified for functions
C:\Test\fltk-1.3.4-1\FL/Fl_Image.H(60) : error C2258: illegal pure syntax, must be '= 0'
C:\Test\fltk-1.3.4-1\FL/Fl_Image.H(60) : error C2252: 'ERR_FORMAT' : pure specifier can only be specified for functions
C:\Test\fltk-1.3.4-1\src\flstring.h(28) : fatal error C1083: Cannot open include file: 'strings.h': No such file or directory
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~2\VC98\Bin\CL.EXE' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\bin\NMAKE.EXE"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\bin\NMAKE.EXE"' : return code '0x2'
Stop.

I also tried with/without defining WINVER in CMake as well as replacing WINVER with _WIN32_WINNT. No success.

Then I tried the same using FLTK 1.3.3, as you suggested. 

Fl.cxx
NOTE: WINVER has been defined as 0x0500 or greater which enables
Windows NT 5.0 and Windows 98 features. When these headers were released,
Windows NT 5.0 beta 1 and Windows 98 beta 2.1 were the current versions.
For this release when WINVER is defined as 0x0500 or greater, you can only
build beta or test applications.  To build a retail application,
set WINVER to 0x0400 or visit http://www.microsoft.com/msdn/sdk
to see if retail Windows NT 5.0 or Windows 98 headers are available.
See the SDK release notes for more information.
C:\Test\fltk-1.3.3\src\flstring.h(28) : fatal error C1083: Cannot open include file: 'strings.h': No such file or directory
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~2\VC98\Bin\CL.EXE' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\bin\NMAKE.EXE"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\bin\NMAKE.EXE"' : return code '0x2'
Stop.

Tried to patch FLTK whereever it defines WINVER and _WIN32_WINNT. Changed them to 0x0400. Same happened. I couldn't get any further.

Best,

Pál Tamás Ács

[Edzard Egberts]

Pál Ács wrote:
> That is good news, thanks for letting me know. However, 1.1.10 is
> without unicode. Unfortunately it's not an option to go without it.
> :(

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.

[Pál Ács]

Meanwhile I successfully built FLTK 1.1.10 using CMake and MSVC 6.0. It works on Windows 95! Sadly I must give this a no-go for not having built-in Unicode support. However, I consider this a kind of half-success. :)

Even fluid works properly.

[Albrecht Schlosser]

On 24.02.2017 15:05 Pál Ács wrote:
> On Wednesday, February 22, 2017 at 12:50:00 AM UTC+1, Albrecht Schlosser
> wrote:
>
> 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.
>
> It's added by newer GCC versions. For example, TDM-GCC 4.52 doesn't add
> it but 5.X does.

Okay, then you have the opportunity to use the older version. Did you
try the original MinGW(-32) gcc compilers? Do they also add this? Why do
you use TDM-gcc?

> FLTK 1.3 and later expects all internal strings (labels, any text,
> etc.)
> to be UTF-8. If you use only the ASCII subset (0-127) everything might
> look okay, but users may enter arbitrary UTF-8 encoded text.
>
> Is this behavior compatible with unicows.dll?

I'll answer this question later. As I said, FLTK uses UTF-8 internally,
but converts UTF-8 strings to Windows 2-byte wide characters (UTF-16?)
for all system calls, for instance to read directories to open files
etc.. Hence, FLTK's _internal_ representation (on all platforms) is
UTF-8, whereas the system calls use converted strings for the given
platform. This means for all Windows platforms we use the wide character
function calls, i.e. FunctionNameW as opposed to the so-called
single-byte (aka ANSI) calls FunctionNameA.

According to Wikipedia [1] this means AFAICT that this _should_ be
compatible with Unicows. I believe that text rendering also works this
way, so if you have the corresponding Unicode fonts this should also work.

However, the reason I mentioned that users could input arbitrary UTF-8
encoded text, for instance in Europe the Euro sign '€' (U+20ac), is
important for your application's data storage to files or a database.
Note that the given € sign is encoded in three bytes in UTF-8, whereas
it's only one byte in MS's "ANSI" codepage CP-1252 or other codepages.

[1] https://en.wikipedia.org/wiki/Microsoft_Layer_for_Unicode

> If not, would it be a lot of work to make it compatible?

Likely not necessary from FLTK's point of view.

> Unfortunately not. Our team is too small to maintain several
> branches in
> parallel. FLTK 1.3.4 is intended to be the last 1.3.x release. We don't
> plan to release further 1.3.x versions, but if we encounter severe bugs
> we _might_ consider releasing security fixes.
>
> I'm only talking about applying bug fixes for 1.3.4 while leaving its
> features intact while paying the most attention to 1.4. FLTK is a
> minimalist toolkit and is a very good choice for those who want to
> develop their applications for legacy systems. I think it would be vital
> to have a branch containing a frozen FLTK release that has grown stable
> over time and gets only maintenance fixes. This way we would not be
> forced to upgrade to even newer versions with raising system
> requirements. If system requirements raise (e.g. Windows 95 to Windows
> 2000, then Windows 2000 to XP or 7), there should be an LTS branch that
> is supported and is compatible with even legacy systems.

My point stands. We have too little manpower to do this. :-(

During the initial development of branch 1.4 we ported each commit to
both branches, but this was really hard work. The core of the branches
diverged heavily because 1.4 has a very different internal structure
with its system and graphics drivers to simplify future porting to other
platforms. Real bugs that would need fixes are very likely in these
system related parts so we'd need two completely different patches and
would have to test the patches thoroughly on both versions.

But, as I said before, I don't preclude that we _might_ have later bug
fix releases in branch 1.3.x.

> Fluid is not a problem. It's only necessary for creating the GUI. This
> can be done on a newer system.

You're right, but that was not my point. The reason I mentioned it was
that the only use of GetFileSizeEx was in fluid (since 1.3.4, not in 1.3.3).

Another point is that fluid is necessary to build the test programs, but
you can also do this on another host and copy the generated files over
to your target (build) host.

> I already tried setting WINVER and

> _WIN32_WINNT to *0x0400*. It failed. GCC complained about *VK_* symbols

> not found in WinAPI headers.

I already wrote that these VK_* symbols should IMHO not be a problem,
other than that you'd need to patch the FLTK sources. These particular
symbols deal with keyboard input obviously not defined in Windows
versions before XP. So, if you just disable the code dealing with these
unknown VK_* symbols (for instance by commenting it out or using '#if
(0) ... endif' you wouldn't lose anything. Keep in mind that all code
that is not compatible with the older Windows version was definitely not
existant in FLTK 1.1, so you can disable it with a little sensible
judgement. If you have questions what exactly you need to do in a
particular case, feel free to ask here.

> FWIW: I compiled FLTK 1.1.10 with _WIN32_WINNT = 0x0400 and it worked
> without errors or warnings except some "normal" compiler warnings
> created by recent compilers.
>
> That is good news, thanks for letting me know. However, 1.1.10 is
> without unicode. Unfortunately it's not an option to go without it. :(
>
> Thanks for the PoC idea, I'll try my best.
>
> Step 3: If this doesn't help, use a Win95 system with an installed
> compiler of that time to build FLTK...
>
> I have already done this using Visual Studio 6.0. I did this on my
> Windows XP box which I mainly use for building for Windows 95. All
> programs built with VS6 would work on Windows 95 as VS6 generates
> binaries with full support for Windows 95. Here is my configuration.
>

> <https://lh3.googleusercontent.com/-Btb4vNZlUTk/WLA6s3MzfYI/AAAAAAAAAFI/8Qse-kp395sb-xMG7FE225bdHAihi6DeACLcB/s1600/cmake.png>

I don't think that just defining a CMake variable WINVER helps with this
issue. I may be wrong though, but see below.

> Then clicked Generate, entered the build folder and executed *nmake*.

I'm afraid I can't help you with nmake.

Here's what I did:

I used MinGW to build FLTK 1.3.4 (sic!) with WINVER and _WIN32_WINNT
defined to 0x0400 with the patch attached to this posting.

I could build everything but I could not test on other Windows versions
than Windows 10. I fixed all issues with undefined symbols and tried to
implement fallbacks, but this is all more or less untested. The patch in
fluid, for instance, uses GetFileSize instead of GetFileSizeEx, and I
had to fix a few other issues. One of them is that fl_text_extents()
will probably always return the results of fl_measure() because the used
features don't work on older Windows, but this was already partly
implemented this way.

Please report if this patch works for you. The patch is not "perfect"
but I believe it's a good starting point. No warranties though.

I configured my standard MinGW (32-bit) with CMake (commandline):

cmake -G"Unix Makefiles" \
-DCMAKE_BUILD_TYPE=Debug \
-DOPTION_OPTIM:STRING="-D'WINVER=0x0400' -D'_WIN32_WINNT=0x0400'" \
-DCMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++" \
/path/to/fltk

Note that I use "Unix Makefiles" as CMake generator, YMMV.

BTW: gcc --version
gcc.exe (GCC) 5.3.0


Feedback welcome. If this works for you I'd like to add parts of this
patch to FLTK 1.4 so we have even better Windows compatibility. This may
enable you to build FLTK 1.4 on Windows 95 as well.

[Pál Ács]

Thank you for your work on this.

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.

Back to you soon, when I have results.

[Pál Ács]

Spent (wasted) three and a half hours trying to install MinGW32 from mingw.org. Official installer fails on Windows XP. Can't connect to server because of deprecated WinSSL SSL methods. Pathetic. -.- I configured a virtual machine with Windows 7 just for mingw-get-setup. It succeeded in downloading but failed to unpack the .xz files. Biggest shame! This is why guys at MinGW-w64 and TDM-GCC fork the project, because it is carried out this crappy way. The only installer you have is a beta crap from 2013. I gave up and kind of lost my enthusiasm for the whole project.

Could someone give me an offline installer for MinGW(32!)?

[Albrecht Schlosser]

On 28.02.2017 19:01 Pál Ács wrote:
> Spent (wasted) three and a half hours trying to install MinGW32 from

> mingw.org. ... I gave up and kind of lost my enthusiasm for
> the whole project.

I'm sorry to read that. Mostly the installer worked for me, but ISTR
that I also once had troubles unpacking some files. I can't remember how
I solved this, but maybe I unpacked them manually.

> Could someone give me an offline installer for MinGW(32!)?

I don't know. I can only give some pointers:

The MinGW files are hosted on sourceforge:
https://sourceforge.net/projects/mingw/files/MinGW/Base/

I believe the 'Base' files, distributed in several subdirectories, are
all you need, but I'm not sure. And you don't need _all_ files, of course.

This is a full package list:

$ mingw-get list | grep ^Package:
Package: mingw-developer-toolkit Subsystem: msys
Package: mingw32-autoconf Subsystem: mingw32
Package: mingw32-autoconf2.1 Subsystem: mingw32
Package: mingw32-autoconf2.5 Subsystem: mingw32
Package: mingw32-automake Subsystem: mingw32
Package: mingw32-automake1.10 Subsystem: mingw32
Package: mingw32-automake1.11 Subsystem: mingw32
Package: mingw32-automake1.4 Subsystem: mingw32
Package: mingw32-automake1.5 Subsystem: mingw32
Package: mingw32-automake1.6 Subsystem: mingw32
Package: mingw32-automake1.7 Subsystem: mingw32
Package: mingw32-automake1.8 Subsystem: mingw32
Package: mingw32-automake1.9 Subsystem: mingw32
Package: mingw32-autotools Subsystem: mingw32
Package: mingw32-base Subsystem: mingw32
Package: mingw32-basic-bsdtar Subsystem: mingw32
Package: mingw32-binutils Subsystem: mingw32
Package: mingw32-bsdcpio Subsystem: mingw32
Package: mingw32-bsdtar Subsystem: mingw32
Package: mingw32-bzip2 Subsystem: mingw32
Package: mingw32-dos2unix Subsystem: mingw32
Package: mingw32-expat Subsystem: mingw32
Package: mingw32-gcc Subsystem: mingw32
Package: mingw32-gcc-ada Subsystem: mingw32
Package: mingw32-gcc-fortran Subsystem: mingw32
Package: mingw32-gcc-g++ Subsystem: mingw32
Package: mingw32-gcc-objc Subsystem: mingw32
Package: mingw32-gcc-tools-epoch2-autoconf Subsystem: mingw32
Package: mingw32-gcc-tools-epoch2-automake Subsystem: mingw32
Package: mingw32-gcc-v3-ada Subsystem: mingw32
Package: mingw32-gcc-v3-core Subsystem: mingw32
Package: mingw32-gcc-v3-fortran Subsystem: mingw32
Package: mingw32-gcc-v3-g++ Subsystem: mingw32
Package: mingw32-gcc-v3-java Subsystem: mingw32
Package: mingw32-gcc-v3-objc Subsystem: mingw32
Package: mingw32-gdb Subsystem: mingw32
Package: mingw32-gdb-python Subsystem: mingw32
Package: mingw32-gendef Subsystem: mingw32
Package: mingw32-gettext Subsystem: mingw32
Package: mingw32-gmp Subsystem: mingw32
Package: mingw32-libarchive Subsystem: mingw32
Package: mingw32-libasprintf Subsystem: mingw32
Package: mingw32-libatomic Subsystem: mingw32
Package: mingw32-libbz2 Subsystem: mingw32
Package: mingw32-libcharset Subsystem: mingw32
Package: mingw32-libexpat Subsystem: mingw32
Package: mingw32-libgcc Subsystem: mingw32
Package: mingw32-libgettextpo Subsystem: mingw32
Package: mingw32-libgfortran Subsystem: mingw32
Package: mingw32-libgmp Subsystem: mingw32
Package: mingw32-libgmpxx Subsystem: mingw32
Package: mingw32-libgnat Subsystem: mingw32
Package: mingw32-libgomp Subsystem: mingw32
Package: mingw32-libiconv Subsystem: mingw32
Package: mingw32-libintl Subsystem: mingw32
Package: mingw32-libltdl Subsystem: mingw32
Package: mingw32-liblzma Subsystem: mingw32
Package: mingw32-libminizip Subsystem: mingw32
Package: mingw32-libmpc Subsystem: mingw32
Package: mingw32-libmpfr Subsystem: mingw32
Package: mingw32-libncurses Subsystem: mingw32
Package: mingw32-libobjc Subsystem: mingw32
Package: mingw32-libpdcurses Subsystem: mingw32
Package: mingw32-libpopt Subsystem: mingw32
Package: mingw32-libpthread-old Subsystem: mingw32
Package: mingw32-libpthreadgc Subsystem: mingw32
Package: mingw32-libpthreadgce Subsystem: mingw32
Package: mingw32-libquadmath Subsystem: mingw32
Package: mingw32-libquserex Subsystem: mingw32
Package: mingw32-libssp Subsystem: mingw32
Package: mingw32-libstdc++ Subsystem: mingw32
Package: mingw32-libtool Subsystem: mingw32
Package: mingw32-libunistring Subsystem: mingw32
Package: mingw32-libz Subsystem: mingw32
Package: mingw32-lua Subsystem: mingw32
Package: mingw32-make Subsystem: mingw32
Package: mingw32-mgwport Subsystem: mingw32
Package: mingw32-mingw-get Subsystem: mingw32
Package: mingw32-mingw-utils Subsystem: mingw32
Package: mingw32-mingwrt Subsystem: mingw32
Package: mingw32-minizip Subsystem: mingw32
Package: mingw32-mpc Subsystem: mingw32
Package: mingw32-mpfr Subsystem: mingw32
Package: mingw32-ncurses Subsystem: mingw32
Package: mingw32-pdcurses Subsystem: mingw32
Package: mingw32-pexports Subsystem: mingw32
Package: mingw32-pkginfo Subsystem: mingw32
Package: mingw32-popt Subsystem: mingw32
Package: mingw32-pthreads-w32 Subsystem: mingw32
Package: mingw32-tcl Subsystem: mingw32
Package: mingw32-terminfo Subsystem: mingw32
Package: mingw32-tk Subsystem: mingw32
Package: mingw32-w32api Subsystem: mingw32
Package: mingw32-wsl_rc Subsystem: mingw32
Package: mingw32-xerces-c Subsystem: mingw32
Package: mingw32-xz Subsystem: mingw32
Package: mingw32-zlib Subsystem: mingw32
Package: msys-autoconf Subsystem: msys
Package: msys-autogen Subsystem: msys
Package: msys-automake Subsystem: msys
Package: msys-base Subsystem: msys
Package: msys-bash Subsystem: msys
Package: msys-binutils Subsystem: msys
Package: msys-bison Subsystem: msys
Package: msys-bsdcpio Subsystem: msys
Package: msys-bsdtar Subsystem: msys
Package: msys-bzip2 Subsystem: msys
Package: msys-console Subsystem: msys
Package: msys-core Subsystem: msys
Package: msys-coreutils Subsystem: msys
Package: msys-crypt Subsystem: msys
Package: msys-cvs Subsystem: msys
Package: msys-cygutils Subsystem: msys
Package: msys-dash Subsystem: msys
Package: msys-diffstat Subsystem: msys
Package: msys-diffutils Subsystem: msys
Package: msys-dos2unix Subsystem: msys
Package: msys-expat Subsystem: msys
Package: msys-file Subsystem: msys
Package: msys-findutils Subsystem: msys
Package: msys-flex Subsystem: msys
Package: msys-gawk Subsystem: msys
Package: msys-gcc Subsystem: msys
Package: msys-gdbm Subsystem: msys
Package: msys-gettext Subsystem: msys
Package: msys-gmp Subsystem: msys
Package: msys-grep Subsystem: msys
Package: msys-groff Subsystem: msys
Package: msys-guile Subsystem: msys
Package: msys-gzip Subsystem: msys
Package: msys-help2man Subsystem: msys
Package: msys-inetutils Subsystem: msys
Package: msys-less Subsystem: msys
Package: msys-libarchive Subsystem: msys
Package: msys-libasprintf Subsystem: msys
Package: msys-libbz2 Subsystem: msys
Package: msys-libcharset Subsystem: msys
Package: msys-libcrypt Subsystem: msys
Package: msys-libexpat Subsystem: msys
Package: msys-libgdbm Subsystem: msys
Package: msys-libgettextpo Subsystem: msys
Package: msys-libgmp Subsystem: msys
Package: msys-libguile Subsystem: msys
Package: msys-libiconv Subsystem: msys
Package: msys-libintl Subsystem: msys
Package: msys-libltdl Subsystem: msys
Package: msys-liblzma Subsystem: msys
Package: msys-libmagic Subsystem: msys
Package: msys-libminires Subsystem: msys
Package: msys-libminizip Subsystem: msys
Package: msys-libncurses Subsystem: msys
Package: msys-libopenssl Subsystem: msys
Package: msys-libopts Subsystem: msys
Package: msys-libpopt Subsystem: msys
Package: msys-libregex Subsystem: msys
Package: msys-libtermcap Subsystem: msys
Package: msys-libtool Subsystem: msys
Package: msys-libxml2 Subsystem: msys
Package: msys-lndir Subsystem: msys
Package: msys-locate Subsystem: msys
Package: msys-lpr-enhanced Subsystem: msys
Package: msys-m4 Subsystem: msys
Package: msys-make Subsystem: msys
Package: msys-man Subsystem: msys
Package: msys-minires Subsystem: msys
Package: msys-minizip Subsystem: msys
Package: msys-mintty Subsystem: msys
Package: msys-mksh Subsystem: msys
Package: msys-mktemp Subsystem: msys
Package: msys-ncurses Subsystem: msys
Package: msys-openssh Subsystem: msys
Package: msys-openssl Subsystem: msys
Package: msys-patch Subsystem: msys
Package: msys-perl Subsystem: msys
Package: msys-popt Subsystem: msys
Package: msys-rebase Subsystem: msys
Package: msys-regex Subsystem: msys
Package: msys-rsync Subsystem: msys
Package: msys-rxvt Subsystem: msys
Package: msys-sed Subsystem: msys
Package: msys-system-builder Subsystem: msys
Package: msys-tar Subsystem: msys
Package: msys-termcap Subsystem: msys
Package: msys-terminfo Subsystem: msys
Package: msys-texinfo Subsystem: msys
Package: msys-tiny Subsystem: msys
Package: msys-unzip Subsystem: msys
Package: msys-vim Subsystem: msys
Package: msys-w32api Subsystem: msys
Package: msys-wget Subsystem: msys
Package: msys-xz Subsystem: msys
Package: msys-zip Subsystem: msys
Package: msys-zlib Subsystem: msys

IIRC "Subsystem" indicates where to install (unpack) the package files.
The directory tree is a little weird (for instance:
/c/MinGW/msys/1.0/bin/... etc.).

This is a list of my package cache with (maybe installed or not) package
files:

$ ls -1 /c/MinGW/var/cache/mingw-get/packages/
autoconf-10-1-mingw32-bin.tar.lzma
autoconf2.1-2.13-4-mingw32-bin.tar.lzma
autoconf2.5-2.68-1-mingw32-bin.tar.lzma
autogen-5.10.1-1-msys-1.0.15-bin.tar.lzma
automake-4-1-mingw32-bin.tar.lzma
automake1.10-1.10.2-1-mingw32-bin.tar.lzma
automake1.11-1.11.1-1-mingw32-bin.tar.lzma
automake1.4-1.4p6-1-mingw32-bin.tar.lzma
automake1.5-1.5-1-mingw32-bin.tar.lzma
automake1.6-1.6.3-1-mingw32-bin.tar.lzma
automake1.7-1.7.9-1-mingw32-bin.tar.lzma
automake1.8-1.8.5-1-mingw32-bin.tar.lzma
automake1.9-1.9.6-3-mingw32-bin.tar.lzma
bash-3.1.23-1-msys-1.0.18-bin.tar.xz
binutils-2.25.1-1-mingw32-bin.tar.xz
bison-2.4.2-1-msys-1.0.13-bin.tar.lzma
bsdcpio-2.8.3-1-msys-1.0.13-bin.tar.lzma
bsdtar-2.8.3-1-msys-1.0.13-bin.tar.lzma
bzip2-1.0.6-1-msys-1.0.17-bin.tar.lzma
coreutils-5.97-3-msys-1.0.13-bin.tar.lzma
coreutils-5.97-3-msys-1.0.13-ext.tar.lzma
cvs-1.12.13-2-msys-1.0.13-bin.tar.lzma
dash-0.5.5.1_2-1-msys-1.0.13-bin.tar.lzma
diffstat-1.54-1-msys-1.0.17-bin.tar.lzma
diffutils-2.8.7.20071206cvs-3-msys-1.0.13-bin.tar.lzma
dos2unix-7.3.2-1-msys-1.0.18-bin.tar.lzma
expat-2.1.0-1-mingw32-dll.tar.lzma
file-5.04-1-msys-1.0.13-bin.tar.lzma
findutils-4.4.2-2-msys-1.0.13-bin.tar.lzma
flex-2.5.35-2-msys-1.0.13-bin.tar.lzma
gawk-3.1.7-2-msys-1.0.13-bin.tar.lzma
gcc-5.3.0-2-mingw32-lic.tar.xz
gcc-5.3.0-3-mingw32-lic.tar.xz
gcc-c++-5.3.0-2-mingw32-bin.tar.xz
gcc-c++-5.3.0-3-mingw32-bin.tar.xz
gcc-core-5.3.0-2-mingw32-bin.tar.xz
gcc-core-5.3.0-3-mingw32-bin.tar.xz
gcc-objc-5.3.0-2-mingw32-bin.tar.xz
gcc-objc-5.3.0-3-mingw32-bin.tar.xz
gdb-7.6.1-1-mingw32-bin.tar.lzma
gettext-0.18.3.2-2-mingw32-bin.tar.xz
gettext-0.18.3.2-2-mingw32-dev.tar.xz
gmp-5.1.2-1-mingw32-dll.tar.lzma
grep-2.5.4-2-msys-1.0.13-bin.tar.lzma
groff-1.20.1-2-msys-1.0.13-bin.tar.lzma
guile-1.8.7-2-msys-1.0.15-bin.tar.lzma
gzip-1.3.12-2-msys-1.0.13-bin.tar.lzma
inetutils-1.7-1-msys-1.0.13-bin.tar.lzma
less-436-2-msys-1.0.13-bin.tar.lzma
libarchive-2.8.3-1-msys-1.0.13-dll-2.tar.lzma
libatomic-5.3.0-2-mingw32-dll-1.tar.xz
libatomic-5.3.0-3-mingw32-dll-1.tar.xz
libbz2-1.0.6-1-msys-1.0.17-dll-1.tar.lzma
libcrypt-1.1_1-3-msys-1.0.13-dll-0.tar.lzma
libexpat-2.0.1-1-msys-1.0.13-dll-1.tar.lzma
libgcc-5.3.0-2-mingw32-dll-1.tar.xz
libgcc-5.3.0-3-mingw32-dll-1.tar.xz
libgdbm-1.8.3-3-msys-1.0.13-dll-3.tar.lzma
libgettextpo-0.18.3.2-2-mingw32-dll-0.tar.xz
libgmp-5.0.1-1-msys-1.0.13-dll-10.tar.lzma
libgomp-5.3.0-2-mingw32-dll-1.tar.xz
libgomp-5.3.0-3-mingw32-dll-1.tar.xz
libguile-1.8.7-2-msys-1.0.15-dll-17.tar.lzma
libguile-1.8.7-2-msys-1.0.15-rtm.tar.lzma
libiconv-1.14-1-msys-1.0.17-dll-2.tar.lzma
libiconv-1.14-3-mingw32-bin.tar.lzma
libiconv-1.14-3-mingw32-dev.tar.lzma
libiconv-1.14-3-mingw32-dll.tar.lzma
libintl-0.18.1.1-1-msys-1.0.17-dll-8.tar.lzma
libintl-0.18.3.2-2-mingw32-dll-8.tar.xz
libltdl-2.4-1-mingw32-dev.tar.lzma
libltdl-2.4-1-mingw32-dll-7.tar.lzma
libltdl-2.4-1-msys-1.0.15-dll-7.tar.lzma
liblzma-5.0.3-1-msys-1.0.17-dll-5.tar.lzma
libmagic-5.04-1-msys-1.0.13-dll-1.tar.lzma
libminires-1.02_1-2-msys-1.0.13-dll.tar.lzma
libmpc-1.0.2-mingw32-dll-3.tar.xz
libobjc-5.3.0-2-mingw32-dll-4.tar.xz
libobjc-5.3.0-3-mingw32-dll-4.tar.xz
libopenssl-1.0.0-1-msys-1.0.13-dll-100.tar.lzma
libopts-5.10.1-1-msys-1.0.15-dll-25.tar.lzma
libpopt-1.15-2-msys-1.0.13-dll-0.tar.lzma
libquadmath-5.3.0-2-mingw32-dll-0.tar.xz
libquadmath-5.3.0-3-mingw32-dll-0.tar.xz
libregex-1.20090805-2-msys-1.0.13-dll-1.tar.lzma
libssp-5.3.0-2-mingw32-dll-0.tar.xz
libssp-5.3.0-3-mingw32-dll-0.tar.xz
libstdc++-5.3.0-2-mingw32-dll-6.tar.xz
libstdc++-5.3.0-3-mingw32-dll-6.tar.xz
libtermcap-0.20050421_1-2-msys-1.0.13-dll-0.tar.lzma
libtool-2.4-1-mingw32-bin.tar.lzma
libxml2-2.7.6-1-msys-1.0.13-dll-2.tar.lzma
lndir-1.0.1-2-msys-1.0.13-bin.tar.lzma
m4-1.4.16-2-msys-1.0.17-bin.tar.lzma
make-3.81-3-msys-1.0.13-bin.tar.lzma
make-3.82.90-2-mingw32-cvs-20120902-bin.tar.lzma
man-1.6f-2-msys-1.0.13-bin.tar.lzma
man-1.6f-2-msys-1.0.13-doc.tar.lzma
man-1.6f-2-msys-1.0.13-lang.tar.lzma
man-1.6f-2-msys-1.0.13-lic.tar.lzma
mingw-get-0.6.2-mingw32-beta-20131004-1-bin.tar.xz
mingw-get-0.6.2-mingw32-beta-20131004-1-gui.tar.xz
mingw-get-0.6.2-mingw32-beta-20131004-1-lic.tar.xz
mingw-get-setup-0.6.2-mingw32-beta-20131004-1-dll.tar.xz
mingw-get-setup-0.6.2-mingw32-beta-20131004-1-xml.tar.xz
mingwrt-3.22.4-mingw32-dev.tar.xz
mingwrt-3.22.4-mingw32-dll.tar.xz
mintty-1.0.3-1-msys-1.0.17-bin.tar.lzma
mktemp-1.6-2-msys-1.0.13-bin.tar.lzma
mpfr-3.1.2-2-mingw32-dll.tar.lzma
msysCORE-1.0.19-1-msys-1.0.19-bin.tar.xz
msysCORE-1.0.19-1-msys-1.0.19-doc.tar.xz
msysCORE-1.0.19-1-msys-1.0.19-ext.tar.xz
msysCORE-1.0.19-1-msys-1.0.19-lic.tar.xz
openssh-5.4p1-1-msys-1.0.13-bin.tar.lzma
openssl-1.0.0-1-msys-1.0.13-bin.tar.lzma
patch-2.6.1-1-msys-1.0.13-bin.tar.lzma
perl-5.8.8-1-msys-1.0.17-bin.tar.lzma
pthreads-GC-w32-2.10-mingw32-pre-20160821-1-dev.tar.xz
pthreads-GC-w32-2.10-mingw32-pre-20160821-1-dll-3.tar.xz
rebase-4.0.1_1-1-msys-1.0.17-bin.tar.lzma
rsync-3.0.8-1-msys-1.0.17-bin.tar.lzma
sed-4.2.1-2-msys-1.0.13-bin.tar.lzma
tar-1.23-1-msys-1.0.13-bin.tar.lzma
termcap-0.20050421_1-2-msys-1.0.13-bin.tar.lzma
texinfo-4.13a-2-msys-1.0.13-bin.tar.lzma
unzip-6.0-1-msys-1.0.13-bin.tar.lzma
vim-7.3-2-msys-1.0.16-bin.tar.lzma
w32api-3.18.2-mingw32-dev.tar.xz
wget-1.12-1-msys-1.0.13-bin.tar.lzma
xz-5.0.3-1-msys-1.0.17-bin.tar.lzma
zip-3.0-1-msys-1.0.14-bin.tar.lzma
zlib-1.2.7-1-msys-1.0.17-dll.tar.lzma
zlib-1.2.8-1-mingw32-dll.tar.lzma

I don't know if this can help you, but that's probably all I can do.

[sri...@gmail.com]

The minimum packages required for mingw to be downloaded from mingw.org manually are:

gcc-core
gcc-core-4.8.1-4-mingw32-bin.tar.lzma
gcc-core-4.8.1-4-mingw32-dev.tar.lzma
gcc-core-4.8.1-4-mingw32-dll.tar.lzma
gcc-core-4.8.1-4-mingw32-lic.tar.lzma

binutils
binutils-2.24-1-mingw32-bin.tar.xz

mingwrt
mingwrt-3.21-mingw32-dev.tar.xz
mingwrt-3.21-mingw32-dll.tar.xz

w32api
w32api-3.17-2-mingw32-dev.tar.lzma

putting them in a folder , say ,D:\mingw32
and unzipping using 7zip will have a working gcc for windows.

[Pál Ács]

Thank you for the tips.

I finally managed to install MinGW 5.1.4. This is the version Dillo for Win32 was built with. I applied Albrecht's patch and executed. C:\MinGW32\bin was in %PATH%.

cmake -G"MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release -DOPTION_OPTIM:STRING="-D'WINVER=0x0400' -D'_WIN32_WINNT=0x0400'" -DCMAKE_EXE_LINKER_FLAGS="-static-libgcc-static-libstdc++" c:/FLTK/fltk-1.3.4-1

Got this one.

c:\FLTK\build>mingw32-make
[  0%] Building C object zlib/CMakeFiles/fltk_z.dir/adler32.c.obj
<command line>:6:1: macro names must be identifiers
<command line>:7:1: macro names must be identifiers
mingw32-make[2]: *** [zlib/CMakeFiles/fltk_z.dir/adler32.c.obj] Error 1
mingw32-make[1]: *** [zlib/CMakeFiles/fltk_z.dir/all] Error 2
mingw32-make: *** [all] Error 2

Is this some mistake by me or MinGW 5.1.4 is too old for the current FLTK?

[Albrecht Schlosser]

On 01.03.2017 15:05 Pál Ács wrote:
> Thank you for the tips.
>
> I finally managed to install MinGW 5.1.4. This is the version Dillo for
> Win32 was built with. I applied Albrecht's patch and executed.

> *C:\MinGW32\bin* was in *%PATH%*.

>
> cmake -G"MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release
> -DOPTION_OPTIM:STRING="-D'WINVER=0x0400' -D'_WIN32_WINNT=0x0400'"
> -DCMAKE_EXE_LINKER_FLAGS="-static-libgcc-static-libstdc++"
> c:/FLTK/fltk-1.3.4-1

There's a space missing between -static-libgcc and -static-libstdc++, or
is this only a mail/copy-and-paste error?

> Got this one.
>
> c:\FLTK\build>mingw32-make
> [ 0%] Building C object zlib/CMakeFiles/fltk_z.dir/adler32.c.obj
> <command line>:6:1: macro names must be identifiers
> <command line>:7:1: macro names must be identifiers
> mingw32-make[2]: *** [zlib/CMakeFiles/fltk_z.dir/adler32.c.obj] Error 1
> mingw32-make[1]: *** [zlib/CMakeFiles/fltk_z.dir/all] Error 2
> mingw32-make: *** [all] Error 2
>
>
> Is this some mistake by me or MinGW 5.1.4 is too old for the current FLTK?

See above. If this doesn't fix it try:

$ mingw32-make VERBOSE=1

This should print the entire command line so we (you) can see more, i.e.
see what commands CMake generated.

[Pál Ács]

It was a copy-paste mistake. Sorry about that.

Verbose output as follows.

"C:\Program Files\CMake\bin\cmake.exe" -HC:\FLTK\fltk-1.3.4-1 -BC:\FLTK\build --check-build-system CMakeFiles\Makefile.cmake 0
"C:\Program Files\CMake\bin\cmake.exe" -E cmake_progress_start C:\FLTK\build\CMakeFiles C:\FLTK\build\CMakeFiles\progress.marks
mingw32-make -f CMakeFiles\Makefile2 all
mingw32-make[1]: Entering directory `c:/FLTK/build'
mingw32-make -f zlib\CMakeFiles\fltk_z.dir\build.make zlib/CMakeFiles/fltk_z.dir/depend
mingw32-make[2]: Entering directory `c:/FLTK/build'
"C:\Program Files\CMake\bin\cmake.exe" -E cmake_depends "MinGW Makefiles" C:\FLTK\fltk-1.3.4-1 C:\FLTK\fltk-1.3.4-1\zlib C:\FLTK\build C:\FLTK\build\zlib C:\FLTK\build\zlib\CMakeFiles\fltk_z.dir\DependInfo.cmake --color=
mingw32-make[2]: Leaving directory `c:/FLTK/build'
mingw32-make -f zlib\CMakeFiles\fltk_z.dir\build.make zlib/CMakeFiles/fltk_z.dir/build
mingw32-make[2]: Entering directory `c:/FLTK/build'

[  0%] Building C object zlib/CMakeFiles/fltk_z.dir/adler32.c.obj

cd /d C:\FLTK\build\zlib && C:\MinGW32\bin\gcc.exe -DFL_LIBRARY -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -IC:\FLTK\build -IC:\FLTK\fltk-1.3.4-1  -O3 -DNDEBUG   -D'WINVER=0x0400' -D'_WIN32_WINNT=0x0400' -o CMakeFiles\fltk_z.dir\adler32.c.obj   -c C:\FLTK\fltk-1.3.4-1\zlib\adler32.c

<command line>:6:1: macro names must be identifiers
<command line>:7:1: macro names must be identifiers
mingw32-make[2]: *** [zlib/CMakeFiles/fltk_z.dir/adler32.c.obj] Error 1

mingw32-make[2]: Leaving directory `c:/FLTK/build'

mingw32-make[1]: *** [zlib/CMakeFiles/fltk_z.dir/all] Error 2

mingw32-make[1]: Leaving directory `c:/FLTK/build'

[Albrecht Schlosser]

On 01.03.2017 16:30 Pál Ács wrote:
>
> Verbose output as follows.
> ...

> [ 0%] Building C object zlib/CMakeFiles/fltk_z.dir/adler32.c.obj
> cd /d C:\FLTK\build\zlib && C:\MinGW32\bin\gcc.exe -DFL_LIBRARY
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
> -IC:\FLTK\build -IC:\FLTK\fltk-1.3.4-1 -O3 -DNDEBUG
> -D'WINVER=0x0400' -D'_WIN32_WINNT=0x0400' -o

Looks like the quoting around WINVER=0x0400 and _WIN32_WINNT=0x0400 in
the above line got preserved when sent to the compiler (other than when
running from the commandline). So this may be my mistake when I posted
the CMake configure commandline (or it worked for me because I use the
MSYS gcc, whereas yours is mingw32-gcc). Or something like that.

Try to use the CMake configure line without these extra quotes or edit
the corresponding variable in CMake. CMake configure might look like this:

cmake -G"MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release

-DOPTION_OPTIM:STRING="-DWINVER=0x0400 -D_WIN32_WINNT=0x0400"

-DCMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++"
c:/FLTK/fltk-1.3.4-1

Hope this works...

BTW: I'd suggest using CMAKE_BUILD_TYPE=Debug instead of Release, but YMMV.

[Pál Ács]

It must be some parse error somewhere in the toolkit, because your example will be transformed in the following way, which is wrong I guess.

... -DWINVER="0x0400 -D_WIN32_WINNT=0x0400" ...

It is still okay in the output of cmake -LH so it is not supposed to be ruined by cmd.exe parameter passing.

// No help, variable specified on the command line.
OPTION_OPTIM:STRING=-DWINVER=0x0400 -D_WIN32_WINNT=0x0400

... but a full command line for a source file being compiled would look like this.

cd /d C:\FLTK\build\zlib && C:\MinGW32\bin\gcc.exe -DFL_LIBRARY -DWINVER="0x0400 -D_WIN32_WINNT=0x0400" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -IC:\FLTK\build -IC:\FLTK\fltk-1.3.4-1  -O3 -DNDEBUG   -o CMakeFiles\fltk_z.dir\gzwrite.c.obj   -c C:\FLTK\fltk-1.3.4-1\zlib\gzwrite.c

If I only specify WINVER, it's ok. It seems to break at the space character.

[chris]

Am 01.03.2017 um 16:30 schrieb Pál Ács:
> It was a copy-paste mistake. Sorry about that.
>
> Verbose output as follows.
>
> "C:\Program Files\CMake\bin\cmake.exe" -HC:\FLTK\fltk-1.3.4-1
> -BC:\FLTK\build --check-build-system CMakeFiles\Makefile.cmake 0
> "C:\Program Files\CMake\bin\cmake.exe" -E cmake_progress_start
> C:\FLTK\build\CMakeFiles C:\FLTK\build\CMakeFiles\progress.marks
> mingw32-make -f CMakeFiles\Makefile2 all
> mingw32-make[1]: Entering directory `c:/FLTK/build'
> mingw32-make -f zlib\CMakeFiles\fltk_z.dir\build.make
> zlib/CMakeFiles/fltk_z.dir/depend
> mingw32-make[2]: Entering directory `c:/FLTK/build'
> "C:\Program Files\CMake\bin\cmake.exe" -E cmake_depends "MinGW
> Makefiles" C:\FLTK\fltk-1.3.4-1 C:\FLTK\fltk-1.3.4-1\zlib
> C:\FLTK\build C:\FLTK\build\zlib
> C:\FLTK\build\zlib\CMakeFiles\fltk_z.dir\DependInfo.cmake --color=
> mingw32-make[2]: Leaving directory `c:/FLTK/build'
> mingw32-make -f zlib\CMakeFiles\fltk_z.dir\build.make
> zlib/CMakeFiles/fltk_z.dir/build
> mingw32-make[2]: Entering directory `c:/FLTK/build'

> [ 0%] Building C object zlib/CMakeFiles/fltk_z.dir/adler32.c.obj

> cd /d C:\FLTK\build\zlib && C:\MinGW32\bin\gcc.exe -DFL_LIBRARY

> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
> -IC:\FLTK\build -IC:\FLTK\fltk-1.3.4-1 -O3 -DNDEBUG

> -D'WINVER=0x0400' -D'_WIN32_WINNT=0x0400' -o

> CMakeFiles\fltk_z.dir\adler32.c.obj -c
> C:\FLTK\fltk-1.3.4-1\zlib\adler32.c
> <command line>:6:1: macro names must be identifiers
> <command line>:7:1: macro names must be identifiers
> mingw32-make[2]: *** [zlib/CMakeFiles/fltk_z.dir/adler32.c.obj] Error 1
> mingw32-make[2]: Leaving directory `c:/FLTK/build'
> mingw32-make[1]: *** [zlib/CMakeFiles/fltk_z.dir/all] Error 2
> mingw32-make[1]: Leaving directory `c:/FLTK/build'
> mingw32-make: *** [all] Error 2
>

Judging only from the error message my guess is that it maybe does not
like the ' characters around the -D values:

-D'WINVER=0x0400' -D'_WIN32_WINNT=0x0400'

try without them i.e. -DWINVER=0x0400 -D_WIN32_WINNT=0x0400

[Pál Ács]

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. 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.

[Pál Ács]

It doesn't work either what chris was talking about. For the same reason.

[Pál Ács]

Thank you for the tips, Ian MacArthur.

I'm sorry to say but CMAKE+MinGW combo has become a disappointment for me. However, I did some tests using MSVC and had some success.

As I have already mentioned, MSVC 6.0 won't compile the latest FLTK codebase.

This is why I tried MSVC 7.0. I took fltk-1.3.4-1, patched it with Albrecht's attachment and used ide/VisualC6/fltk.dsw for the build.

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.

So there must be another thing to be patched in the codebase to work with NT4. It works under Windows XP.

[Pál Ács]

Forgot to mention that MSVC 7.0 (released under the name Visual Studio .NET 2003) fully supports Windows 95.

[Pál Ács]

In reply to a post by Ian MacArthur.

Well, I will have to put together a Windows 95 test environment with debugger and symbols. It will take some of my time. I'll get back soon.

[Ian MacArthur]

On Mon Mar 06 2017 16:31:54, Pál Ács wrote:

In reply to a post by Ian MacArthur.

Well, I will have to put together a Windows 95 test environment with debugger and symbols. It will take some of my time. I'll get back soon.

I haven’t used the MS debugger for many years - can it attach to a remote target like gdb does?

When I’ve been debugging stuff like this, I have used gdb, running on my host machine, to access a failing instance of my code instance in a VM in the past and it pretty much Just Worked; can the MS debugger do the same? If so, attaching from the VS2007 IDE to the target running on your Win95 VM might be relatively painless?

[mune michi]

2017年2月19日日曜日 3時52分13秒 UTC+9 Pál Ács:

Hi,

I would like to develop an application that would be used in a legacy environment (specifically Windows 95 and 98). Installing external enhancements like KernelEx are not an option. I tried to solve this in the following ways.

• Tried to compile FLTK with Visual Studio 6.0. This is the last Visual Studio that officially supports Windows 95. I suppose it is supported because there are VS 6.0 workspace files in the ide/VisualC6 folder. I started VS 6.0, then loaded the workspace file ide/VisualC6/fltk.dsw. It loaded successfully. However, when I tried to build FLTK it gave me errors like this.

Fl_Scroll.cxx

../..\FL/Fl_Image.H(58) : error C2258: illegal pure syntax, must be '= 0'

../..\FL/Fl_Image.H(58) : error C2252: 'ERR_NO_IMAGE' : pure specifier can only be specified for functions

../..\FL/Fl_Image.H(59) : error C2258: illegal pure syntax, must be '= 0'

../..\FL/Fl_Image.H(59) : error C2252: 'ERR_FILE_ACCESS' : pure specifier can only be specified for functions

../..\FL/Fl_Image.H(60) : error C2258: illegal pure syntax, must be '= 0'

../..\FL/Fl_Image.H(60) : error C2252: 'ERR_FORMAT' : pure specifier can only be specified for functions

../..\FL/Fl_Device.H(121) : error C2258: illegal pure syntax, must be '= 0'

../..\FL/Fl_Device.H(121) : error C2252: 'matrix_stack_size' : pure specifier can only be specified for functions

../..\FL/Fl_Device.H(129) : error C2258: illegal pure syntax, must be '= 0'

../..\FL/Fl_Device.H(129) : error C2252: 'region_stack_max' : pure specifier can only be specified for functions

At almost all FL_* base classes. I suppose this is some kind of incompatibility, as MSVC 6 would expect a stricter or different syntax than these declarations were made with. Since I didn't know what to do about these errors, I gave up on MSVC 6.0.

• My next candidate was MinGW. I tried with the latest MinGW (using the online installer from mingw.org). It did not work. Then I also tried an older version of MinGW-w64 (a 32-bit i686 build of it) version 4.8.1. In both cases I got the following kinds of errors.
  
  
  
  
  

I think I should somehow tell MinGW not to use these calls to the Windows API for they're not present in the NT kernel of Windows 95. However, I don't know how. So I gave up. However, somehow it must be possible with MinGW because Dillo for Win32 uses FLTK and it runs on my Windows 95 test environment without problems.

Any thoughts on this?

Is there anyone who has an experience building for an ancient system like Windows 95?

Best,

Pál Tamás Ács

hello

I also  trying to Make fltk-1.3.3 on my Windows95 with MinGW5.1.4.

But I had error in FLUID directory.

Fluid.exe is compiled and exist. But in Make script, converting from *.fl to *.cxx and *.h with fluid.exe part had error.

I can RUN fluid.exe on Windows95 independently with no error but when open file witth MENU, I had error "Can't read file. Bad file descriptor".

Please give me any advise.

[Ian MacArthur]

> On 19 May 2020, at 14:56, mune michi wrote:
>
>
> I also trying to Make fltk-1.3.3 on my Windows95 with MinGW5.1.4.
> But I had error in FLUID directory.
> Fluid.exe is compiled and exist. But in Make script, converting from *.fl to *.cxx and *.h with fluid.exe part had error.
> I can RUN fluid.exe on Windows95 independently with no error but when open file witth MENU, I had error "Can't read file. Bad file descriptor".
> Please give me any advise.
>

Fltk-1.3.3 is very unlikely to run on Win95, unless you make a fair number of adjustments to the fltk code (as discussed in the thread you found.)

You could try following the ideas in that thread and see how you get on, but I don’t believe it would be all that likely to work.

If you try an older version of fltk, say 1.1.10, that stands a much higher chance of working on Win95, but it is pretty old and does not easily handle non-ASCII text rendering (it uses the older codepages approach to multilingual support on Windows, rather than the UTF-8 approach that fltk-1.3 follows.)

There were forks of fltk-1.1 to better support internationalisation of text handling, notably the fltk-1.2 experimental branch and O’ksi’D-fltk-1.1.6 fork, but they are long since abandoned, and even then need some text handling capabilities that are not present in Win95 by default (they were added as services patches as Win95 progressed; in some cases as service patches to IE rather than to Win95 itself, so...)

And you would need to find a compiler toolchain that works for Win95 too, of course, since many modern ones may not easily produce Win95 compatible binaries...

[Anon Mouse]

>I can RUN fluid.exe on Windows95 independently with no error but when open file witth MENU, 

>I had error "Can't read file. Bad file descriptor".

>Please give me any advise.

As Ian MacArthur mentions, FLTK 1.3.x supports UTF-8, and that applies to filenames as well.

First, I'd confirm that the error is taking place in fluid.cxx, the open_cb() function. There is a fl_message() that occurs when the function read_file() fails.

If that is indeed where the error message comes from, then I'd suggest you try modifying the fl_open() function in fl_utf8.cxx. Change it so that it merely calls fopen() [instead of the code which converts the filename from Utf8 to Utf16]. 

 

A caveat: I'm looking at the 1.3.5 code, there may be some differences versus 1.3.3.

[mune michi]

Thank you very much for answers.

It's difficult so much to compile FLTK-1.3.3 for Windows95 for me.

I have no programing skill and I can't edit source code.

It's big problem that UTF-8 on Windows95 (Unicows.dll and libunicows?) and how FLTK-1.3.x handling UTF-8 ,then how both of these related.First,I have to learn about it.

[imm]

Yes, it is very difficult using (even vaguely) modern tooling for Win95.

Win95 is very old now, 25 years is aeons in software development timescales.

May I ask *why* you want to use Win95? There are many better alternatives freely available these days, that will still run on ancient hardware and support modern tools.

-- 
Ian
From my Fairphone FP3
   

[Greg Ercolano]

On 2020-05-31 06:10, imm wrote:
> On Sun, 31 May 2020, 12:11 mune michi, wrote:
>
> Thank you very much for answers.
> It's difficult so much to compile FLTK-1.3.3 for Windows95 for me.

Yes, well fltk wasn't really designed to run on early versions
of windows.

> I have no programing skill and I can't edit source code.

Yikes, well you have a problem then; you might want to put out
a bounty for someone to assist you.

> It's big problem that UTF-8 on Windows95 (Unicows.dll and libunicows?)
> and how FLTK-1.3.x handling UTF-8 ,then how both of these related.
> First,I have to learn about it.

Well, UTF8 is the 8bit encoding of Unicode, which all operating systems
now use to support multiple languages.

But in the days of Win95, these encoding techniques were just being born;
Unicode in 1991, and UTF8 was around 1992 I think. And of course Win95
(1995) only a few years after that, so Microsoft would have been
implementing these things for the first time, if at all.

Note that UTF8 was added to fltk in 1.3.0.

You might want to go for the OLDER version of FLTK which won't have that
complexity. I believe we still have FLTK 1.1.10, the newest version of FLTK
that /doesnt/ have utf8/unicode.

So try giving fltk 1.1.10 a try, e.g.
https://www.fltk.org/pub/fltk/1.0.11/fltk-1.0.11-source.zip

You'll probably need either an older compiler from that same era
to get fltk 1.1.10 to compile properly, or know what flags to set
in newer versions of the compiler to silence errors/warnings.

Or, if Win95 seems to be missing utf8 stuff, and you want to go with
fltk 1.3.x, perhaps this add-on stuff from Microsoft is relevant:
https://www.microsoft.com/en-us/download/details.aspx?id=4237
"""
Platform Software Development Kit Redistributable: Microsoft Layer for Unicode on Windows 95, 98

The Microsoft Layer for Unicode on Windows 95, 98, and Me systems (MSLU) helps
to provide a layer over the Win32 API on Win9x so that you can write a single
Unicode version of your application.
"""

> Ian responds:

> Yes, it is very difficult using (even vaguely) modern tooling for Win95.
>
> Win95 is very old now, 25 years is aeons in software development timescales.
>
> May I ask *why* you want to use Win95?

I'm guessing if it's Win95, it's usually for industrial environments
that depend on old non-multiuser 16bit DOS mode and/or non-plug+play
ISA bus hardware.

Win95 and Win98 are the two versions of color oriented windows
that also support DOS based OS and windowing tools.

There's a lot of old machining/motion control software/hardware
that depends on DOS, and simply won't operate reliably in multitasking
environments where the software can't take full control of the cpu
from the operating system.

I run into this a lot writing and designing realtime motor control stuff.

That said, I usually don't design GUI tools for these environments,
but I could see where it would be beneficial.

> There are many better alternatives freely available these days, that will
> still run on ancient hardware and support modern tools.

Mmm, there's freedos, but I think that gets away from "windows".

I fully understand certain software's need to run on non-multiuser
operating systems. DOS is somewhat unique in that it gives over
the entire machine to the running process, and does not at all
get in the software's way.

And with the DPMI software installed, DOS programs can access above
1M of ram, and access the full 'protected mode' of the machine (32bit
instruction set, virtual addressing, paging, etc. but without multitasking)

[Ian MacArthur]

OK, fair enough. Been there, done that.

Well, what I actually ended up doing was having the “legacy” PC (at the core of the old machine) handle some limited command/status on RS-485 (think it was 485, might have been 422, or even RS-232... it was old...) and read that on a tiny dedicated industrial all-in-one display/PC combo (which was about one tenth the size and an order of magnitude more powerful than the “legacy” PC it was displaying for.)
We then set that display PC (which was running some embedded windows version in kiosk mode, might have been WinXPe, IIRC...) up with the GUI and Ethernet and all that fancy “modern" stuff...

The crux was that there was basically no way the old PC was ever going to run any GUI toolkit, or have the ability to drive a decent display, so...

I’m not sure if this is pertinent to the OP’s situation, but if it is, they really ought to try and do the same; trying the get an old PC to run a modern GUI is likely not worth the effort.
Unless you are actually into that sort of thing for a hobby (but if you are, then it’s likely you would also have the necessary chops to pull it off, so I’m guessing that’s not the case here...)