juno.base.native vs. core.sys.windows.windows

[Numpsy]

juno.base.native contains declarations of a bunch of WindowsAPI functions/structs that are also defined in core.sys.windows.windows.

Do we need to be keeping duplicates around?

There is also some overlap with the whole core.sys.windows.windows vs. thing, but that is a separate issue.

[JesseKPhillips]

core.sys.windows.windows is missing a crap ton of needed stuff. To me it doesn't make much sense to do the same thing but in reverse.

What really needs to happen is for core.sys to be updated with either the bindings project or Juno's. I don't know about licensing issues though.

I think core.sys need to be updated before we move to it, and I don't think depending on the bindings project is a good choice. Though maybe bringing the bindings project into Juno would be good (maybe even get the maintainers for it).

[Numpsy]

The bindings project is a bit of a hefty dependancy for the required use, and it seems to have maintainance issues of it's own (the D2 version of xfBuild includes the whole thing because of some of these issues).

I don't know what the situation is with getting the Windows bit moved on to github or something.

The Juno bindings contain a bunch of stuff that core.sys doesn't, but a possible issue is that they tend to use raw types rather than typedefs (i don't know if there are any issues in that, but it crosses my mind that there might be 64bit issues and such in there somewhere).