Jump to content











Photo
- - - - -

[RELEASE] SectEdit.g4b hex sector editor for grub4dos


  • Please log in to reply
72 replies to this topic

#1 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 September 2021 - 05:12 PM

Be careful :ph34r:, particularly when saving to device or file, but have fun :)

 

Not fully-fully tested, as always ideas, suggestions, bug reports are welcome.

 

:duff:

Wonko

 

P.S. updated version taking care (hopefully) of higher scancodes 

P.P.S. New version 0.2 fixed a few issues/bugs (some here - some there) and added (pseudo :w00t:) Copy-Paste function

P.P.P.S. new version 0.3 added [G]oto sector experimentally (no checks, be careful)

 

P.P.P.P.S. new version with support for large files, Load with skip and Save with seek (this latter is really-really dangerous :ph34r:)

 

P.P.P.P.P.S. new version with a new (better?) management of the status/hints lines, a new static and virtual clipboard, higher load address, a few additions here and there and a new P[R]ompt option to run commands from within the batch.

Still very, very experimental and with a lot of things to be fixed/polished up, but the overall plan seem to be coming together.

Removing older versions. 

 

v 0.6 released with a few fixes, particularly on the P[R]ompt option

v 0.7 released with a few more fixes

v 0.8 released with a number of fixes, particularly for the P[R]ompt option (thanks deomsh :) ) and for the load/save + a few other inconsistencies, [H] now toggles three-way Hints/History/Hic 

Attached Files


  • Atari800XL likes this

#2 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 09 September 2021 - 05:47 PM

Wow...

Nice!

Tested with Grub4UEFI on the now well-known DELL laptop, after using your crc32 tool:

GPTcrc32.g4b (hd0)0+34
SectEdit.g4b

Looks very cool!

Unfortunately, these are the **only** keys working on my setup:

N=Next sector, P=Previous sector, W to toggle write mode on/off (In write mode, L and S work, Z not tested).

 

Maybe Grub4UEFI doesn't support all the key functions? (Just a guess).

 

Still, this tool looks very impressive!

 

 



#3 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 09 September 2021 - 05:53 PM

OK, W for Write mode is not as dangerous as I thought :-)

It's "only" the Memory Drive being written to, didn't realize that at first...

So I *did* test the L, S and Z keys.

 

"ESC" to quit doesn't work here, either.



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 September 2021 - 06:05 PM

Strange. :dubbio:

 

Try on command line:

 

pause --test-key
set /A thiskey=%@retval%

set thiskey

 

The batch revolves around the above and:

 

#special provisions for
#Esc
if %thiskey%==0x011B goto :Esc

 

....

 

:Esc
clear
goto :eof

 

So, the only explanation I can find that on your PC (and laptops are known for this, particularly "first line" of keys, including F1-F12) the ESC key provides a different scan code.

 

And as well Arrow keys may be tricky.

 

Try getting those scan codes and post them, they can be added easily unless they conflict with some other one.  :ph34r:

And/or try an external keyboard.

 

:duff:

Wonko



#5 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 09 September 2021 - 06:31 PM

14800 up 
25000 down
44b00 left
34d00 right
54700 Home
64f00 End
94900 Page up
05100 Page down
17011b ESC

Nice and clean code, by the way. I'm no expert in Grub4Dos batch code, but I could see it wouldn't be very difficult to add extra keys to the ":comms" section.

 

On line 124, should there be a "#" comment marker?



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 09 September 2021 - 08:19 PM

Hmmm.

it seems like the scancodes are the same, only bigger

 

Try modifying the batch:

 

set /A thiskey=%@retval% > nul
set /A ascii=%thiskey%&0xFF > nul

 

into:

 

set /A thiskey=%@retval%&0xFFFF > nul
set /A ascii=%thiskey%&0xFF > nul

 

This way only the 2 rightmost bytes should be used.

 

:duff:

Wonko

PS: Yes, good catch on line #124

PPS: since the above change doesn't change the functionalities on a "normal" keyboard, I implemented it (and added the missing # on line 124), replacing the original file in first post.



#7 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 10 September 2021 - 12:55 PM

Before you made the change in the batch (set /A thiskey=%@retval%&0xFFFF) I was fooling around and I am happy (...) to say I must have hit some keys unintentionally, because I (finally) managed to screw up the partition table. At a certain point all I had left was a 2GB EFI partition with no empty space left (kinda strange on a 465gb HD).

 

