79 replies to this topic

[steve6375]

Great!

Maybe you could let YaYa know that his work in changing the source code as you requested worked?

 

@Wonko - I bow to your much greater experience and knowledge in this area - do you think it is worth asking YaYa to also add a =0xhh switch as well?

[tinybit]

The undocumented switch --in-situ=<FLAGS> is already in use. Currently the FLAGS is used for "clearing the other 3 entries and only keep the in-situ'ed entry", if I remember correctly. Surely, maintainers/developers may change anything at will, no problem, especially when the FLAGS has actually not yet been used by anyone.

 

Emm...

 

The FLAGS is currently a byte value. So it could be treated as a 16-bit value by developers.

 

In the case of in-situ, To_C's high byte is FLAGS, and Low byte is the partition ID(0x0E or 0x06, etc.)

 

The possible new usage could be: --in-situ=<FLAGS_AND_ID> where FLAGS_AND_ID is a 16-bit value with flags at high byte and partition ID at low byte. And the FLAGS_AND_ID will be place on to "to_cylinder" which is also 16-bit. This way, the assembly code need not touch. Only the map_func() need to change.

 

Anyone of you could make a patch and send it to the maintainers.

[MichaelWeaser]

Great!

Maybe you could let YaYa know that his work in changing the source code as you requested worked?

 

@Wonko - I bow to your much greater experience and knowledge in this area - do you think it is worth asking YaYa to also add a =0xhh switch as well?

 

He says in this post somewhere that the =0xhh option would be better than the =CHS option, because he says that the =CHS option is only good for MS-DOS basically.

[tinybit]

Hey, yaya accepted the proposal of --in-situ=FLAGS_AND_ID. The original FLAGS is still in the lower byte, and the higher byte is used for partition ID.

[Wonko the Sane]

@Wonko - I bow to your much greater experience and knowledge in this area - do you think it is worth asking YaYa to also add a =0xhh switch as well?

I see it differently, it's more like:
http://www.imdb.com/...uotes/qt0416285
than anything else, if you are gonna build the best bootmanager/bootloader in the world, why not do it with some style?
 
And if you think a bit about it it is also about learning from the past (small) mistakes.
 
Tinybit (or someone else among the other earlier developers of grub4dos) at the time created out of thin air the --in-situ option.
 
It has been used by hundreds, thousands or more people to boot Windows 9x/Me successfully.
 
Some 11 (eleven) years later it comes out that a "fixed" provision (that was not evidently "wrong" since it served us well for all these years), in a very "niche" case was not adequate.
 
Since it is possible to "fully open" the choices, let's have them as open as possible, you will never know when another new kid on the block will come out with a particular OS or setup for which having this choice could be useful.

The proposed =CHS option would be limited and it would make not any sense for a number of partition ID's, so it would imply either a "full" conversion table (0E=06, 0C=0B, 07=07 etc.) or anyway a lookup to see if the automatically generated partition ID has a CHS corresponding version, the =00ID will give the user the full power to do whatever he/she see fit, including strange, dangerous things.
 
I would leave the working of --in-situ "as is" (since it has served us well for all these years) if no options are provided and the optional parameters will allow any kind of "crazy" setup , while for those insisting to use older versions the explanation by tinybit and my little batch or set of commands in a .lst file will be enough to allow the same functionalities of the new, more comprehensive version.
 
 
 
 

Hey, yaya accepted the proposal of --in-situ=FLAGS_AND_ID. The original FLAGS is still in the lower byte, and the higher byte is used for partition ID.

 
Very good. 
 
 

Wonko