26 Mar
2011
26 Mar
'11
8:06 p.m.
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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev