Actually I was thinking. There is a way to be win32 compatible and avoid PnP storage stack.
The wiki said that this bug was stopping them from completing reactos gui installer. http://www.reactos.org/bugzilla/show_bug.cgi?id=3886 Though from my understanding. Those functions are just used to get the current physical hard drives. Then get the drive number with SPDRP_LOCATION_INFORMATION then you could build the string from that number and call something like "\.\PhysicalDrive0" or "\Device\Harddisk0\partition0"(both of these exist in current reactos) with CreateFile. Then use all the functions that are available to edit the drive.
A stop gap would be to query 0 to 32 or whatever and see if it exists(a hack but the difference between the 2 would be small and easy to change or simply have a preprocessor flag to change the behavior). Then i just have to worry about how to complete the drive editing functions are.
I could be completely wrong with this though.
Would be cool to work on something like PnP. As that would be much more valuable to the project. Though it is not in GSOC ideas page, and this sounds like it's due to lack of mentors.
On Sun, Mar 27, 2011 at 4:53 AM, Pierre Schweitzer pierre.schweitzer@reactos.org wrote:
Hi
After poking around more it is mentioned that "plug&play storage stack" will be needed. which I'm guessing is no small task. I would have liked to make a proposal to do it the proper way.
is there anyone who can tell me what "plug&play storage stack" would take?
Having a PnP storage stack would require you first fix PnP in ReactOS. Or you would implement something which isn't working in ReactOS (could be an idea well - test case for ReactOS).
Anyway, harder part here is finding someone who can mentor you. After several talks on IRC, it appears that "lassy" and I are the most skilled on that point. And we are far from understanding everything...
Luckily, you may use some DDK samples to realise part of that. But it wouldn't do everything. Especially if you never coded in kernel-mode.
Regards, P. Schweitzer
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev