FPC: Windows 98 setup fail

[zx_gamer]

I tried to install FPC 3.2.2 to Windows 98 (win32) and got an error message "Update windows". Why? FPC supports even DOS.

[marcov]

Win9x has been formally abandoned since FPC 2.6.0, but versions up to 3.0.0 were basically hit and miss.

3.0.0 introduced unicode and that complicated win9x support, and a call for maintainers for a separate win9x port was done. There were no respondents. See e.g. https://forum.lazarus.freepascal.org/index.php/topic,30677.msg195427.html#msg195427

ZX spectrum, Amiga, go32v2 and Msdos, while older, do have people that test, maintain etc.

[Ten_Mile_Hike]

Code: Text  [Select][+][-]

1. I got a setup fail when installing into Temple OS... then I tried to install on GEM...still no luck!!!

[zx_gamer]

Win9x has been formally abandoned since FPC 2.6.0, but versions up to 3.0.0 were basically hit and miss.

3.0.0 introduced unicode and that complicated win9x support, and a call for maintainers for a separate win9x port was done. There were no respondents. See e.g. https://forum.lazarus.freepascal.org/index.php/topic,30677.msg195427.html#msg195427

ZX spectrum, Amiga, go32v2 and Msdos, while older, do have people that test, maintain etc.

Okay, can I try maintain FPC for Windows 9x? What should I do?

[Thaddy]

You should simply use an older version of FPC. Not fight donkeys.

[marcov]

Well, there is the question if it is worth the effort, but that goes for all vintage ports, so let's skip that for now. Except maybe that I hope that it is clear that it is a big job, and a long term commitment to develop a new target.  (win9x is a new target for the current compiler/codebase). This is not an one-off week work or so.

Some hints:

• The win9x port shouldn't hinder the win32/win64 port in anyway, so mostly is a wholly separated target with duplicates of every source.  But for your tests you can use the win32 target till the port is considered viable and well enough to define a target in the compiler etc
• Consider which versions you are going to support (from win 3.11+win32s up to ME)
• Consider what to do with unicode (kernelex, MSLU). Keep in mind that the RTL is fully unicode nowadays 
• Will it be native or crosscompile only?  fpmake is a threading application, and going crosscompile only means you won't have to fix fpmake for win9x. It also avoids problems in win9x with available memory.
• There might be work in the internal linker/assembler. I don't know about EXE format differences that are win9x specific and might be removed later on
• There is also the question where to get information from. Microsoft removed a lot of win9x info from MSDN. Probably start collecting Petzolds that apply to win9x
• The starting point would be to get the current (trunk) win32 RTL, and a copy of the win32 RTL from when win9x was still functional, and simply start hacking the current copy while looking at the old copy till it works.

[Thaddy]

I think the DOS port also basically supports any 16 bit Windows, like WIN98 so you may start there. Maybe just copy out the Windows stuff from an old release? That is because older Windows ran on top off DOS.
You may need an emulator for that, like dosbox.

[zx_gamer]

I think the DOS port also basically supports any 16 bit Windows, like WIN98 so you may start there. Maybe just copy out the Windows stuff from an old release? That is because older Windows ran on top off DOS.
You may need an emulator for that, like dosbox.

Windows 98 is Win32 system only. Windows 3.x MAY work on 16-bit systems without multitasking (only focused window works, other freezes).

[zx_gamer]

Well, there is the question if it is worth the effort, but that goes for all vintage ports, so let's skip that for now. Except maybe that I hope that it is clear that it is a big job, and a long term commitment to develop a new target.  (win9x is a new target for the current compiler/codebase). This is not an one-off week work or so.

Some hints:

• The win9x port shouldn't hinder the win32/win64 port in anyway, so mostly is a wholly separated target with duplicates of every source.  But for your tests you can use the win32 target till the port is considered viable and well enough to define a target in the compiler etc
• Consider which versions you are going to support (from win 3.11+win32s up to ME)
• Consider what to do with unicode (kernelex, MSLU). Keep in mind that the RTL is fully unicode nowadays 
• Will it be native or crosscompile only?  fpmake is a threading application, and going crosscompile only means you won't have to fix fpmake for win9x
• There might be work in the internal linker/assembler. I don't know about EXE format differences that are win9x specific and might be removed later on
• There is also the question where to get information from. Microsoft removed a lot of win9x info from MSDN. Probably start collecting Petzolds that apply to win9x
• The starting point would be to get the current (trunk) win32 RTL, and a copy of the win32 RTL from when win9x was still functional, and simply start hacking the current copy while looking at the old copy till it works.

I guess, application, which uses only WinAPI have same EXE file with Windows XP. The diffirenece is which functions are available in WinAPI in Windows 98.

[Thaddy]