Yes, that was a *good* thing, because as I said I was going to automate the repartitioning of the test hd anyways.

 

So when (not *if*) I screw things up again now, everything can be recreated on the fly: Partitioning, copying standard MS files to EFI part, copying Grub4UEFI files to EFI, copying your new batch files, etc).

 

The keyboard is working fine now, you solved it very elegantly.

Now it's time for the real stuff... (changing the partition table entries)....



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 10 September 2021 - 01:53 PM

.... all I had left was a 2GB EFI partition with no empty space left (kinda strange on a 465gb HD).

 

Well, JFYI, sometimes it happens (on USB external drives) ... ;)

https://lowkeytech.c...ts-nuts-inside/

 

:duff:

Wonko



#9 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 10 September 2021 - 02:09 PM

Great tool :magic:

 

I had initially two problems:

1) Didn't work with a bit older versions of Grub4Dos, I think because of the missing echo --mem=

2) If set-ext=.g4b last line of :help didn't find sectedit if used without .g4b-extension.

 

So first two problems easily to avoid while on the user-side.

 

Third problem: if in Write-mode number '0' was not possible for me. Nothing happened. Also some other characters beyond 'ABCDEFabcdef' were written.

 

After a debug-session I found following line [87]:

 

if %w_mode%==1 set a_chars=%a_chars%0123456789ABCDEFabcdef

 

 

After correcting to:

if %w_mode%==1 set a_chars=%a_chars%%0123456789ABCDEFabcdef

 

only allowed chars can be written now.

 

Side question: is 'saving' the right phrase in case of copying to FILE? File must exists already and must be big enough in case of a file-on-disk (also: there is no file-size check as far I can see in the call ':save').



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 10 September 2021 - 04:54 PM

Hmmm.

I am not convinced by the correction you propose for a_chars.

 

I mean, there is the issue, but that is not the right solution :dubbio: that seemingly derives from the parsing of the %0 parameter? :unsure:

 

Try changing (on line 87) to this one instead (simpler):

if %w_mode%==1 set a_chars=0123456789ABCDEFabcdef

 

When w_mode is 0 there are NO allowed a_chars, when it is 1 a_chars is the whole set of 0-9 A-F.

 

BTW the lines assigning a_chars are (at the moment) duplicated in the :w_mode subroutine (around line 357) and can be commented out from lines #86 and #87 altogether, since the initial state of the program when launched is always w_mode 0.

 

I tested the thingy on grub4dos 0.4.6a 2021-05-16, anything earlier won't probably do, but it seems that it is "forward compatible" with grub4efi, as Atari800XL reported, my bad I didn't specify the "initial" grub4dos version.

 

About the issue #2 I wonder what could be the solution/workaround?

%~dpnx0 instead of %~f0?

or

%~f0 0x60000 || %~f0.g4b 0x60000

or what? :unsure:

Disregard the above, (hopefully temporary) brain black out, this should do nicely:

 

echo Press any key to load the default 0x60000 address
pause
#%~f0 0x60000
set param=0x60000
goto :begin

 

Ok, bettered:

 

echo Press [Enter] to load the default 0x60000 address, any other key to exit
pause --test-key
set /A thiskey=%@retval%&0xFFFF > nul
#Enter
if %thiskey%==0x1c0d set param=0x60000 && goto :begin

About file saving you are right (while being wrong :w00t:, technically the feature is called "Save", NOT "Save as" that is what you are probably thinking about), I mean that is "basic" grub4dos rule that you cannot create nor enlarge files (unless using - in some cases - the fat or fatmini modules), so what do you propose?

A check for the existence of the file is already in place (if it works), do you think useful a check for the size?

 

BTW even when Load is used, one could provide as source (say) (fd0)0+2 and then specify 42 sectors, but only two sectors will be loaded (dded) to (md).

 

 

:duff:

Wonko



#11 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 10 September 2021 - 05:02 PM

This might be slightly off-topic in this thread, but I hope you can provide me with some tips.

I have the harddisk all setup now for repeated testing, the partition table will be completely "clean" when I execute the "Clean&Prep" batches.

Testing without any Windows installs should be enough in some cases, but I also do tests with (at least one) Windows install on one of the 4 "OS" partitions. I'm using the same standard menu.lst every time, this is the OS select part:

