45 replies to this topic

[DavidB]

I'm trying to find a way to change the screen resolution with certain keys (F1..F4). The command to change resolution will be in an untitled menu entry, normally used to separate "blocks" of menu entries:

title
root

What I did so far:

.........
title ^F1
set /a CURDEF=*0x8276 & 0xff > nul
if not "%CURDEF%"=="6" graphicsmode -1 640 480 > nul
if not "%CURDEF%"=="6" savedefault %CURDEF% && configfile /menu.lst
.........
title ^F2
set /a CURDEF=*0x8276 & 0xff > nul
if not "%CURDEF%"=="15" graphicsmode -1 800 600 > nul
if not "%CURDEF%"=="15" savedefault %CURDEF% && configfile /menu.lst
.........
title ^F3
set /a CURDEF=*0x8276 & 0xff > nul
if not "%CURDEF%"=="20" graphicsmode -1 1024 768 > nul
if not "%CURDEF%"=="20" savedefault %CURDEF% && configfile /menu.lst
.........
title ^F4
set /a CURDEF=*0x8276 & 0xff > nul
if not "%CURDEF%"=="24" graphicsmode -1 1280 1024 > nul
if not "%CURDEF%"=="24" savedefault %CURDEF% && configfile /menu.lst
.........

When the menu has a normal entry selected and the user presses F1..F4, it changes resolution, saves the number of that normal entry and reloads the menu; this way, after changing resolution, that normal menu entry will still be selected instead of the untitled one.
If the user selects (left/right arrow keys) one of these untitled menu entry and presses Return key, nothing happens (this way only the F1..F4 keys will work).

My questions are:
1. how to get the number of the menu entry in which you are using a command/function? I'm not talking about the selected (0x8276).
As you may noticed, I compare CURDEF with a number, which is the number of that menu (6/15/20/24). The problem is that, each time when I insert or delete other menu entries I have to modify these numbers too.
So that's why I need a way to get the number, so they can be dynamic instead of static.

2. The only way to prevent that the untitled menus would be selected after running its code was to use "savedefault %CURDEF% && configfile /menu.lst".
Is there a better way...?

Thank you.

[Wonko the Sane]

I don' t understand, excuse me if I am missing something evident, the "logic" behind the if clauses:

 

 

title ^F1
set /a CURDEF=*0x8276 & 0xff > nul
if not "%CURDEF%"=="6" graphicsmode -1 640 480 > nul
if not "%CURDEF%"=="6" savedefault %CURDEF% && configfile /menu.lst

I.e., what is the "enhancement" over:

 

 

 

title ^F1
set /a CURDEF=*0x8276 & 0xff > nul
graphicsmode -1 640 480 > nul
savedefault %CURDEF% && configfile /menu.lst

 

Wonko

[steve6375]

1. well, it seems to me that it is a bug in the hotkey feature! If you press F4 and then look at 0x8276 - it should return the menu number for F4 (not the menu number of the previously selected item!). However, this odd behaviour looks useful!

 

You could try using the savedefault command and then looking at the bytes in the savedefault file to find out what it saved?

 

2. Have you tried using a variable?

 

e.g.

if exist MYDEF default %MYDEF%

title ^F1 
set /a CURDEF=*0x8276 & 0xff > nul
set MYDEF=%CURDEF%
configfile /menu.lst

[DavidB]

@Wonko

The difference is: without those if's, when the user will select (for some reason) one of these untitled menu entries and press Return, it will change the screen resolution. But I want to be changed ONLY with F1..F4.
If a normal menu entry is selected and F1 is pressed, CURDEF has the number of that normal menu entry (and not the one running the code).



@Steve

1. Yes, it works. Thank you.
But the thing is I usually try to avoid writing/reading external files (to find internal values) - for some good reasons (slow speed, wearing USB flash, greater risk of something could go wrong and so on). That's why in my second question I asked about a better way - for both "savedefault" and "configfile /menu.lst".
Sorry for not mentioning this in my first post - the main reason is that, when you ask about an idea, usually the mind is preoccupied with finding one, not with what to avoid...

So I will consider this "the last resort"...

Another way: I could set "default (md)0x220+4" and save the entry in that memory file but the problem is that it wants the mf to have that specific "default" format...
Is there any way to "build" one fast so I wouldn't have to load it from an external file (and end up with what I am trying to avoid in the first place)?
Because writing 2048 characters with echo or write is not that much fun

2. Since the writing/reading from "default" is avoided but still reads from /menu.lst, it's better than my solution. Thank you.

[Wonko the Sane]

@Wonko

The difference is: without those if's, when the user will select (for some reason) one of these untitled menu entries and press Return, it will change the screen resolution. But I want to be changed ONLY with F1..F4.
If a normal menu entry is selected and F1 is pressed, CURDEF has the number of that normal menu entry (and not the one running the code).