Those are just the stubs for 16 bit support.
Marco is right, and I am right too:
You can either rewrite for the stubs (win98 is 16 bit) or use the DOS port, which already works as a cross compiler that executes in an emulator like dosbox. Performance is not an issue, if anything running under dosbox is faster....(I run win95 on Raspberry Pi's on dosbox..., since RPi 1.)

Anything else requires porting the application to 32 bit. Not the compiler.

[marcov]

(just let Thaddy waffle. He seems to likes the sound of his own uh, writing, so much that he reacts to everything, even if he doesn't know or remember much about it. He doesn't even seem to remember what OSes are 16-bit or not. As said, even Win3.1xx can be 32-bit (win 386 extended kernel mode, available since at least Windows 3.0, and support for 32-bit win32s apps since WFW 3.11 or so, and btw Thaddy, win9x _IS_ 32-bit)

I guess, application, which uses only WinAPI have same EXE file with Windows XP. The diffirenece is which functions are available in WinAPI in Windows 98.

This is only true for non unicode. That change, from using windows -A to -W API calls was one of the reasons for the debate about what to do with Windows 9x that ultimately lead to its abandonment.

Asking Windows developers for modern versions to make win9x alternative paths for each and every call was not considered feasible, specially because of a lot of win9x knowledge disappeared from the web. So it would take more than a simple google to find the authoritative MSDN page for a call.  This is the main reason for splitting out win9x as separate target.

Note that even in the old RTL there were workarounds with special code paths for Win9x, like getting specific directories (my documents, pictures, home etc), and some unicode/codepage related workarounds. Those were a pain, even back then.

[MarkMLl]

While I'm cautious dispensing second- or third-hand experience, I was told that the chap who implemented Win-16 for the JPI-TopSpeed compiler/IDE found it a most unpleasant experience because the API made what appeared to be random selection of which segment register to use for any parameter. In addition, when he got into the GDI he had to contend with "blitting" code being built on the stack and then executed in-situ.

I admit to being a bit of a fan of what is now called retrocomputing, but find myself wondering whether Win-16 would be best left alone.

I also find myself wondering whether a 32-bit Windows-98 compatible version of the compiler and RTL could be bootstrapped via something like Sanos. That was basically an experimental 32-bit "DOS" using standard .exe files etc., I looked briefly at the standard Win-32 FPC on it but there was already (in something like the 2.7 era) too much reliance on the Unicode API for it to be directly compatible. http://www.jbox.dk/sanos/index.htm

MarkMLl

[marcov]

While I'm cautious dispensing second- or third-hand experience, I was told that the chap who implemented Win-16 for the JPI-TopSpeed compiler/IDE found it a most unpleasant experience because the API made what appeared to be random selection of which segment register to use for any parameter. In addition, when he got into the GDI he had to contend with "blitting" code being built on the stack and then executed in-situ.

Luckily, win9x is mostly using the win32 API. The win16 port is something else.

I also find myself wondering whether a 32-bit Windows-98 compatible version of the compiler and RTL could be bootstrapped via something like Sanos

I don't see any relevance of Sanos as I try to read and get the gist of that site. So you will have to do a better job of explaining that. 

In practice you could crosscompile-and-bootstrap a new win9x FPC target from any supported FPC target, so I don't see why a 3rd party product would be needed in the first place. I assume you are just namedropping, s pecially since this one advocates POSIX and standard C library support, neither of which FPC uses on (any) Windows, so its prime features seem to be irrelevant.

Keep in mind that x86 (and _64) windows and dos feature the build in assembler and linker, so if you manage to create the win9x startup code in Pascal (like the current Win32 WinNT port), you don't need any external tools to crosscompile.

[zx_gamer]

I don't get why Unicode is a problem.

Obviously, machine code for i386 platform (and EXE file format is the same).

Runtime library has many functions, which know nothing about Unicode and WinAPI (sin, cos, log, abs, ...)

Some functions are WinAPI wrappers (sockets) or use WinAPI in implementation low-level (WriteLn, ReadLn, ...)

That looks like high-portable part of RTL (just copy implementation).

About Unicode. I guess strings should support Unicode (cause UTF-8 have no same character length) and functions like Assign.

Because of Windows 98 use "local" single byte encoding (ASCII, Windows-****), I see two ways: set single byte only encoding for Windows 9x or use UTF-8 implementation, but before system call (kernel32.dll call) convert UTF-8 string into "local" single byte string.

What if try to modernize RTL (Windows 9x) epoch FPC 2.x to modern RTL API?

[marcov]

I don't get why Unicode is a problem.

Obviously, machine code for i386 platform (and EXE file format is the same).

The rough outline of the EXE format is the same. there are possible differences in details. Pascaldragon might know more about that than me.

Runtime library has many functions, which know nothing about Unicode and WinAPI (sin, cos, log, abs, ...)

True. But those (sin,cos,log,abs) are mostly only CPU dependent, not OS dependent, so I didn't count them as "special" anyway. 

But anything that communicates a string to an OS call is affected by unicode. Open file, findfirst, but also calls that get parameters, environment strings and special directories.

Some functions are WinAPI wrappers (sockets) or use WinAPI in implementation low-level (WriteLn, ReadLn, ...)

Sockets are a good example. Not all win9x targets support winsock2, which is the corner stone of most Windows networking. Only very late (win ME) and with all updates afaik do.

That looks like high-portable part of RTL (just copy implementation).

About Unicode. I guess strings should support Unicode (cause UTF-8 have no same character length) and functions like Assign.

In Windows versions before 2019-05 Windows 10, unicode means UTF16 and thus -W API calls that win9x doesn't have. The usual forum parrots point to the kernelex and MSLU enhancements to make such calls work on win9x, but I don't know of  no practical experiences of such avenues. It is just a gentle remind for a future win9x maintainer to research them, as they could save quite some time.

Because of Windows 98 use "local" single byte encoding (ASCII, Windows-****),

Don't forget the console uses OEM encoding.

I see two ways: set single byte only encoding for Windows 9x or use UTF-8 implementation, but before system call (kernel32.dll call) convert UTF-8 string into "local" single byte string.

What if try to modernize RTL (Windows 9x) epoch FPC 2.x to modern RTL API?

You are free to try any avenue you want. As long as you keep it separate from regular (NT5+ aka w2k+) windows. That is a hard request. No sharing, period. Copy existing (NT) code if it helps you forward, but then maintain it in isolation from the mainstream Windows port.