45 replies to this topic

[DavidB]

well, this code works with lzma:

 

if not "%MAINRAN%"=="1" timeout 30 && /hotkey | set dummy=
if not "%MAINRAN%"=="1" color black/cyan yellow/cyan > nul && graphicsmode | set DGM=
if not "%MAINRAN%"=="1" set DGM=%DGM:~-2,2%
if not "%MAINRAN%"=="1" set DEFGZ1=\x5d\x00\x00\x00\x01\x00\x08\x00\x00\x00\x00\x00\x00\x00\x18\x00\x2c\x41\x94\xfd\x19\xbe\x61\x25\x88\xfc\x87\x7b\x3c\x61\xaf\x31\xf3\xcb\xc2\x16\x67\xd9\x86\xff\x47\xbb\xaf\x9f\xd0\xc7\xf2\x83\x5e\xbd\xa5\x5a\x45\xdf\x2b\x22\xdd\xd3\x9a\xd4\xcf\x3e\xaa\x74\xef\x12\x67\x09\xbe\xf0\xe2\xf5\x67\x41\x8f\x9f\x8b\x9b\xb3\x90\x79\xc1\x6b\x5a\xb5\xca\x26\x20\x48\x97\x1b\xb2\x4e\xa0\xc6\xed\x79\x75\x96\xe1\x18\xc0\x57\x9b\x91\xad\x5e\x95\x33\xfe\x83\xa4\xbd\x87\xe6
if not "%MAINRAN%"=="1" set DEFGZ2=\x88\xb6\x7d\x15\xae\x8e\xfe\x62\x8b\x80\x08\x3c\xcc\x6e\xea\x6f\x06\x44\x54\x35\x23\x92\xdc\xb6\x67\xb7\x0c\x2f\x70\x5f\xc0\xc7\x82\x65\x68\x08\x65\x63\xda\xe6\xd0\xb2\xb1\x8c\x32\x85\x78\xe2\x89\xe2\xd9\x48\xcd\x6a\xd4\xa3\x73\x4c\xa6\xfd\x4c\x10\xb4\xc8\x84\x43\x99\xde\xe2\x6f\xe3\xd6\x35\xd4\x29\xd5\x05\x55\xfd\xf4\xd3\x70\xf3\xf3
if not "%MAINRAN%"=="1" set MAINRAN=1 && graphicsmode -1 800 600 > nul

if "%DN%"=="" default /default
if not "%DN%"=="" default %DN% && set DN=

...........................
...........................

title ^F1
set /a CURDEF=*0x8276 & 0xff > nul
write (md)0x220+4 %DEFGZ1%%DEFGZ2% > nul
dd if=(md)0x220+4 of=(md)0x300+4 > nul
write 0x44001 0 > nul
setlocal
default (md)0x300+4
savedefault
endlocal
cat --length=2 (md)0x300+1 | set CMN=
if not "%CURDEF%"=="CMN" graphicsmode -1 640 480 > nul && set DN=%CURDEF% && configfile /menu.lst

...........................
...........................

title ^F2
set /a CURDEF=*0x8276 & 0xff > nul
write (md)0x220+4 %DEFGZ1%%DEFGZ2% > nul
dd if=(md)0x220+4 of=(md)0x300+4 > nul
write 0x44001 0 > nul
setlocal
default (md)0x300+4
savedefault
endlocal
cat --length=2 (md)0x300+1 | set CMN=
if not "%CURDEF%"=="CMN" graphicsmode -1 800 600 > nul && set DN=%CURDEF% && configfile /menu.lst

...........................
...........................

title ^F3
set /a CURDEF=*0x8276 & 0xff > nul
write (md)0x220+4 %DEFGZ1%%DEFGZ2% > nul
dd if=(md)0x220+4 of=(md)0x300+4 > nul
write 0x44001 0 > nul
setlocal
default (md)0x300+4
savedefault
endlocal
cat --length=2 (md)0x300+1 | set CMN=
if not "%CURDEF%"=="CMN" graphicsmode -1 1024 768 > nul && set DN=%CURDEF% && configfile /menu.lst