Maybe stupid idea, but how would the "lock" menu.lst entry feature work?

http://diddy.boot-la.../files/menu.htm

and/or "hidden menu"?

http://www.rmprepusb...OC-Secret-menus

 

Wonko

[DavidB]

Thank you, but I don't see how lock command could help ("break a command execution unless the user is authenticated"). Should I type the password to change screen resolution..?
And I read about secret/hidden menu just before starting the thread. But I couldn't see a solution.
But if you understand what I'm trying to do and you see a way, please show me how...

 

Later edit:

Sorry if I said something to upset you but I'm so tired Going to bed...

 

So far the code (menu.lst) looks like this:

 

if not "%MAINRAN%"=="1" timeout 30 && /hotkey
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 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
if not "%CURDEF%"=="6" graphicsmode -1 640 480 > nul && set DN=%CURDEF% && configfile /menu.lst
..............
..............
title ^F2
set /a CURDEF=*0x8276 & 0xff > nul
if not "%CURDEF%"=="15" graphicsmode -1 800 600 > nul && set DN=%CURDEF% && configfile /menu.lst
..............
..............
title ^F3
set /a CURDEF=*0x8276 & 0xff > nul
if not "%CURDEF%"=="20" graphicsmode -1 1024 768 > nul && set DN=%CURDEF% && configfile /menu.lst
..............
..............
title ^F4
set /a CURDEF=*0x8276 & 0xff > nul
if not "%CURDEF%"=="24" graphicsmode -1 1280 1024 > nul && set DN=%CURDEF% && configfile /menu.lst
..............
..............
title ^F5
set /a CURDEF=*0x8276 & 0xff > nul
if not "%CURDEF%"=="26" graphicsmode 0x%DGM% > nul && set DN=%CURDEF% && configfile /menu.lst
..............
..............

 

I added DGM for the situations where the screen is using nonstandard resolution(s).

[DavidB]

Well, I have found a different way to "build" a "default" file.

 

setlocal
#writes the content of a gzipped default file; "write" detects that is gzipped and it is decompressed
write (md)0x220+4 \x1f\x8b\x08\x08\x36\xee\x28\x4f\x02\x00\x64\x65\x66\x61\x75\x6c\x74\x00\xed\x95\x4f\x0b\x82\x40\x10\xc5\x3b\x0b\x7d\x87\x17\x1d\xba\x88\x84\x14\x44\xb7\x20\x08\x2f\x1e\x22\xa8\xeb\xa6\xa3\x2e\xe8\x2c\xe8\x9a\x6c\x9f\xbe\x35\x83\xe8\x50\x10\x1d\xba\xec\x63\x60\x98\x7f\x8f\xdf\x6d\xc2\xe5\x08\x56\x63\x6f\xfa\x39\x30\x19\x84\x43\x41\xc8\x64\x49\x68\xe4\x95\x20\x1b\x84\xf3\xc5\x0a\x67\xa3\xa9\x09\xb0\x55\x3c\xd3\x48\x0a\xc1\x39\x41\xbf\x6c\x3e\xee\x7b\xab\xd3\xef\x7a\x6b\xd3\x0f\x8e\x9b\x7d\x1c\xc5\xbb\x35\xa2\x0c\x46\xb5\xe8\x04\x6b\x68\x05\x4a\xa5\xcd\x85\x65\xbe\x63\xa5\xb2\xa6\x44\x97\xc6\x47\xaa\xc0\x4a\xa3\xa6\x4a\x5d\x08\x82\x0d\x4a\xc9\xd4\x5b\x65\xb5\xaa\x9e\x27\x3e\x24\x27\x65\x9b\x4a\xce\x87\x66\x27\x6a\xb6\x45\x00\x87\xea\x50\x1d\xaa\x43\x75\xa8\x0e\xf5\x4b\xd4\x7f\x3e\xd6\xb1\x77\x03\x4e\x67\xa6\x44\x00\x08\x00\x00 > nul
#because we can't write at 0x220 (complains that it's a gzipped file), we copy it in another location
dd if=(md)0x220+4 of=(md)0x300+4 > nul
default (md)0x300+4
savedefault
cat --length=2 (md)0x300+1 | set CMN=
echo Current menu number = %CMN%
pause
endlocal

 

 

I used setlocal/endlocal to ensure that it will return to saving normally in the "default" file.

2 problems:
1. (md)0x220+4 will be read-only for any code. Is there a way to "unmap" it..?
2. still too much text, but it can be acceptable...

 

 

Later edit:

 

But what is strange is that it seems to decompress well the file ONLY in (md)0x200..0x249. Under 200 says "Disk read error", with higher than 249 says "0xD1 bytes written at offset 0x0" (which is normal) but it doesn't write anything.
I tried 250..310, 2000, 6000, 11000 - same...

