We're still officially targeted at Server 2003 SP2. The work to add Vista+ functionality is a work in progress, but there isn't much emphasis on it right now due to the simple fact that we need a solid 5.2 kernel first before we can credibly attempt 6.x features. If we had more manpower we could do ...

In theory there should not be any need to port the driver, it should run as is in ReactOS. If it doesn't, that's a bug on our end and bug reports submitted to jira would be useful.

There actually as yet is no decision on what would be the "main" filesystem. As far as I'm aware of, it hasn't even really been thought about internally by the team. NTFS often gets brought up because it's the one that thematically makes sense since it's what NT uses, but officially there ...

It's that time of year again and we are looking to spin out version 0.4.2. I think at this point we can all agree that attempts to find a new versioning scheme are dead. Anyway, before we initiate the process of actually spinning out a release the team would like to check ReactOS' pulse so to speak....

That probably won't be happening just due to the maintenance requirements on our end. The best we can reasonably offer is a build option to target 64bit when using MSVC, but you're likely to still need our BE with its customized CMake to generate the solution files.

I don't see a midimap.dll in a cursory glance, but the msacm stuff is from Wine and isn't ours. wdmaud are drivers so those technically are ours, but drivers tend to be OS version specific, and ours are geared towards NT5.2, so whether it would even work on newer versions of Windows is an open quest...

This is a suggestion that you read the code of conduct.

Considering that tainted code would also be a roadblock to getting something included into ReactOS, asking us if the shell code was somehow tainted comes off as extremely disingenuous.

Internally I'm not sure there's much of a desire to convert the entire shell32 back to just C. Wine never prioritized shell32 in the first place and whether they would invest further development time into an implementation we provide is uncertain. With these considerations, I'd say the interest here...

The project tends to take a very strong position against anything that might at all be linked to leaked proprietary code due to past accusations against the project. Anything based off or derived from such code is also tainted by association, and we go to significant lengths to keep the project as a...

Monday, Monday. You're not a US student I take it then?

Just a heads up, a filter has been set up on the wiki to disable file uploads. Don't attempt one right now, it will auto-block your account if you do. It'll be refined to be less blanket but for now, uh, don't tempt fate.

I'm pretty sure internally a decision was made to support only i686 and later to make the lives of the people maintaining the build system simpler.

At this point Microsoft's created its own niche with the Surface line, one that Apple has found itself having to respond to what with the larger iPad Pro, a better keyboard, and etc. The Surface line is very popular and profitable, to the point that even if the original strategic objective was not m...