title p1
load /ntfs_x64.efi
chainloader (hd0,1)

title p2
load /ntfs_x64.efi
chainloader (hd0,2)

title p3
load /ntfs_x64.efi
chainloader (hd0,3)

title p4
load /ntfs_x64.efi
chainloader (hd0,4)

There's a tiny problem, however: Only (hd0,1) actually has a Windows install, so selecting the "P1" item should be the only working selection.

When I select "P2", however, Grub4Dos proceeds with booting Windows from the first partition anyway. Why is that?

 

When I try to repeat this from the command line, this is what I get (I'm skipping the "load /ntfs_x64.efi" commands in the examples below):

 

chainloader (hd0,1)     ===>   Working, no error message (there is an OS on this partition)

boot                             ===>   Windows 10 is booted

 

but:

 

chainloader (hd0,2)    ===> "Failed to load virtual partition image" (as expected, there is no OS on this partition)

boot                            ===> Windows 10 is STILL booted from the "other" partition (hd0,1)

 

So on the command line, at least I get a warning that there is something wrong. How can I change my menu.lst to "capture" the "Failed..." error message?

 

Thanks!



#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 10 September 2021 - 05:21 PM

Try using root command

root (hd0,1)

and then

root

should give

(hd0,1)

 

Whilst the

root (hd0,2)

should give an error. :unsure:

 

Or check for the presence of the Windows EFI files before unconditionally using chainloader. :dubbio:

 

:duff:

Wonko 


  • Atari800XL likes this

#13 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 10 September 2021 - 06:33 PM

root (hd0,2)

doesn't give an error.

 

I think it's very strange that "chainloader (hd0,2)" gives the proper error in command line mode ("Failed to load virtual partition image") but we can't capture this error in menu.lst?

 

I couldn't find a way to find a specific file on a specific partition, could you please provide an example?



#14 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 10 September 2021 - 11:39 PM

Hmmm.

I am not convinced by the correction you propose for a_chars.

 

I mean, there is the issue, but that is not the right solution :dubbio: that seemingly derives from the parsing of the %0 parameter? :unsure:

 

Try changing (on line 87) to this one instead (simpler):

if %w_mode%==1 set a_chars=0123456789ABCDEFabcdef

 

When w_mode is 0 there are NO allowed a_chars, when it is 1 a_chars is the whole set of 0-9 A-F.

 

BTW the lines assigning a_chars are (at the moment) duplicated in the :w_mode subroutine (around line 357) and can be commented out from lines #86 and #87 altogether, since the initial state of the program when launched is always w_mode 0.

 

Indeed, debug showed 'sectedit.g4b' as part of %a_chars%, so a simple %0-thing

 

I made a correction to let your script work for me. If you say some lines should be rewritten instead: feel free, its all yours. I tested your correction: without %a_chars% in line 87, is working too.

 

I did only a general reading of your script and some fast debugging (with Grud4Dos 20190909 I got error 30). A serious study will cost me about 8-10 hours at the minimum to understand what you have been doing, and much more if I wanted to rewrite your script - which it's not the case. So don't expect serious criticism. :(

 

At least I found a gem I can use for a keyboard-code related project: echo -e "\%ascii:~1%" | set key= very interesting. :rolleyes:

 

 

About file saving you are right (while being wrong :w00t:, technically the feature is called "Save", NOT "Save as" that is what you are probably thinking about), I mean that is "basic" grub4dos rule that you cannot create nor enlarge files (unless using - in some cases - the fat or fatmini modules), so what do you propose?

A check for the existence of the file is already in place (if it works), do you think useful a check for the size?

 

BTW even when Load is used, one could provide as source (say) (fd0)0+2 and then specify 42 sectors, but only two sectors will be loaded (dded) to (md).

 

'Save as' would imply a different file-name in my opinion. Of course I know dd cannot enlarge a file, BUT if the filesize is unchanged, 'Save' is good.

 

Size checking will be useful only if the size is changed, I understand that should be not the case? But I don't understand what you say about 'only two sectors will be loaded'.

 

I loaded your whole script (rounded up 24 sectors) after starting at (md)0x19000. Watched the script in all 24 sectors, zerod all sectors (after going to the next loaded sector, 'Write mode' is set 'OFF' - seems to me a logic decision) and saved to same file. Afterwards file was fully zerod out. .

 

This is the result (my online converter had too many problems with the hex-part):

grub> (hd0,0)/sectedit.g4b
Error 13:(http://grub4dos.chenall.net/e/13)
Invalid or unsupported executable format
grub>
grub> cat --length=0 /sectedit.g4b ;; echo %@retval%
11801
grub> cat --locate=\x00 /sectedit.g4b > nul ;; echo %@retval%
11801
grub> calc 11801/512 ;; echo %@retval%
23
grub>

Or did I misunderstood you about the 'two sectors'-max?



#15 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 September 2021 - 08:05 AM

@deomsh
I meant that the dd (generally, but also the version in grub4dos) is at the same time "smart" and "dumb".it tries to do exactly what is told, but when that is not possible resolves to doing the "closest" thing, practical example:
dd if=(md)0x300+2 of=(md)0x360+50 bs=512 count=42
will result in the message:
buf_size=0x10000 loops=0x1, in_pos=0x0 out_pos=0x0
000000000
Bytes read / written = 0x400 / 0x400

while the user most probably wanted to read and write 42 sectors, the dd finds that the source is only 2 sectors in size and copies only them.

Vice versa:
dd if=(md)0x300+42 of=(md)0x360+5 bs=512 count=42
will result in the message:
buf_size=0x10000 loops=0x1, in_pos=0x0 out_pos=0x0
000000000
Bytes read / written = 0x5400 / 0xA00

all 42 sectors are read from source but only 5 are written to target (because target is 5 sectors in size only)

So one would need to check (both when the Load and the Save commands are used) that the source and destination are "compatible" with the amount of sectors that dd is asked to copy and refuse to run, to avoid that an error by the user results in something different from the intentions of the user, is this the check that is missing and that you are suggesting to add? :unsure:

@Atari800XL
root (hd0,2)
find /mydir/myfile.ext && echo File /mydir/myfile.ext found.
find /mydir/myfile.ext || echo File /mydir/myfile.ext NOT found.

 

Try also:

chainloader (hd0,2) && boot

commandline

 

 

:duff:
Wonko


  • Atari800XL likes this

#16 Atari800XL

Atari800XL

    Frequent Member

  • Advanced user
  • 192 posts
  •  
    Netherlands

Posted 11 September 2021 - 09:27 AM

Thank you very much, Wonko

I tried your second suggestion first, in menu.lst:

 

chainloader (hd0,2) && boot

commandline

 

This looked very promising, I believe I even understand the logic here (even though I still have to get used to the Grub4Dos batch syntax, luckily your excellent batches are very informative!):

- "boot" should only be executed when the "chainloader (hd0,2)" command exits *without* error. Correct?

- If there *is* an error (which I can see with my own eyes: "Failed to load virtual partition image", "boot" should not be executed, but instead the next command "commandline" should be executed.

 

Sounds logical, but the bloody thing still boots the OS on partition 2 (hd0,1).

This is very weird to me, because there are no files at all on (hd0,2), so why the heck is Grub4UEFI trying to "help me" and boot just any old OS it finds (without being asked?).

 

JFYI: I'm using Grub4UEFI to boot (S:\EFI\Microsoft\Boot\bootmgfw.efi), there's only 1 OS installed (the other 3 OS partitions meant for multiboot testing are still empty), I even removed S:\EFI\Microsoft\Boot\BCD (not needed with Grub4UEFI).

 

 

For now, I will proceed with your other suggestion:

 

root (hd0,2)
find /mydir/myfile.ext && echo File /mydir/myfile.ext found.
find /mydir/myfile.ext || echo File /mydir/myfile.ext NOT found.



#17 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 11 September 2021 - 10:13 AM

v nice but some issues...

 

Unfortunately it seems the echo --mem command has been changed over different versions!

Older versions of grub4dos  use -mem  not --mem  !!!

Yaya or someone has changed it sometime after 2020!

 

I used

help echo > (md)0x200+1
set mem=-mem
cat --locate=--mem (md)0x200+1 > nul && set mem=--mem

to make it work on older versions as well and then use  %mem% in the code.

 

 

Also in grub4efi graphics mode, it does not display the correct characters.

Maybe use text instead?  e.g. UP  DOWN  PAGEUP etc?

 

 

There are some issues if editing two byte or more - e.g. press W then type 3 3 3 3  (number 3 four times)

it edits bytes to 33 30 30  Caused by too many environment variables

 

The Load and Save command - not obvious what it expects??. suggest you give example sequence of commands in a usage message? e.g. if enter (hd0) or (hd0,0) it says not found - seems to need (hd0)0+2  but then you as for sectors when I already specified 2 ??  If specify a file (has / in input), you could get length of file using cat command and round up to nearest sector maybe?

 

I got 'error while parsing number' bomb-out. I loaded a Windows disk MBR using L, then pressed W to go to edit mode, then attempted to edit first byte (was value EF) and crashed out. Seems to have problems.. gets stuck in Save and cant exit, etc.

Caused by too many environment variables

Attached Thumbnails

  • sectedit.JPG

Edited by steve6375, 11 September 2021 - 02:32 PM.


#18 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 11 September 2021 - 10:54 AM

call Fn.11 "%a_opers%" %key%
if not %@retval%==0 call :opers %key%

??? cant find use for this in code ??

 

--- some issues caused by using too many variables as I tested from within e2b which already had 20+ variables.

 

I fixed using set *

:begin
setlocal
set * && set param=%param%
help echo > (md)0x200+1
set mem=-mem
cat --locate=--mem (md)0x200+1 > nul && set mem=--mem
debug msg=0
pager off


#19 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 11 September 2021 - 11:00 AM

would be nice if Next and Previous would be prevented from going outside of buffer area?

 

e.g. load (hd0)0+3   Sectors = 3

does not limit buffer area


Edited by steve6375, 11 September 2021 - 02:33 PM.


#20 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 11 September 2021 - 11:39 AM

in byte edit mode, I can enter . (period) and space  and non-hex characters.

 

bug is fixed here

if %w_mode%==1 set a_chars=%a_chars%%0123456789ABCDEFabcdef

you need %% because %0 is special in a batch file!

 

though not sure why you need %a_chars% in there as a_chars is set to nothing just before that line?



#21 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 11 September 2021 - 11:59 AM

Load and Save not working on grub4efi because pause --test-key returns  0x0d for ENTER in efi.

 

I also added





if %thiskey%==0x08 call :comms "CE"

Attached is current modified file for you to compare.

 

under grub4efi there is still a [null] character showing under byte form...

Attached Thumbnails

  • sectedit2.JPG


#22 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 September 2021 - 06:02 PM

Steve6375, please, NO. :frusty:

 

As always, you are perfectly free to fork the half-@§§ed script and make your (better) own.

 

Otherwise the rules of the game are the following:

1) the user reports a bug 

OR:

2) a feature request/suggestion

AND/OR:

3) a possible way to solve the bug [1] or to implement the feature/suggestion

AND:

when/if I have time I will see how to modify the script, making the corrections/fixes I see fit, the way I see them fit.

 

I am deleting your attachment :w00t: :ph34r:, no offence intended :), but I already have enough versions with different fixes (good and bad) and having other versions published or non-published will only create havoc.

 