[steve6375]

What do you mean by read-only and unmap it??

[DavidB]

By "read-only" I mean that any attempt to write again in that area shows "Error 70: attempt to write a gzip file"...

[steve6375]

Well you could just ignore it or may use write 0x44000 0  to corrupt it?

[DavidB]

Since I said (in the Later edit) that only 200..249 works and I see that "area"is used in other scripts, I just can't ignore it.

And what do you mean by "corrupt it"...?

[steve6375]

http://en.wikipedia.org/wiki/Gzip

gzip files are recognised by their header bytes

[DavidB]

Got it.

I knew about gzip's header, but I didn't know about writing directly in that memory area...

Thanks for the solution

[DavidB]

well, my menu looks like this now:

 

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=\x1f\x8b\x08\x08\x36\xee\x28\x4f\x02\x00\x64\x65\x66\x61\x75\x6c\x74\x00\xed\x95\x4f\x0b\x82\x40\x10\xc5\x3b\x0b\x7d\x87\x17\x1d\xba\x88\x84\x14\x44\xb7\x20\x08\x2f\x1e\x22\xa8\xeb\xa6\xa3\x2e\xe8\x2c\xe8\x9a\x6c\x9f\xbe\x35\x83\xe8\x50\x10\x1d\xba\xec\x63\x60\x98\x7f\x8f\xdf\x6d\xc2\xe5\x08\x56\x63\x6f\xfa\x39\x30\x19\x84\x43\x41\xc8\x64\x49\x68\xe4\x95\x20\x1b\x84\xf3\xc5\x0a\x67\xa3\xa9\x09\xb0\x55\x3c\xd3\x48\x0a
if not "%MAINRAN%"=="1" set DEFGZ2=\xc1\x39\x41\xbf\x6c\x3e\xee\x7b\xab\xd3\xef\x7a\x6b\xd3\x0f\x8e\x9b\x7d\x1c\xc5\xbb\x35\xa2\x0c\x46\xb5\xe8\x04\x6b\x68\x05\x4a\xa5\xcd\x85\x65\xbe\x63\xa5\xb2\xa6\x44\x97\xc6\x47\xaa\xc0\x4a\xa3\xa6\x4a\x5d\x08\x82\x0d\x4a\xc9\xd4\x5b\x65\xb5\xaa\x9e\x27\x3e\x24\x27\x65\x9b\x4a\xce\x87\x66\x27\x6a\xb6\x45\x00\x87\xea\x50\x1d\xaa\x43\x75\xa8\x0e\xf5\x4b\xd4\x7f\x3e\xd6\xb1\x77\x03\x4e\x67\xa6\x44\x00\x08\x00\x00
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 0x44000 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 0x44000 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 0x44000 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 0x44000 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 0x44000 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

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

 

Perhaps a bit too much for just changing screen resolution

[tinybit]

gzip format is not good.

 

better use lzma format.

 

with gzip file, the decompressed file length is at the end of the gzipped file. too bad! you cannot correctly decompress such a block-list file, because the last 4 bytes(of the block-list (md) file) is not equal to the decompressed file length.

 

with lzma, the decompressed file length is in the header of the lzma'ed file. so you can decompress it without problems.

[DavidB]

Thank you for the tip.

I understand but, like gzip, the lzma compressed files are automatically recognized and decompressed by grub4dos functions..? Specifically by "write" in my grub4dos version: 0.4.5c-2013-03-03...

[tinybit]

yes, lzma is supported just like gzip.

[DavidB]

Ok, it worked.

Just a problem: seems that "write 0x44000 0" can't corrupt the (md)0x220+4 and again I can't write at that location.

The lzma file is 198 bytes long. Where should I write that 0..?

 

\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

[steve6375]

Your comment about 0x220 working but not other areas intrigued me, so I investigated further.

 

I think it is because 0x220 area is used by grub4dos and so the data in that area does not contain 00's whereas the other areas you tried do:

 

Try the code below on a fresh boot:

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

Address 0x44000: Value 0x746e6572

Address 0x44000: Value 0x76767676

Address 0x44000: Value 0x76767676

0x4 bytes written at offset 0x0

Address 0x44000: Value 0x53535353

 

 

Now try again but uncomment the 3rd line:

 

Address 0x44000: Value 0x746e6572  (read)
Address 0x44000: Value 0x76767676  (write)
Address 0x44000: Value 0x0                (write)
Address 0x44000: Value 0x0                (read)  note write (md)0x220 line next is missing!!!
Address 0x44000: Value 0x0                (read)

 

So if the area being written to contains 0 as the first byte  write (md)0x220 does NOT work!!!

If you use echo fred > (md)0x220+1  then that does work.

[steve6375]

Ok, it worked.

