FPC: Windows 98 setup fail

[zx_gamer]

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.

Windows 98 supports winsock2. I tried it with MSVC++6.0, it just works fine (ws2_32.lib).

Winsock2 is just a Berkeley sockets implementation. I maintain POSIX/Windows networking software in C using some macroses like that:
#ifdef WINDOWS_IMPLEMENTAION
#define close closesocket
#endif

in main():
#ifdef WINDOWS_IMPLEMENTATION
WSAStartup(...);
#endif

also you should allways use recv/send instead of read/write, because there are other functions in Windows.
Of couse, windows have some bullshit like typdef int SOCKET; but you can just igonre it and write portable code using int.

I did't try, but I belive, Windows 95 also support ws2_32.lib.

[zx_gamer]

[user]marcov[/user], could you introduce me? What I should read to understand current FPC architecture?

P.S. Hm... This BBCode doesn't support [user] tag?

[Bart]

There used to be a win9xwsmanager unit long time ago in fpc IIRC (I wrote it).
It dynamically loaded some dll for unicode conversions and had a fallback (very rudimentary) if that dll did not exist.

Bart

[marcov]

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.

Windows 98 supports winsock2. I tried it with MSVC++6.0, it just works fine (ws2_32.lib).

It's all too long ago for me. I switched to win 2000 at work before it came out (part of the team that prepared the win2000 migration for our university. Running Win2000 on a P166 with 16MB is not fun btw. I resorted to reading my imap email with cygwin MUTT because outlook ate too much memory), and on my private systems a few years later when RAM suddenly got cheap.

