Hi all, I have a question for you: what would I need to do in order to create a Win32-NT cross compiler? i.e. how do you port the compiler to a new platform? I'd like to create Windows NT device drivers, subsystems, etc. in FPC (currently the only build environment for this kind of programs is that included in the Windows NT DDK, but it's for Microsoft C++ only, and I simply can't afford it). I know I'm crazy :), but I thank you in advance for all the help you'll be able to give me

I'm not sure what you are referring to. The Win32 compiler compiles native windows binaries. Device drivers are of course a whole different matter.

I think that you would need 2 things:
- Cross linker (I assume device drivers need a special link script) But this is not something FPC handles; as we use GNU binutils for that.
- A special system unit, which would override some of the system routines. How to do this is being documented (docs/internal/arch.tex).

After that is all done, a special target can be created in the compiler.

Michael.

you wrote

I'm not sure what you are referring to. The Win32 compiler compiles native windows binaries. Device drivers are of course a whole different matter.

There are two categories of Windows 32 bit executables:
- LE executables: VXD device drivers (these MUST be partly written in ASM, and MUST follow a special preprocess-compile-link process)
- PE executables: anything else

But Windows NT doesn't use LE format for drivers (VXD's are a ugly hack to retain DOS compatibility), NT device drivers are just PE dll's linked to the right libraries and, more important, with a completely different SEH model. dd's belong in turn to a wider category: NT Native executables. Note that Win32 means "anything running over the Win32 subsystem" (implemented in two native executables, csrss.exe and win32k.sys), but it doesn't mean "any 32 bit PE executable running on Windows". In fact 32 bit PE's can be even NT-POSIX or OS/2, or the aforementioned Native exes. Let's say that an exe is Native if it interfaces only to the kernel (via ntdll.dll) and/or the hardware (via hal.dll)

thanks! I'll let you know if I obtain anything barely working