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