BUT be careful what media you use (win95 had 3 (original, an OEM only OSR1(aka win96) and a wider available OSR2, and win98 had at least original and second edition), and what you update it with later. IIRC installing MSIE4 replaced half of the windows directory, but was not part of original win98, and optional with win98 2nd edition.  Since VS6 was released after original win98, it might be that update that installed those libs.

Unfortunately I did away with my original Win95 floppies a few years ago.  I don't know much about Windows ME, since I never ran it.

Anyway,  those are all details are for you to decide.  Later versions and additional compatibility systems make it easier to compile existing applications. Sticking to original win9x maximises hypothetical compatibility, but requires more code changes. (and after the RTL, you need to get packages/ to compile and work)

[marcov]

[user]marcov[/user], could you introduce me? What I should read to understand current FPC architecture?

Well, obviously, the source code? Read the code, Luke!

[zx_gamer]

BUT be careful what media you use (win95 had 3 (original, an OEM only OSR1(aka win96) and a wider available OSR2, and win98 had at least original and second edition), and what you update it with later. IIRC installing MSIE4 replaced half of the windows directory, but was not part of original win98, and optional with win98 2nd edition.  Since VS6 was released after original win98, it might be that update that installed those libs.
...
Anyway,  those are all details are for you to decide.  Later versions and additional compatibility systems make it easier to compile existing applications. Sticking to original win9x maximises hypothetical compatibility, but requires more code changes. (and after the RTL, you need to get packages/ to compile and work)

.lib is a static library. So, it is possible to maintain ws2_32.lib and link with it.

[zx_gamer]

Well, obviously, the source code? Read the code, Luke!

Of course. But I guess I should begin with understating common FPC architecture. I guess FPC has unique architecure in the middle of "Simple one-pass compiler" (in Dragon Book terms) and "Advanced compiler" (in Steven S. Muchnick terms).

I mean I need to understand frontend API, backend API, and common compilation pipeline.

[marcov]

.lib is a static library. So, it is possible to maintain ws2_32.lib and link with it.

Is it? Or is it a static import library to connect to a dll ? You don't need those in FPC, as static bindings to a DLL are generated on the fly.

Linking with real static .libs in FPC is a relatively new feature.

[marcov]

Well, obviously, the source code? Read the code, Luke!

Of course. But I guess I should begin with understating common FPC architecture. I guess FPC has unique architecure in the middle of "Simple one-pass compiler" (in Dragon Book terms) and "Advanced compiler" (in Steven S. Muchnick terms).

If you know Turbo Pascal or Delphi that would help. For a basic usage, the compiler finds its files recursively from invoking it on the main file. You just pass the main file and some search paths, and that's enough to generate a binary. The links between pieces of source are based on USES clauses in the source, pretty much like USING in some other languages. The most important part to grok from this that compiling a source file does not 100% equate to a single invocation of the compiler. An invocation might compile dozens files (compilation units, having their own .o) or more.

Bootstrapping the project, in principle, requires the last FPC release installed. Any tools required are in that install,  in practice you also want GIT to check out cutting edge sources.

To build and bootstrap the project is slightly more complicated and requires some more tools that are included in the release, make and a few other tools (rm,gecho, ginstall, cmp and diff).  Till recently, GDB has been the only way to debug (with or without a GUI (Lazarus) or TUI (textmode IDE) frontend).  GDB is sometimes upgraded from the release version (i.e. Lazarus might package other versions).

There are no library dependencies, not even msvcrt or ucrt. Simple binaries only link to kernel32 and user32.

Originally FPC also used binutils (assembler (g)AS, linker LD, archiver AR as well as windows specific tools as DLLTOOL and WINDRES), over times these have been replaced by own versions, with the final replacement of windres still pending. The next major release might default to own "FPCRES" instead of windres to compile resources.

The main driving force to make own versions of AS/AR/LD were rooted in smartlinking (aka dead code elimination on the linker lever much like GCC's gc-sections). The binutils didn't support it on a per section level on Windows, and the only workaround was to make an object file per symbol  and archive those to static libraries using AR. This was horribly slow and memory consuming (I think the LD linker would nowadays eat more memory than available in 32-bit, before the internal linker, LD would eat 1.5GB to link Lazarus), specially for the Windows unit that held the windows api headers with tens of thousands of symbols.

Note that the binutils that we use are from about 2005, the last standalone mingw versions ( before unix compatibility layer MSYS was introduced). Such early LD versions don't support linking MSVC .lib static libraries.

I think the internal FPC linker slowly is starting to support .lib in trunk though, so it is not wholly impossible.

FPC does not support multithreaded builds, but the FPC and Lazarus build processes do allow for some parallelism, by compiling independent packages in parallel, specially in the packages/ directory. So the compiler-rtl bootstrap cycle (compile both 3 times) is single threaded, and then it goes into a multithreaded compilation of the package directory. However the dependencies of the various packages limit parallelism, giving a overall 2-3 times speedup of the packages/ directory.

Still, despite all the bad news, and lack of infinite parallelism, FPC is fairly fast. A good buildscript bootstraps the entire compiler on Linux in about 1min, and on windows on 1.5min, even on already dated hardware like a Ryzen 5 5600g, generating about 1500 compilation units (.o files) and several binaries. And that despite only limited parallelism.   

The principles of the Windows bootstrap process are more integrated and should be faster, but Windows' file I/O and process creation is relative slow and hold it back. Even just the clean step with all its "rm" invocations can take 5-15 seconds.

I mean I need to understand frontend API, backend API, and common compilation pipeline.

I think compiler work is a bridge best crossed when you actually need it. Start with the libraries first, as that is where most of the work is for a win9x port. Check out the rtl/win32 library and its makefile.fpc/makefile combo. The Makefile is generated from the Makefile.fpc file by "fpcmake".   

Also note that the RTL compiles the lowest level compilation units (system, math, objpas) standalone (invocation per unit), and then compiles "buildrtl", which compiles a bunch of files. This is called a "build unit", saving on the compiler start/build state/stop cycle to compile multiple units in one run.  The makefile(.fpc) entries for those units are only to trigger recompilation of "buildrtl" on change.

For a bit dated, but still relevant treatise about FPC building, see https://www.stack.nl/~marcov/buildfaq.pdf by yours truly. A version of my windows buildscript is at https://www.stack.nl/~marcov/stdbuild.cmd
 

[440bx]

@marcov,

I just wanted to say thank you for all the quite useful information you shared in that post.

[zx_gamer]

I think compiler work is a bridge best crossed when you actually need it. Start with the libraries first, as that is where most of the work is for a win9x port. Check out the rtl/win32 library and its makefile.fpc/makefile combo. The Makefile is generated from the Makefile.fpc file by "fpcmake".   

Also note that the RTL compiles the lowest level compilation units (system, math, objpas) standalone (invocation per unit), and then compiles "buildrtl", which compiles a bunch of files. This is called a "build unit", saving on the compiler start/build state/stop cycle to compile multiple units in one run.  The makefile(.fpc) entries for those units are only to trigger recompilation of "buildrtl" on change.

For a bit dated, but still relevant treatise about FPC building, see https://www.stack.nl/~marcov/buildfaq.pdf by yours truly. A version of my windows buildscript is at https://www.stack.nl/~marcov/stdbuild.cmd

I have copied rtl/win32 as rtl/win32_9x. As my understanding goes I need to add "win32_9x" target to FPCMake (How?).
So, after that, I need to wrap all functions, which dosen't work with Windows 9x WinAPI in current win32 RTL port in my RTL win32_9x port.

[MarkMLl]

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.

Etc.

Yes, very true. I was working on the assumption that having a text-mode OS with the basic non-NT Win-32 API would be useful, but OTOH there are problems like poor (if any) debugger support.

MarkMLl