Just a problem: seems that "write 0x44000 0" can't corrupt the (md)0x220+4 and again I can't write at that location.

The lzma file is 198 bytes long. Where should I write that 0..?

 

\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

 

try 

write 0x44000 0

write 0x44004 0

write 0x44008 0

write 0x4400c 0

[DavidB]

Your comment about 0x220 working but not other areas intrigued me, so I investigated further.

 

I think it is because 0x220 area is used by grub4dos and so the data in that area does not contain 00's whereas the other areas you tried do:

 

Try the code below on a fresh boot:

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

Address 0x44000: Value 0x746e6572

Address 0x44000: Value 0x76767676

Address 0x44000: Value 0x76767676

0x4 bytes written at offset 0x0

Address 0x44000: Value 0x53535353

 

 

Now try again but uncomment the 3rd line:

 

Address 0x44000: Value 0x746e6572  (read)
Address 0x44000: Value 0x76767676  (write)
Address 0x44000: Value 0x0                (write)
Address 0x44000: Value 0x0                (read)  note write (md)0x220 line next is missing!!!
Address 0x44000: Value 0x0                (read)

 

So if the area being written to contains 0 as the first byte  write (md)0x220 does NOT work!!!

If you use echo fred > (md)0x220+1  then that does work.

 

 

On the second test write (md)0x220 line next is not missing (on my computer at least)...

Anyway I tried with "echo -n -e %DEFGZ1%%DEFGZ2% > (md)0x11000+4" and is writing only the first byte (the second byte is \0). What am I doing wrong?

 

try 

write 0x44000 0

write 0x44004 0

write 0x44008 0

write 0x4400c 0

 

I already found that it's working with 0x44001 but thank you.

[steve6375]

FYI (in case you did not realise)

write (mem_location) takes a dword value - so

 

write 0x44000 0x33333333

write 0x44000 0x0

 

will leave

0x44000=0

0x44001=0

0x44002=0

0x44003=0

 

 

If you use  write 0x44001 0x0   then that will write four bytes of 0s to 44001, 44002, 44003 and 44004

 

re. echo - don't use -e  or it will translate it into ASCII characters!

[Wonko the Sane]

If either DavidB or Tinybit would post info on HOW exactly (with which tool) a lzma file compatible with grub4dos is created, it would be a nice piece of info.

 

@DavidB

I really have no idea on how exactly the lock or hidden actually work, but from what you report re: CURDEF, it seems to me that *0x8276 provides NOT the actual "entry that is going to be executed" but rather "the line on which the cursor is placed", i.e. when you press the hotkey the "cursor" remains where it is, but the entry is executed nonetheless.

 

What happens if you add four hidden menues, each connected to a F-key and to a resoluition change? (and then reloading the "main" menu)?

 

Wonko

[steve6375]

On the second test write (md)0x220 line next is not missing (on my computer at least)...

I tested on Oracle VBox and on Asus EeePC - both give same results  (grldr 0.4.5c 2013-05-21) ???

[DavidB]

FYI (in case you did not realise)

write (mem_location) takes a dword value - so

 

write 0x44000 0x33333333

write 0x44000 0x0

 

will leave

0x44000=0

0x44001=0

0x44002=0

0x44003=0

 

 

If you use  write 0x44001 0x0   then that will write four bytes of 0s to 44001, 44002, 44003 and 44004

 

re. echo - don't use -e  or it will translate it into ASCII characters!

 

 

Ok, I also tried "echo -n %DEFGZ1%%DEFGZ2%" but it writes the "\xnn" exactly like that, without "translating" them into hexa.
I'll search in your tutorial how to make "hexa" for echo...

LE: but, wait, isn't ASCII characters I want to wrote? yes... So echo -n -e is good but it can't write after \0...

 

If either DavidB or Tinybit would post info on HOW exactly (with which tool) a lzma file compatible with grub4dos is created, it would be a nice piece of info.

 

So far I used a Total Commander plugin

 

@DavidB

I really have no idea on how exactly the lock or hidden actually work, but from what you report re: CURDEF, it seems to me that *0x8276 provides NOT the actual "entry that is going to be executed" but rather "the line on which the cursor is placed", i.e. when you press the hotkey the "cursor" remains where it is, but the entry is executed nonetheless.

 

You're right and that's exactly what I need, because this way the code know that it can change the screen resolution and will reselect that "line on which the cursor is placed" after changing.

 

What happens if you add four hidden menues, each connected to a F-key and to a resoluition change? (and then reloading the "main" menu)?

 

Wonko

 

 

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

 

I tested on Oracle VBox and on Asus EeePC - both give same results  (grldr 0.4.5c 2013-05-21) ???

 

Maybe it's from the version difference (0.4.5c-2013-03-03), maybe it's my computer "special", who knows