...........................
...........................

title ^F4
set /a CURDEF=*0x8276 & 0xff > nul
write (md)0x220+4 %DEFGZ1%%DEFGZ2% > nul
dd if=(md)0x220+4 of=(md)0x300+4 > nul
write 0x44001 0 > nul
setlocal
default (md)0x300+4
savedefault
endlocal
cat --length=2 (md)0x300+1 | set CMN=
if not "%CURDEF%"=="CMN" graphicsmode -1 1280 1024 > nul && set DN=%CURDEF% && configfile /menu.lst

...........................
...........................

title ^F5
set /a CURDEF=*0x8276 & 0xff > nul
write (md)0x220+4 %DEFGZ1%%DEFGZ2% > nul
dd if=(md)0x220+4 of=(md)0x300+4 > nul
write 0x44001 0 > nul
setlocal
default (md)0x300+4
savedefault
endlocal
cat --length=2 (md)0x300+1 | set CMN=
if not "%CURDEF%"=="%CMN%" graphicsmode 0x%DGM% > nul && set DN=%CURDEF% && configfile /menu.lst

...........................
...........................

[Wonko the Sane]

You mean using this http://www.rmprepusb...OC-Secret-menus or just the way I'm doing now (title ^F1\r\ncode)?

The first you said, though I am not familiar with those.

 

Of course the "Total Commander Plugin" is not acceptable, for this time (once) it may be passed as "handy tool available at the time of experimenting" , but it is definitely "cheating".

 

Wonko

[DavidB]

The first you said, though I am not familiar with those.

 

 

I don't think it's possible to hide only some menu entries using hiddenmenu command.
It's possible with iftitle but I usually avoid it because it's slow. More, it's not reacting to the hotkey when is hidden...

 

Of course the "Total Commander Plugin" is not acceptable, for this time (once) it may be passed as "handy tool available at the time of experimenting" , but it is definitely "cheating".

 

Wonko

 

Of course, a better tool is needed when you work with a lot of files...

[tinybit]

the first byte of an LZMAed file is <= 0xE0

 

Set it > 0xE0, and then it will not be recognized as LZMA.

 

The next 4 bytes are for a long integer. it is called "dictionary size".

 

And the next 8 bytes are a long long integer, called "uncompressed file size".

 

The header size is 1 + 4 + 8 = 13.

 

In order to be recognized by grub4dos,

 

(1)  the dictionary size must be a power of 2, that is, 2 ^ n, or 2 to the n-th power.

(2)  the uncompressed file size must be not 0xFFFFFFFFFFFFFFFF, or say, a long long value of negative 1.

[tinybit]

write (md)0x220+1 \x53\x53\x53\x53

 

Such a write command is possible to fail. You know, you cannot write to a compressed file.

 

If the current  (md)0x220+1  happen to form a compressed file, the write will fail.

[steve6375]

write (md)0x220+1 \x53\x53\x53\x53

 

Such a write command is possible to fail. You know, you cannot write to a compressed file.

 

If the current  (md)0x220+1  happen to form a compressed file, the write will fail.

read 0x44000
write 0x44000 0x76767676
#write 0x44000 0x00
read 0x44000
write (md)0x220+1 \x53\x53\x53\x53
read 0x44000

 

 

If you notice - I write 76767676 to the start of the file - therefore it cannot be recognised as a compressed file by grub4dos - yet it does not write to it if it starts with 00000000. Also, no error message is given at all!

[tinybit]

previously, you have posted the successful feed back:

 

Address 0x44000: Value 0x746e6572

Address 0x44000: Value 0x76767676

Address 0x44000: Value 0x76767676

0x4 bytes written at offset 0x0

Address 0x44000: Value 0x53535353

 

So when you are sure it cannot be recognised as a compressed file, you then gain a successful write.

 

But, after you write 0x44000 0x00, what will happen? Are you 100% sure this time the (md)0x220+1 will still be uncompressed?

 

The first byte 00 is less than or equal to 0xE0.

 

the next 4 bytes could happen to be a power of 2.

 

