So basically I am really just needing to know where to put things in the repository and create my own machine makefile etc. I looked around
and you cover recompiling but not porting to a new system.

Now I had a look at the beagleboard codes and I sort of know where most everything goes and what I would change but there is one major
thing I haven't worked out. As I will be doing the Pi3 AARCH64 bit first I have 4 processor cores and I can't work out how I am supposed to
hand the other cores over.

So currently my boot code will just park cores 1,2,3 and the O/S is then expected to ask me when they want them handed over. So this is
my current bootstub for AARCH64https://github.com/LdB-ECM/Raspberry-Pi ... tStart64.S
So that sets up memory stuff, parks core 1,2,3 brings the FPU online and then finally looks to enter a C file

No clue where to begin but the first start would be dumping Linaro and use a proper compiler which supports mandatory features needed for Windows alike systems. SEH would be a good start: https://msdn.microsoft.com/en-us/library/swezty51.aspx We have a hacky implementation for MinGW made x86 builds, but it would need to be completely redone for every other architecture. Only way to get some stuff being at least semi useable, you need MSVC ARM

ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

Update: Deleted previous stuff, I found the startup ntoskrnl\ke .. what does ke stand for, kernel entry?
So I made an CORTEX-A53 directory and started working and got the switcher doing its thing by looks. Can I ask what CPU the arm directory is for it has some problems for the Pi 32 bit. I am trying to work out if I should fix it or build my own. I am also scratching my head where you guys put your linker directive files

It would be quicker to use IRC if there is anyone there that could help! You would be getting answers much quicker than waiting for someone that could answer your posts, to come along.

Please keep the Windows classic (9x/2000) look and feel.
The layman's guides to - debugging - bug reporting - compiling - with some complementary scripts.
They may help you with a problem, so do have a look at them.

Slower question I need to ask if this is a standard being used .. what I am objecting to is ULONG on hardware registers.
I assume that must be a macro somewhere because the files use it without any includes. I am defining up a pile of
hardware at the moment.

I can't do that with my libraries it's illegal .... uint32_t is the C standard for that width fixed type and what I will use by
including <stdint.h>. It's hardware and not possible it could ever change.

For what matters to NT, (u)LONG is *always* 32-bit (which is of course different from what *nix chose), (u)SHORT is *always* 16-bit, (u)LONGLONG is *always* 64-bit. But (u)INT is either 32-bit or 64-bit (or...) depending on your architecture. The same is for "ULONG_PTR" which depends on the architecture.
You can more rarely encounter (u)LONG32, or (u)LONG64, etc... : these are understood to always be 32-bit, or 64-bit respectively.

Yes but my libraries which I am providing to do this don't know what a ULONG is, so it would
become a type hacking exercise at this very low level. It's fine up off the hardware layers we
can do what we like, you don't get to play with hardware registers.

I am not going to rewrite the entire USB, sdCARD, ETHERNET, WIFI system blocks to use such
a stupid name for a register type. I have no intention of maintaining lots of hardware drivers
which don't match any C standard or my usual libraries I use and maintain.

In the meantime what I have worked out I can do because your compiler supports anonymous
unions and structs is to put my own unions over those already existing. Then I can just ignore all
the ULONG stuff totally which will be acceptable to me. If you want to use my stuff with ULONG
feel free to put ULONG unions over it.

There is no full-featured Windows port on Raspberry Pi. Only existing port is locked from inside. Compatibility concern is more limited on that specific build (not all ARM builds are in this state however)

Well I was going along all right but now I have lost the thread in what seems like a maze of subsystems most of which I don't care about at this stage. The system isn't crashing and the switcher is merrily working and I can probe around to debug by assigning my own task thread.

I need to probably come back wards from a user window. So anyone know what source file the window message thread is created in. I can then see if I can track it backwards from there.