I'm looking to put in a proposal for gui 1st stage installer. I've asked around a bit on IRC who would be the mentor. Though no one seems to know. If anyone could point me in the right direction that would be great.
I was thinking of how it would be implemented. I know the gui mostly exists in svn. so that simplifies that.
I was thinking that the parts of the project would be setting it up so that as much code is shared between text-mode installer and gui installer.
1st stage gui installer should be able to run in windows as well as ros(this could simplify the install when using windows and make it easy to test the installer)
Also fixing the functions that are used. As it seems at the moment disk drives are not appearing as devices.
I have been unable to find an api that creates partitions. I thought this would be good rather than manipulating the disk directly as it may provide the ability to create partitions for any file system as long as a driver exists. Making it more flexible.
I am also rather excited about this project as the skills that I gain from this could be used to make the disk manager, and other disk utilities.
Any comments would be much appreciated.
Hi,
I have started the 1st GUI-installer frontend and the development has benn stalled at the point of missing library calls for e.g. detecting drives, partitions aso. This is described here: http://www.reactos.org/wiki/First_Stage_GUI_Setup
The correct way to proceed is to extend the win32-api by functions for setupapi (maybe sometimes it seemsto be necessary to extend the undelaying kernel as well). I still aren't/wasn't able to achieve this and wait for this work until i can proceed.
At Chemitz Linux Days 2011 Timo Kreutzer pointed out that we can go the easier way and port the install parts from text mode (aka usetup) to the graphics mode. We have to keep in mind, that we use bios-calls aso - means we don't use win32-api functions. This will probably work, but needs to be replaced somewhere in future too. Due to my lack of deep and detailed knowledge I don't feel comfortable with mentoring anyone in this development topic, even if the graphical frontend has been extended by me.
Am Samstag, 26. März 2011 09:43:51 schrieb Andrew Green:
I was thinking of how it would be implemented. I know the gui mostly exists in svn. so that simplifies that.
I was thinking that the parts of the project would be setting it up so that as much code is shared between text-mode installer and gui installer.
1st stage gui installer should be able to run in windows as well as ros(this could simplify the install when using windows and make it easy to test the installer)
Also fixing the functions that are used. As it seems at the moment disk drives are not appearing as devices.
As mentioned above, I suspect a chain of dependencies for this topic, which leads in frustration like a game with pyramid scheme.
I have been unable to find an api that creates partitions. I thought this would be good rather than manipulating the disk directly as it may provide the ability to create partitions for any file system as long as a driver exists. Making it more flexible.
I am also rather excited about this project as the skills that I gain from this could be used to make the disk manager, and other disk utilities.
Tools and managers are appreciated as long as they use the intended api like windows. We discourage the development of tools with _own_ (low-level) routines, even if it's faster to realise. For you information, we have such problems with explorer, which should use shell32-api, but in fact implements all functions for it's own. At the end of the day the shell32 is partly a stub and other programs can't use the api calls. Feel free to extend the win32-api to make functions for your tool working.
II hope that helps a little bit, feel free to ask anyway
Matthias
Thank you Matthias Kupfer. 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?
Also it might be worth noting that gsoc will replace my 8 hour 5 day a week job. so i should be spending more than 480 hours on this as an intermediate programmer with no kernel programming skills.
Is it possible to implement everything(not as a hack)? And i know it's impossible for you to say, but you have a much better idea than I do.
On Sat, Mar 26, 2011 at 7:15 PM, Matthias Kupfer mkupfer@reactos.org wrote:
Hi,
I have started the 1st GUI-installer frontend and the development has benn stalled at the point of missing library calls for e.g. detecting drives, partitions aso. This is described here: http://www.reactos.org/wiki/First_Stage_GUI_Setup
The correct way to proceed is to extend the win32-api by functions for setupapi (maybe sometimes it seemsto be necessary to extend the undelaying kernel as well). I still aren't/wasn't able to achieve this and wait for this work until i can proceed.
At Chemitz Linux Days 2011 Timo Kreutzer pointed out that we can go the easier way and port the install parts from text mode (aka usetup) to the graphics mode. We have to keep in mind, that we use bios-calls aso - means we don't use win32-api functions. This will probably work, but needs to be replaced somewhere in future too. Due to my lack of deep and detailed knowledge I don't feel comfortable with mentoring anyone in this development topic, even if the graphical frontend has been extended by me.
Am Samstag, 26. März 2011 09:43:51 schrieb Andrew Green:
I was thinking of how it would be implemented. I know the gui mostly exists in svn. so that simplifies that.
I was thinking that the parts of the project would be setting it up so that as much code is shared between text-mode installer and gui installer.
1st stage gui installer should be able to run in windows as well as ros(this could simplify the install when using windows and make it easy to test the installer)
Also fixing the functions that are used. As it seems at the moment disk drives are not appearing as devices.
As mentioned above, I suspect a chain of dependencies for this topic, which leads in frustration like a game with pyramid scheme.
I have been unable to find an api that creates partitions. I thought this would be good rather than manipulating the disk directly as it may provide the ability to create partitions for any file system as long as a driver exists. Making it more flexible.
I am also rather excited about this project as the skills that I gain from this could be used to make the disk manager, and other disk utilities.
Tools and managers are appreciated as long as they use the intended api like windows. We discourage the development of tools with _own_ (low-level) routines, even if it's faster to realise. For you information, we have such problems with explorer, which should use shell32-api, but in fact implements all functions for it's own. At the end of the day the shell32 is partly a stub and other programs can't use the api calls. Feel free to extend the win32-api to make functions for your tool working.
II hope that helps a little bit, feel free to ask anyway
Matthias
-- Matthias Kupfer phone +49 371 236 46 52 Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54 09122 Chemnitz, Germany
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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
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