and usually the next 8 bytes are not all 0xFF.

[steve6375]

Yes, you are correct - if I knock out 8 bytes using

write 0x44000 0

write 0x44004 0

then the write (md)0x220 works

 

So, in summary, one cannot depend on   write (md)0x(addr) (value) working   as it is entirely dependent on what the random contents of memory at (addr) happen to be!!!!

 

So, how is the user supposed to use  the write (md)0x(addr)  or write (md)(string)  reliably when it is entirely dependent on what happens to be at that memory location?

[steve6375]

Cat also does not work or give any error message!

 

write 0x44000 0x00
write 0x44004 \x20
read 0x44000
read 0x44004
cat --hex --length=32 (md)0x220+1
write (md)0x220+1 \x82

[tinybit]

you may disable compression before read or write.

 

See readme:

0000:82A4	4 (DWORD)	no_decompression (no auto gunzip)

you may set no_decompression to 1, write to the compressed(or uncompressed) file, and then set no_decompression back to 0.

[steve6375]

yes setting 82a4 to 1 solves the problem - but why isn't this done automatically when using the write command???

 

if write command then  set temp=(82a4)

set 82a4=1

do write

set 82a4=temp

 

as write only writes characters or bytes - this seems a sensible thing to do???

[tinybit]

consider someone do not want to write a compressed disk file by mistake. when read, the file is decompressed automatically. so the user could try to directly write the compressed disk file. but there is a length issue. the uncompressed file usually has a much longer size. so the write will be no use. that is why we should disable write by default.

[steve6375]

The fact is that using a command like

 

write (md)0x3000+1 0x333    may or may not work - it is entirely random and unreliable and I have found that it does not always work dependant on what happens to be already in memory!

 

 

So what you are saying is that  you prefer this case:

 

1. User issues a perfectly correct command

 

write (md)0x3000+1  ABCDEFG

 

which may fail on many systems (as I have found and as the original poster has found) because of the state of uninitialised memory on that particular system or VM

 

 

so that an illegal command made by mistake by a 'stupid' user is prevented

 

write /fred.gz ABCDEFG

 

and you choose this rather than  allow legal writes to legal memory to always work as per the grub4dos specification ???

 

Sorry, but I don't see your logic...

 

Maybe a compromise is to turn off compression temporarily when the  ADDR_OR_FILE bit of the command is an ADDRESS (e.g. (md) (rd) 0xyyyy) but leave compression on if the ADDR_OR_FILE is a FILE (like (bd)/xxxx or (hd0,0)/xxx) - is this possible to do?

 

 

 

 

[steve6375]

posted in error!

[tinybit]

you have a proposal of just allowing write to compressed md and rd files. user may complain about why disk files were rejected whereas md and rd files allowed.

do you really prefer to allow all the write by default, for both normal disks and memory devices? Or do you think thus it will be perfect? I don't think so. See my post above. And I think there is nothing absolutely perfect in the world. One can accept something, or reject it. But the thing itself is both acceptable and rejectable. you accepted something, but others might reject it. you could reject something, while someone else might accept it. developers could hardly satisfy everyone at the same time. you may ask chenall and see if he would like to accept your proposal.

[DavidB]

How about adding a new parameter to echo "-f", to write "--force", to dd "f=0/1 and so on ? Or just a function like "debug on/off": "forcewrite on/off" (default off).

When it's used or set to on it will write in that location no matter what's there...

[steve6375]

you have a proposal of just allowing write to compressed md and rd files. user may complain about why disk files were rejected whereas md and rd files allowed.

do you really prefer to allow all the write by default, for both normal disks and memory devices? Or do you think thus it will be perfect? I don't think so. See my post above. And I think there is nothing absolutely perfect in the world. One can accept something, or reject it. But the thing itself is both acceptable and rejectable. you accepted something, but others might reject it. you could reject something, while someone else might accept it. developers could hardly satisfy everyone at the same time. you may ask chenall and see if he would like to accept your proposal.

 

The user has the option of turning off compression if they really want to write to compressed files.

