[Lazarus] Alternatives to WinCE (Windows Mobile)

[Bernd]

2012/9/1 Sven Barth <pascaldragon at googlemail.com>:

> 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?