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 <[email protected]> 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 > [email protected] > http://www.reactos.org/mailman/listinfo/ros-dev > _______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