With my proposal of allowing writes to (md) and (rd) at least the user does not have to be concerned with it not working on some systems depending on how the system memory has been initialised or used on previous boot.

 

Consider a case where a user boots to grub4dos, loads a compressed file at say 0x30000 and then boots to it.

Then he reboots the system, and chooses a different menu option which tries to write some bytes to 0x30000  and it will fail to work because of the compressed file already at that location from the previous boot. The 'coder' has done nothing wrong. If he switches off the system and then switches it on again and re-runs the same menu option, it will work because memory will be different after a cold reboot.

 

So I think it is far better to fix this issue even if the coder wonders why writes to (rd) and (md) are allowed but writes to a compressed file are not - at least that scenario is 100% repeatable and the coder can investigate why it is not working and then write his code correctly.

[steve6375]

How about adding a new parameter to echo "-f", to write "--force", to dd "f=0/1 and so on ? Or just a function like "debug on/off": "forcewrite on/off" (default off).

When it's used or set to on it will write in that location no matter what's there...

You can already do the same by writing 1 to 0x82a4 - the point is that a coder should expect a write to work regardless of what state the memory happens to be in at the time. The grub4dos specification does not say anything about 'write to memory may sometimes not work!'

 

I have changed my code now to use echo fffffffffffffffffff > (md)0x30000+1   at the start of my main menu for each starting range of (md)0xyyyy that I use, to ensure memory is correctly initialised.

 

BTW: One of the reasons I used 'echo' rather than 'write' in much of my code was because I found that sometimes 'write' did not work or worked in some locations but not others - this issue explains why!

 

The other issue is with cat.  cat --hex does not display any bytes if it thinks that the memory contains a compressed file header but then cannot decode it. So you cannot reliably print out memory bytes  (unless you fiddle with 0x82a4)!

 

The same problem is with dd,  dd if=()/fred.txt of=(md)0x3000+0x200     may not work if (md)0x3000 previously contained a compressed file or even just bytes that look like a compressed file header!

[DavidB]

Well, I changed the code a bit:

if not "%MAINRAN%"=="1" timeout 30 && /hotkey.gz | set dummy=
if not "%MAINRAN%"=="1" color black/cyan yellow/cyan > nul && graphicsmode | set DGM=
if not "%MAINRAN%"=="1" set DGM=%DGM:~-2,2%
if not "%MAINRAN%"=="1" write (md)0x12340+4 \x5d\x00\x00\x00\x01\x00\x08\x00\x00\x00\x00\x00\x00\x00\x18\x00\x2c\x41\x94\xfd\x19\xbe\x61\x25\x88\xfc\x87\x7b\x3c\x61\xaf\x31\xf3\xcb\xc2\x16\x67\xd9\x86\xff\x47\xbb\xaf\x9f\xd0\xc7\xf2\x83\x5e\xbd\xa5\x5a\x45\xdf\x2b\x22\xdd\xd3\x9a\xd4\xcf\x3e\xaa\x74\xef\x12\x67\x09\xbe\xf0\xe2\xf5\x67\x41\x8f\x9f\x8b\x9b\xb3\x90\x79\xc1\x6b\x5a\xb5\xca\x26\x20\x48\x97\x1b\xb2\x4e\xa0\xc6\xed\x79\x75\x96\xe1\x18\xc0\x57\x9b\x91\xad\x5e\x95\x33\xfe\x83\xa4\xbd\x87\xe6\x88\xb6\x7d\x15\xae\x8e\xfe\x62\x8b\x80\x08\x3c\xcc\x6e\xea\x6f\x06\x44\x54\x35\x23\x92\xdc\xb6\x67\xb7\x0c\x2f\x70\x5f\xc0\xc7\x82\x65\x68\x08\x65\x63\xda\xe6\xd0\xb2\xb1\x8c\x32\x85\x78\xe2\x89\xe2\xd9\x48\xcd\x6a\xd4\xa3\x73\x4c\xa6\xfd\x4c\x10\xb4\xc8\x84\x43\x99\xde\xe2\x6f\xe3\xd6\x35\xd4\x29\xd5\x05\x55\xfd\xf4\xd3\x70\xf3\xf3 > nul && dd if=(md)0x12340+4 of=(md)0x12345+4 > nul && write 0x2468004 0 > nul
if not "%MAINRAN%"=="1" set MAINRAN=1 && graphicsmode -1 800 600 24:32 > nul

