[GSOC]GUI first stage installer

[Andrew Green]

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.

[Matthias Kupfer]

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 [phone]
Wilhelm-Firl-Straße 21   mobile [phone]
09122 Chemnitz, Germany

[Andrew Green]

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(a)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 [phone]
>  Wilhelm-Firl-Straße 21   mobile [phone]
>  09122 Chemnitz, Germany
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Pierre Schweitzer]

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

[Andrew Green]

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
>