When/If the stupid batch will actually work properly on text mode on grub4dos and possibly on grub4efi, then (and only then) we might talk about (stupid) graphic mode.

 

:duff:

Wonko

 

[1] ONLY AFTER having checked that the issue has not been already talked about and the "proper" fix already talked about, namely:

http://reboot.pro/in...554#entry219344

http://reboot.pro/in...=22554&p=219331



#23 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 11 September 2021 - 06:10 PM

Sure, it was only for you to compare, not intended as a fork or replacement.

#24 deomsh

deomsh

    Frequent Member

  • Advanced user
  • 196 posts
  •  
    Netherlands

Posted 12 September 2021 - 09:46 AM

@Wonko,

So I misunderstood you.

Yep, it is a bit special if sectors are specified in the source they can 'overrule' the amount given in the sector-input. But I can live with that.

 

In case of editing sectors in an image-file, it would be nice if it was possible to load one ore a few sectors that start later in the file. For instance the PBR if the image contains a MBR. Same with saving. So a skip-dialog.

If thats not possible, a goto loaded sector-number instead.

BTW using FAT/FATMINI to create files and save to them, doesn't seem needed to me. The user can make empty files before using SECTEDIT.G4B, for instance to backup a MBR or PBR before making changes. 



#25 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 12 September 2021 - 09:49 AM

Would be nice if  

SectEdit.g4b (hd0)0+20 

worked from command line?

It just defaults to use memory buffer somewhere,

(maybe check size is not too stupidly large?).






2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users