Freeldr UI modifications

[mf]

Hi,

I recall having heard several suggestions to make freeldr easier on the
eyes (don't underestimate 60Hz VGA resolutions on a CRT) and/or make it
look more familiar to ntldr. I have experimented with editing bootsup.c
and the result implements both suggestions. The black background makes
it less flickery on CRT displays and looks more in line with ntldr (the
Windows boot loader). Please see the attached image and tell me your
thoughts and observations.

Best Regards,

mf.

[J. De BACKER]

Thanks, it's good. It me thinks old dos or CPM on CBm 1972' year
Good luck.
> -----Message d'origine-----
> De : [e-mail]
> [mailto:[e-mail]]De la part de mf
> Envoyé : mercredi 9 novembre 2005 18:32
> À : ReactOS General List
> Objet : [ros-general] Freeldr UI modifications
>
> Hi,
>
> I recall having heard several suggestions to make freeldr easier on the
> eyes (don't underestimate 60Hz VGA resolutions on a CRT) and/or make it
> look more familiar to ntldr. I have experimented with editing bootsup.c
> and the result implements both suggestions. The black background makes
> it less flickery on CRT displays and looks more in line with ntldr (the
> Windows boot loader). Please see the attached image and tell me your
> thoughts and observations.
>
> Best Regards,
>
> mf.

[Casper Hornstrup]

Why not just make it as simple as ntldr while you are at it?
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of mf
> Sent: 9. november 2005 18:32
> To: ReactOS General List
> Subject: [ros-general] Freeldr UI modifications
>
> Hi,
>
> I recall having heard several suggestions to make freeldr easier on the
> eyes (don't underestimate 60Hz VGA resolutions on a CRT) and/or make it
> look more familiar to ntldr. I have experimented with editing bootsup.c
> and the result implements both suggestions. The black background makes
> it less flickery on CRT displays and looks more in line with ntldr (the
> Windows boot loader). Please see the attached image and tell me your
> thoughts and observations.
>
> Best Regards,
>
> mf.

[mf]

David Hinz wrote:
> I think it is good the way it looks in his screenshot,
> but it looks like the timeout is missing in this version, or am I wrong??
> If it is really missing, it should be added again, as it is very important to 
> see how many time you have left to decide.

I had moved the cursor in that screenshot, which disables the timeout. 
It is still there if you don't touch the keyboard as usual, though.

mf

[mf]

Alex Ionescu wrote:
> That's exactly how my freeldr looks, but I only had to modify
> freeldr.ini. Why touch bootsup.c?
>
> Best regards,
> Alex Ionescu

bootsup.c is the code where usetup "generates" a freeldr.ini upon 
install. I usually format the virtual drive before I install a new build 
of ReactOS on it to prevent registry corruption, so any local changes 
will be wiped this way.

Casper Hornstrup wrote:
> Why not just make it as simple as ntldr while you are at it?

Because even though I have touched my C book for the first time in 
roughly 3 years (it was dusty) and started reading it, I am still in no 
position to call myself a programmer or modify any ReactOS code. Until I 
advance at least a few chapters I will keep myself to modifying 
parameters, drawing artwork and motivating programmers instead of 
writing my own code. In this case I have simply modified some color 
parameters to change Freeldr's look.

mf

[João Jerónimo Barata de Oliveira]

mf wrote:
> bootsup.c is the code where usetup "generates" a freeldr.ini upon
> install. I usually format the virtual drive before I install a new
> build of ReactOS on it to prevent registry corruption, so any local
> changes will be wiped this way.

So you only made usetup to configure freeldr ina diferent way... good
idea...

A better idea would be add a bootloader configuration step to usetup...

João Jerónimo

_______________________________________________________ 
Yahoo! Acesso Gr�tis: Internet r�pida e gr�tis. 
Instale o discador agora!
http://br.acesso.yahoo.com/

[João Jerónimo Barata de Oliveira]

David Hinz wrote:
> I don't think such a step in our setup would be useful, because nearly
> nobody (of the users) wants to configure the look and feel of his
> bootloader, and every step you add to the setup makes it more
> difficult for the user.

Yes... a agree about the look and feel... but I meant the whole boot
loader config, not (only) the look and feel...
And there's always a solution: automatic configuration for people who
don't like to concern/don't know much about boot loader configuration...
> I think wo should choose a default and everybody who doesn't like it
> may change the settings in his freeldr.ini.

No... doing things in Microsoft's way no, thanks... I think ROS
shouldn't clone that philosophy of making the things so easy even if it
makes the software dangerous... because if you have no control about the
boot loader configuration, usetup can break other operating system's...

It happens the same when usetup doesn't distinguishes logical from
primary partitions...

João Jerónimo

_______________________________________________________ 
Yahoo! Acesso Gr�tis: Internet r�pida e gr�tis. 
Instale o discador agora!
http://br.acesso.yahoo.com/

[João Jerónimo Barata de Oliveira]

David Hinz wrote:
> I didn't know, you want to configure the bootloader in usetup.
> That really is a good idea, but I don't think we should add the
> possibility to configure the look and feel of freeloader to usetup.

Yes... Really I didn't make it very clear...

João Jerónimo

_______________________________________________________ 
Yahoo! Acesso Gr�tis: Internet r�pida e gr�tis. 
Instale o discador agora!
http://br.acesso.yahoo.com/

> No... doing things in Microsoft's way no, thanks... I think ROS
> shouldn't clone that philosophy of making the things so easy even if it
> makes the software dangerous... because if you have no control about the
> boot loader configuration, usetup can break other operating system's...
>
> It happens the same when usetup doesn't distinguishes logical from
> primary partitions...
>
> João Jerónimo
> I didn't know, you want to configure the bootloader in usetup.<br>
> That really is a good idea, but I don't think we should add the
> possibility to configure the look and feel of freeloader to usetup.<br>

Hmm, I don't think that it would harm if we make a site calles "Advanced
Options" where are buttons to get to other sites like the configuration of
freeldr.

[Alex Ionescu]

Here are some changes I made to Freeldr last night. Also to ntoskrnl and 
the HAL. Booting takes 4 seconds now and seems much faster, it probably 
is a bit too.

http://www.relsoft.net/rosldr1.png
http://www.relsoft.net/rosldr2.png

Best regards,
Alex Ionescu

João Jerónimo Barata de Oliveira wrote:
> David Hinz wrote:
> > I don't think such a step in our setup would be useful, because nearly
> > nobody (of the users) wants to configure the look and feel of his
> > bootloader, and every step you add to the setup makes it more
> > difficult for the user.
>
> Yes... a agree about the look and feel... but I meant the whole boot
> loader config, not (only) the look and feel...
> And there's always a solution: automatic configuration for people who
> don't like to concern/don't know much about boot loader configuration...
> > I think wo should choose a default and everybody who doesn't like it
> > may change the settings in his freeldr.ini.
>
> No... doing things in Microsoft's way no, thanks... I think ROS
> shouldn't clone that philosophy of making the things so easy even if it
> makes the software dangerous... because if you have no control about the
> boot loader configuration, usetup can break other operating system's...
>
> It happens the same when usetup doesn't distinguishes logical from
> primary partitions...
>
> João Jerónimo

[Brandon Turner]

Thats sweet, good work Alex!

Brandon

Alex Ionescu wrote:
> Here are some changes I made to Freeldr last night. Also to ntoskrnl 
> and the HAL. Booting takes 4 seconds now and seems much faster, it 
> probably is a bit too.
>
> http://www.relsoft.net/rosldr1.png
> http://www.relsoft.net/rosldr2.png
>
> Best regards,
> Alex Ionescu
>
> João Jerónimo Barata de Oliveira wrote:
> > David Hinz wrote:
> >
> > <snip>
>
> ros-general mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-general

[Magnus Olsen]

Hi, I do not like the design at all, I do not care if it take 4 sec or
curent time it takes.

----- Original Message ----- 
From: "Alex Ionescu" [e-mail]
To: "ReactOS General List" [e-mail]
Sent: den 16 November 2005 18:33
Subject: Re: [ros-general] Re: Freeldr UI modifications

Here are some changes I made to Freeldr last night. Also to ntoskrnl and
the HAL. Booting takes 4 seconds now and seems much faster, it probably
is a bit too.

http://www.relsoft.net/rosldr1.png
http://www.relsoft.net/rosldr2.png

Best regards,
Alex Ionescu

João Jerónimo Barata de Oliveira wrote:
> David Hinz wrote:
> > I don't think such a step in our setup would be useful, because nearly
> > nobody (of the users) wants to configure the look and feel of his
> > bootloader, and every step you add to the setup makes it more
> > difficult for the user.
>
> Yes... a agree about the look and feel... but I meant the whole boot
> loader config, not (only) the look and feel...
> And there's always a solution: automatic configuration for people who
> don't like to concern/don't know much about boot loader configuration...
> > I think wo should choose a default and everybody who doesn't like it
> > may change the settings in his freeldr.ini.
>
> No... doing things in Microsoft's way no, thanks... I think ROS
> shouldn't clone that philosophy of making the things so easy even if it
> makes the software dangerous... because if you have no control about the
> boot loader configuration, usetup can break other operating system's...
>
> It happens the same when usetup doesn't distinguishes logical from
> primary partitions...
>
> João Jerónimo

_______________________________________________
ros-general mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-general
-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.3/172 - Release Date: 2005-11-15

[mf]

Alex Ionescu wrote:
> Here are some changes I made to Freeldr last night. Also to ntoskrnl and 
> the HAL. Booting takes 4 seconds now and seems much faster, it probably 
> is a bit too.
>
> http://www.relsoft.net/rosldr1.png
> http://www.relsoft.net/rosldr2.png

I like them a lot. I would suggest them to be committed to SVN. Does 
anyone agree?

mf

[Alex Ionescu]

mf wrote:
> > http://www.relsoft.net/rosldr1.png
> > http://www.relsoft.net/rosldr2.png
>
> I like them a lot. I would suggest them to be committed to SVN. Does 
> anyone agree?
>
> mf

They are part of my rosldr project. You'll be able to download it at a 
much later date.

Seeing as how Brian doesn't even want to let me remove an empty file 
that's not used at all, I doubt he'd agree to allow such heavy 
modification of Freeloader.

Best regards,
Alex Ionescu

[Brian Palmer]

Alex,

You could very easily add this within the current framework. You had said
you wanted to remove all the GUI stuff (which I took to mean all the video
and graphics capabilities) and make everything call the TUI functions
directly. Which I think is a bad idea.

However, if you want to keep the current UI framework, and only delete gui.c
and gui.h I am ok with that. They are empty, just like you say. Then you can
add this new "console" looking UI as a sibling to the TUI one. After all,
that's what the abstraction is for.

It looks like there is some confusion about what we both are talking about.
Can you please explain again what you propose to change?

-Brian

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Alex Ionescu
Sent: Saturday, November 19, 2005 3:30 PM
To: ReactOS General List
Subject: Re: [ros-general] Re: Freeldr UI modifications

mf wrote:
> > http://www.relsoft.net/rosldr1.png
> > http://www.relsoft.net/rosldr2.png
>
> I like them a lot. I would suggest them to be committed to SVN. Does 
> anyone agree?
>
> mf

They are part of my rosldr project. You'll be able to download it at a 
much later date.

Seeing as how Brian doesn't even want to let me remove an empty file 
that's not used at all, I doubt he'd agree to allow such heavy 
modification of Freeloader.

Best regards,
Alex Ionescu
_______________________________________________
ros-general mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-general

[Alex Ionescu]

Brian Palmer wrote:
> Alex,
>
> You could very easily add this within the current framework. You had said
> you wanted to remove all the GUI stuff (which I took to mean all the video
> and graphics capabilities) and make everything call the TUI functions
> directly. Which I think is a bad idea.
>
> However, if you want to keep the current UI framework, and only delete gui.c
> and gui.h I am ok with that. They are empty, just like you say. Then you can
> add this new "console" looking UI as a sibling to the TUI one. After all,
> that's what the abstraction is for.
>
> It looks like there is some confusion about what we both are talking about.
> Can you please explain again what you propose to change?
>
> -Brian

Hi,

When I say remove all the "GUI Stuff" I meant the abstraction layer, not 
the "video and graphics capabilities". One more time, I simply want a 
box to be drawn by TuiDrawBox, instead of UiDrawBox, which will then 
read the current graphics mode, and then call TuiDrawBox. It's a useless 
abstraction at this point.

However, I gave it a bit more thought, and if I replace this by a vtable 
system much like the Mach functions, then I believe we shoudl both be 
happy. It would get rid of ui.c, gui.h, ui.h and gui.c, leaving only 
tui.c. However, the calls themselves won't be TuiDrawBox, but UiDrawBox, 
where this will be defined to something like GraphicsTable->DrawBox, 
which will be initialized on startup. That way, the useless source files 
go away, because it's not necessary to define the Gui functions anymore. 
The speed impact will go away too, since we don't be checking the 
graphics mode each time, and if someone wants to implement a 3rd graphic 
mode (ie: console mode), they won't have to edit 50 UI functions to add 
another "if/else" case. How does that sound?

Best regards,
Alex Ionescu

[Brian Palmer]

Alex,

That sounds good. However, aren't your current changes what should be called
the "console" UI and the old user interface should stay as the "TUI"? And
they could be user selectable through the .ini file?

Or are you getting rid of the current user interface completely, instead of
writing an additional one? If so, I suggest writing an additional one so
that those of us that prefer the old user interface can still use it.

Something like this:

tui.c has all the original UI stuff in it.
cui.c has your new "console" UI.
ui.c (or ui.h) has a single function that calls (or is #define'd) to
GraphicsTable->DrawBox which points to either the tui.c or cui.c equivalent.

What do you think?

-Brian

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Alex Ionescu
Sent: Saturday, November 19, 2005 5:39 PM
To: ReactOS General List
Subject: Re: [ros-general] Re: Freeldr UI modifications

Hi,

When I say remove all the "GUI Stuff" I meant the abstraction layer, not 
the "video and graphics capabilities". One more time, I simply want a 
box to be drawn by TuiDrawBox, instead of UiDrawBox, which will then 
read the current graphics mode, and then call TuiDrawBox. It's a useless 
abstraction at this point.

However, I gave it a bit more thought, and if I replace this by a vtable 
system much like the Mach functions, then I believe we shoudl both be 
happy. It would get rid of ui.c, gui.h, ui.h and gui.c, leaving only 
tui.c. However, the calls themselves won't be TuiDrawBox, but UiDrawBox, 
where this will be defined to something like GraphicsTable->DrawBox, 
which will be initialized on startup. That way, the useless source files 
go away, because it's not necessary to define the Gui functions anymore. 
The speed impact will go away too, since we don't be checking the 
graphics mode each time, and if someone wants to implement a 3rd graphic 
mode (ie: console mode), they won't have to edit 50 UI functions to add 
another "if/else" case. How does that sound?

Best regards,
Alex Ionescu
_______________________________________________
ros-general mailing list
[e-mail]
http://www.reactos.org/mailman/listinfo/ros-general

[Alex Ionescu]

Brian Palmer wrote:
> Alex,
>
> That sounds good. However, aren't your current changes what should be called
> the "console" UI and the old user interface should stay as the "TUI"?

I never meant for my current changes to be part of Freeloader. But if 
there is enough request for it, then they belong in TUI; they are just 
another TUI interface. With some small changes in the INI file and the 
TUI code (to make it more dynamic) it would easily be done. All I've done is

1) change the backdrop to full black (easy)
2) Disable the clock (easy)
3) Use a different top-level header (a bit hard to configure through an 
.INI)
4) Not draw a box around the menu  (easy)
5) Use a modified timeout text (easy) and style (a bit harder to do with 
the .INI alone, but not overkill)
6) Position the menu differently (easy)

