2012/9/1 Sven Barth :
Show quoted text 5 lines
Those apps then use the APIs
provided by WinRT and only those. The operating system can then check
whether the application behaves "good" and only uses that APIs and then
allows to run it on "locked down" versions of Windows like the ARM version
of Windows 8
What about information like this:
https://forums.embarcadero.com/message.jspa?messageID=484319#484319
Quote Allen Bauer:
"[...] Right now, the issues surrounding the WinRT space center around the fact that many OS-supplied APIs which are required by anyone implementing their own language RTL are actually off-limits unless you're the VC++ RTL DLL. You know, little things like RtlUnwind for exception processing and VirtualAlloc (et. al.) for memory management... Any calls to those APIs from your application will automatically disqualify your application from being an "official" WinRT application capable of delivering through the MS app store.
Right now the VC++ RTL DLL is given special dispensation since that is the library that makes the calls to those forbidden APIs and not directly from the user's app.
[...]
Like the APIs I mentioned above, there are lots of changes with WinRT that make targeting it a little more tricky. For instance, you cannot merely open any file, access the registry, and even use the loopback (127.0.0.1) adaptor. LoadLibrary cannot be used to load any arbitrary DLL; you must call LoadPackageLibrary and only on a DLL that is present in the digitally signed appx package. WinRT is a seriously locked down sandbox or "walled-garden" with some extremely high walls.
[...]"
or this one: https://forums.embarcadero.com/message.jspa?messageID=484771#484771
"[...] Something else I didn't mention was for 32bit applications under WinRT, you must build all binaries using what MS calls SafeSEH. There is precious little information about exactly what that entails. We know it is special meta-data included with an executable that describes all exception handlers throughout that image. However the format of said meta-data isn't documented. I suspect it is similar to the .pdata section of a Win64 image because SafeSEH only pertains to Win32.
<snark>
The only thing we can find is a reference to the /SafeSEH switch for VC++ which you set and it "does the right thing." Gosh, thanks... so all I have to do is recognize that switch with Delphi and it will magically "do the right thing" ;-). Yeah that's the ticket. </snark>
[...]"
When reading such things about Delphi's problems I wonder what this all means for FPC, Especially the following:
* will it ever be possible to build any kind of .exe for RT that will work?
* will it at least be possible to compile a .dll that can be loaded by a native RT app?
* what exactly does "Win32" and "Win64" mean in the above quote in the context of WinRT/ARM, he is talking about ARM code, isn't he? Would the SafeSEH problem affect FPC programs or libraries too?
* will FPC be usable for anything at all on WinRT?
* If the answer to the above is no then would it help to implement a .NET bytecode target in FPC, would this improve the chances of making it usable?
