If you were to ignore the signing problems and concentrate solely on the FPC problems, are those problems you could provide solutions for in your custom unleashed fork ? if the answer is "yes", is it appealing for you to enhance unleashed to make it easier to develop drivers ?
There's a
NativeNT target in FPC already, but it's incomplete to an unknown degree - in practice, not usable for anything serious.
The bigger pain point is the trunk RTL: at some commit a couple of years back, the build setup changed in a way that you can no longer drop RTL units alongside your project and compile them together. The RTL has to be rebuilt separately, in its own pass - which massively complicates the dev cycle when you're iterating on a kernel-mode RTL replacement. That's why I worked off an older commit - it allowed the "throw it all together and rebuild" workflow that's a lot more practical for this kind of work.
Unleashed is now too far ahead of that older commit to roll back, so addressing this would mean: first sinking some unknown amount of time into figuring out a workable path for preparing a dev environment around the
NativeNT target, then slowly building out the target itself. That's
days of poking around and potentially fixing FPC just to start writing a driver RTL freely - before any actual driver-relevant work.
So the honest answer is: not really. Technically doable, but I don't see a clear purpose for it, I don't have the motivation, and the entry cost is high. If at some point a concrete project shows up where this matters, I'd reconsider - but right now, no.
Otherwise it is easier to write 64 bit drivers than 32 bit drivers using fpc.
Other way around in my experience - 32-bit drivers are simpler. The dev side is roughly the same on both (same FPC, same RTL pain), but 32-bit Windows doesn't enforce driver loading nearly as strictly. Self-signed or unsigned drivers, or one of the various loading tricks, just work in a lot more cases on 32-bit. So: dev = same, loading a self-signed / hacked driver = much easier on 32-bit. The 64-bit pain is almost entirely on the loading / signing side, not the writing side.
@440bx
Can you elaborate on possible problems with the current FPC win 64 bit release regarding driver development?
Let me answer this one - as it stands, you can't compile a working 64-bit driver with what's currently in FPC. The
NativeNT target is incomplete to an unknown degree - the build setup is wired for both i386 and x86_64, but the implementation is patchy enough that I wouldn't call either architecture production-usable. You'd need your own RTL - either built from scratch, or by fixing and finishing
NativeNT. The gaps are huge; the target is essentially a "template". If you went back about 20 years you might be able to compile it for XP, but the resulting driver wouldn't actually do anything useful.
Take a look at the
NativeNT sources sometime - empty function bodies,
TODO markers everywhere. It's abandoned work, last meaningful activity around 2010; doing it properly would mean redoing most of it from scratch.
Recent