I can make some small changes to the Tui code to support more 
configurabile options, like for #4, TuiDrawMenu can be modified to 
conditionally call TuiDrawMenuBox, etc.
> And
> they could be user selectable through the .ini file?

See above.
> Or are you getting rid of the current user interface completely, instead of
> writing an additional one?

That was never my plan, a lot of people don't like NTLDR's interface.
> If so, I suggest writing an additional one so
> that those of us that prefer the old user interface can still use it.

Defintely.
> Something like this:
>
> tui.c has all the original UI stuff in it.
> cui.c has your new "console" UI.
> ui.c (or ui.h) has a single function that calls (or is #define'd) to
> GraphicsTable->DrawBox which points to either the tui.c or cui.c equivalent.
>
> What do you think?

Sounds good, except that my stuff isn't really "console". It's still 
very much TUI but simply using other settings which I can make available 
through the .INI file.
So, should I go ahead with the new .INI options and modifying TUI to 
respect them?

Best regards,
Alex Ionescu

[Brian Palmer]

Alex,
> So, should I go ahead with the new .INI options and modifying TUI to 
> respect them?

Yes, this all sounds fine. It's good to all be on the same page.

-Brian

[João Jerónimo Barata de Oliveira]

Alex Ionescu wrote:
> Here are some changes I made to Freeldr last night. Also to ntoskrnl

and the HAL. Booting takes 4 seconds now and seems much faster, it
probably is a bit too.
> http://www.relsoft.net/rosldr1.png
> http://www.relsoft.net/rosldr2.png

In my opinion, it was best before with more graphical design...
Now it's just like NTLDR, nothing special... I even think you would
better entirely change FreeLDR configuration... I don't like
poly-bootloaders (for distinguishing from multiboot, which is a
standard) that run from disk partitions... In my opinion, the ideal boot
loader:
MBR boot code (446 bytes)... loads some contents of the 1st cylinder of
the disk (after the MBR sector, it's usually empty)

Contents of that space: configuration of the boot loader (no config
reading from partitions while running this first stage boot loader);
executable that shows the menu accordingly to the config it should read;
some routines (possibly modules) for loading specific OSs, becuase they
aren't all started the same way; and parhaps an image in some format...
MBR boot code would load (and jump to) the menu binary, which reads the
config and builds the menu accordingly... after knowing the user
decision, it would read the right routine for that OS...
That routine would, then, do what it has to do (i.e. load the kernel,
switch to protected mode if that's the case, etc) or just chainload to
another partition's boot code (on filesystems that allow it)...

Well, indeed there's a boot loader that works very much like this...
GRUB uses that sector to store some parts of the program... but I don't
know if it stores there the config and I think that would be essencial
(because, in my opinion, a boot loader needs to be independent from
operating systems so, for example, there could be configuration floppy
disks for changing its configuration)...
As Grub is very similar (or parhaps identic) to my description of the
ideal boot loader, I would like you to chose Grub as ReactOS boot loader
(either by modifying it's configuration or by installing it from
scratch, depending on the pré-install configuration)... That is, of
course, also making ReactOS multiboot-compilant if it isn't already (It
doesn't look like that)...

I don't claim to be a pioneer on those ideas... But I think you are
following the same path as Microsoft (i.e. I am the main OS, chainload
to my partition and then I can load other OSs if you want) and it's not
good... I think a boot loader must be on its own place, and MBR (and
those bytes between MBR and the partitions) is the right place for a
boot loader...

Finally, I'm merelly giving my opinion... if you think that there are
other priorities, I understand that... of course you have many other
things to implement/stabilise/improve... I'm not very skilled in
programming, otherwise I would help...

João Jerónimo

_______________________________________________________ 
Yahoo! Acesso Grátis: Internet rápida e grátis. 
Instale o discador agora!
http://br.acesso.yahoo.com/