I'm currently looking at the potential of a minimal Win32-compatible OS called Sanos, which supposedly implements a useful subset of the Windows console-mode API. As a starting point, I'm using the standard Windows variant of the FPC compiler, but if I build a minimal program (i.e. program test0; begin end.) the executable requires the oleaut32 DLL which is not implemented.

Is there an easy way to break this requirement, or do I need to hack and rebuild FPC? If the latter is feasible, could somebody give me a hint where to start?

You don't need to rebuild FPC itself, but you need to modify the RTL.

Three functions from oleaut32 are included for Windows compatible widestring management. As FPC has a fallback mechanism you can disable that.

For that create dummy implementations for the three functions that are imported from oleaut32 in system.pp (search for "oleaut32" in rtl/win32/system.pp, remove the "external ..." part and add empty bodies). Then you need to enable the fallback mechanism. You can do this by adding the following line to the top of the initialization section of system.pp (attention: system.pp uses the "begin" variant):

winwidestringalloc := False;

This is defined in rtl/inc/wstringh.inc, which is included by system.pp. And don't be afraid that it's a "const", because system.pp has "writable typed consts" enabled ;)

Then you need to rebuild the RTL.
If you've never done this here is the quick version:

- open command line and navigate to FPC directory
- make rtl OS_TARGET=win32
Note:
* if you are on a Win64 system you might want to add CPU_TARGET=i386 as well
* if FPC is not in your PATH you need to add FPC=c:\path\to\your\fpc.exe

This should built the RTL in rtl\units\i386-win32. You can copy the contents of that directory to the rtl directory that is mentioned in your fpc.cfg file (maybe backup that first...). Alternatively you copy your fpc.cfg and just alter the path for the rtl directory.

I have not tested what I've written here, so if it does not work then
feel free to ask back. :)

Regards,
Sven

Hello FPC,

Thursday, March 24, 2011, 9:10:10 PM, you wrote:

SB> You don't need to rebuild FPC itself, but you need to modify the RTL.

SB> Three functions from oleaut32 are included for Windows compatible SB> widestring management. As FPC has a fallback mechanism you can disable that.

Or simply create a dummy "oleaut32.dll" which exports the same functions prototypes without doing nothing (empty functions) and drop that DLL in the same folder as the exe.

But then you must not use FPC for that DLL as the oleaut32 functions are used in DLLs as well.

Also if you follow this approach it might be safer to stay far away from any function that takes a WideString (UnicodeString might work though).

Regards,
Sven

Ouch :-)

Also if you follow this approach it might be safer to stay far away from any function that takes a WideString (UnicodeString might work though).

Also since I'm tinkering with an OS of unknown completeness I think I'd rather steer clear of extra DLLs to start with.

I looked a little on the API declared by Sanos
and I think that it would probably be easier
to use our Unix targets to get a reasonable support for this OS rather than trying to use the Win32 subset. The C API seems to be far more extended than
the small Win32 emulation layer.

Otherwise you will really need to strip the RTL down a lot: Do not rely on exported function in DLL's
looking into sources, you will discover that lots
are only pseudo implementations doing nothing.

See for instance
SetConsoleCtrlHandler implementation in:
http://www.jbox.dk/sanos/source/win32/kernel32/kernel32.c.html

SetConsoleCtrlHandler is the central function
used inside Windows RTL to support exceptions on that target... Using signals.pp unit might help for this particular problem as thread specific exceptions with thread information block seems to be supported (but I didn't test it).

Pierre

colleagues]

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

I'm tinkering with I can get it to the point where an empty program "runs" then I'll be happy for the moment, if it runs a Hello World which also runs on Windows then I'll consider it time well spent.

I don't intend to put much effort into this since I don't know whether Sanos really is useful for anything, but I think it has potential as an upgrade for DOS+Go32. After all, if somebody wants a unix-style OS there's plenty of cut-down Linuxes.

Correct me if I'm wrong, but isn't the central function for this "SetUnhandledExceptionFilter"?

Regards,
Sven

Whoops, you are right, I made a confusion...
But looking at the implementation of that one
also seems to be an almost empty implementation:
It sets topexcptfilter variable and
return previous value, but that variable isn't used anywhere...

Pierre

Hello FPC,

you wrote

> Or simply create a dummy "oleaut32.dll" which exports the same > functions prototypes without doing nothing (empty functions) and drop > that DLL in the same folder as the exe.

SB> But then you must not use FPC for that DLL as the oleaut32 functions are SB> used in DLLs as well.

Instead modify RTL to not import that functions, provide a simple empty stub in a "local" DLL to keep the dll loader happy and disable unicode. Maybe I'm dropping something in the path and this approach is not good.

SB> Also if you follow this approach it might be safer to stay far away from SB> any function that takes a WideString (UnicodeString might work though).

The worst thing could be a "no answer" function, or implement a very basic non complian unicode operations (I had not checked what oleaut32.dll functions perform).

As the RTL can be switched to "don't use those functions", as I've described, the impact should be low.

Note: You do that switch in your main program as well as the variable/constant is available in the implementation section of the system unit (maybe you need to enable "writable typed constants"). Then a stub would be sufficient.

Regards,
Sven

Your earlier source hack works fine for excluding the oleaut32 stuff, I'd somehow got the idea that was being pulled in by MinGW so hadn't gone looking in system.pp.

With the patched runtimes available on a pukka Win-32 system, compilation needs -WR before a program will even start loading on Sanos- this was expected from the documentation. There are a couple of user32 calls (CharLowerBuffW and CharUpperBuffW) which presumably could be replaced in system.pp- they're in the same place as the function which was giving me problems with NT4.

More significantly, there are a whole lot of unresolved kernel32 entry points- I can't even get a full list at the moment since I can't login to Sanos's telnetd and there's more than a screenful, but they include things like GetStartupInfoA, LocalAlloc, LocalFree and so on and whilst I've not gone hunting yet I suspect that they're fundamental to the RTL's operation.

So I might tinker a bit more, but it's definitely not going to be trivial.