Sven Barth wrote:
Am 25.03.2011 13:10, schrieb José Mejuto:
Hello FPC,
Thursday, March 24, 2011, 10:19:09 PM, 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.
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.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