if "%DN%"=="" default /default
if not "%DN%"=="" default %DN% && set DN=

..................................
block of normal menu entries
..................................
title ^Ctrl+F1
set /a CURDEF=*0x8276 & 0xff > nul
set ERROR=
setlocal
default (md)0x12345+4 || set ERROR=1
if "%ERROR%"=="" savedefault
endlocal && set ERROR=%ERROR%
if "%ERROR%"=="" cat --length=2 (md)0x12345+1 | set CMN=
if "%ERROR%"=="1" set CMN=-1 && set ERROR=
if not "%CURDEF%"=="CMN" graphicsmode -1 640 480 24:32 > nul && set DN=%CURDEF% && configfile /menu.lst
..................................
block of normal menu entries
..................................
title ^Ctrl+F2
set /a CURDEF=*0x8276 & 0xff > nul
set ERROR=
setlocal
default (md)0x12345+4 || set ERROR=1
if "%ERROR%"=="" savedefault
endlocal && set ERROR=%ERROR%
if "%ERROR%"=="" cat --length=2 (md)0x12345+1 | set CMN=
if "%ERROR%"=="1" set CMN=-1 && set ERROR=
if not "%CURDEF%"=="CMN" graphicsmode -1 800 600 24:32 > nul && set DN=%CURDEF% && configfile /menu.lst
..................................
block of normal menu entries
..................................
title ^Ctrl+F3
set /a CURDEF=*0x8276 & 0xff > nul
set ERROR=
setlocal
default (md)0x12345+4 || set ERROR=1
if "%ERROR%"=="" savedefault
endlocal && set ERROR=%ERROR%
if "%ERROR%"=="" cat --length=2 (md)0x12345+1 | set CMN=
if "%ERROR%"=="1" set CMN=-1 && set ERROR=
if not "%CURDEF%"=="CMN" graphicsmode -1 1024 768 24:32 > nul && set DN=%CURDEF% && configfile /menu.lst
..................................
block of normal menu entries
..................................
title ^Ctrl+F4
set /a CURDEF=*0x8276 & 0xff > nul
set ERROR=
setlocal
default (md)0x12345+4 || set ERROR=1
if "%ERROR%"=="" savedefault
endlocal && set ERROR=%ERROR%
if "%ERROR%"=="" cat --length=2 (md)0x12345+1 | set CMN=
if "%ERROR%"=="1" set CMN=-1 && set ERROR=
if not "%CURDEF%"=="CMN" graphicsmode -1 1280 1024 24:32 > nul && set DN=%CURDEF% && configfile /menu.lst
..................................
block of normal menu entries
..................................
title ^Ctrl+F5
set /a CURDEF=*0x8276 & 0xff > nul
set ERROR=
setlocal
default (md)0x12345+4 || set ERROR=1
if "%ERROR%"=="" savedefault
endlocal && set ERROR=%ERROR%
if "%ERROR%"=="" cat --length=2 (md)0x12345+1 | set CMN=
if "%ERROR%"=="1" set CMN=-1 && set ERROR=
if not "%CURDEF%"=="%CMN%" graphicsmode 0x%DGM% > nul && set DN=%CURDEF% && configfile /menu.lst
..................................
block of normal menu entries
..................................

[tinybit]

 

graphicsmode -1 1024 768

 

Please always explicitly specify the color depth as 24:32, like the following:

 

graphicsmode  -1  1024  768  24:32

 

suppose only a 1024x768x16 exists for a machine, and it is selected, then grub4dos will fail to display or even could hangup.

 

grub4dos has no support for other color depths. Only 24 and 32 are supported. So you may use either "24,32" or "24:32". They are equivalent because actually there are no such depth values as 25,26,27,28,29,30 and 31.

[DavidB]

Thank you for the tip.

I changed the script in my previous post.