34 replies to this topic

[Wonko the Sane]

Yes and no, it is is "implied" in the way these numbers are interpreted, two's complement:

https://en.wikipedia...wo's_complement

 

Try this:

calc 0x7FFFFFFF

echo %@retval%

calc 0x7FFFFFFF+1

echo %@retval%

calc 0x7FFFFFFF+1

calc %@retval%-1

 

calc 0x7FFFFFFF+2

calc %@retval%

 

calc 0xFFFFFFFF

calc %@retval%

 

 

calc 0xFFFFFFFF+1

calc %@retval%

 

 

calc 0xFFFFFFFF+42

calc %@retval%

 

the rightmost 8 characters (4 bytes) in the hex representation remain the same, they are only "interpreted" differently in decimal and of course they "wrap around" at the 32 bit limit, so the &0xFFFFFFFF does the trick.

 

Wonko

[deomsh]

Thanks for the link and the NICE exercise. You are a great teacher!

However I still do not understand why 'standalone' %@retval% gives the 'two's complement' output above 0x7FFFFFFF. Is there any use for it in grub4dos scripting?

[Wonko the Sane]

I don't know *why*, at least initially also some other commands had 32 bit values only, and if you are limited to 32 bit, it actually makes sense.

 

As said, just like it is in DOS/Windows batch command line, you need to lower the max positive value to allow for negative numbers, otherwise you wouldn't be able to do some operations, let's assume that it is/was for compatibility.

 

Now, that 0x7FFFFFFF i.e. 2,147,483,647 is a too small number for many uses is obvious but if you think about it, it wasn't that bad in the '80's or '90's, I remember buying in 1995 a Compaq desktop that should have had a 300 MB disk but (probably because they had not available that size) arrived with a 500 MB disk (with a 300 MB partition, likely because they imaged the disk in manufacturing), and if I recall correctly first 2.1 GB disks were end 1995 or 1996.

 

JFYI/as a side note, I had to write my own batches to do multiply and divisions on larger numbers in Windows NT batch:

http://reboot.pro/in...?showtopic=2986

 

Wonko

[deomsh]

Nice, I tested DIVIDER.CMD

 

[deomsh]

About dividing: I found calc can not divide 2GB+ values. I think I reported earlier.

Also using unsigned values does not give meaningfull results.



In the past I wrote my own divider: calc seems to have no problems with multiplication, addition and substraction.



But my primary school-approach is not so fast.

Maybe you can 'port' your script to grub4dos? So I can compare speed of calculation..

[deomsh]

Currently I am trying to add free clusters to a directory cluster-chain to write Long File Names to an already written Short File Name, if last directory cluster is 'full'.

I first write the Long File Name in free directory entries, then I copy the entry of the corresponding Short File Name to the entry just 'after' the Long File Name and 'delete' the original Short File Name entry by writing E5 to first byte. As such successfull. But Long File Names + Short File Name entry can use a maximum of 21 directory entries. On my 160KB test-floppy image clustersize is one sector, so reaching cluster-borders is rather common. So I have to write to the FAT(s).

My question is if the next cluster in a directory cluster-chain always must have a higher cluster number too?

[deomsh]

With a generalized approach I made a simple script to get/ set attributes on FAT12/16/32 file-systems

https://github.com/deomsh/ATTRIB.G4B

BTW I added ATTRIB.ZIP to the Repository (right-click to save files can give bad html, sorry, is my first github-project ever).

Screenshots:



Running ATTRIB.G4B on a grub4dos command-line WITHOUT arguments will show some HELP

[deomsh]

BUG FOUND, please use new release V0.4.1 of ATTRIB.G4B.

 

Also some echos added if PATH or ENTRY is not found.

 

Further changing Archive-attribute on directories now allowed.

 

https://github.com/d...ases/tag/V0.4.1

 

Print-screens to compare MS-DOS' ATTRIB.EXE and ATTRIB.G4B

 

 

Although ATTRIB.EXE of course have much more possibilities than ATTRIB.G4B, I do not understand WHY ATTRIB.EXE do not show the Directory attribute.

 

Is there some special (historical) reason?

[deomsh]

Because I was not fully satisfied with the echo-output of ATTRIB.G4B, I made some changes in the direction of a collumn-style.

 

Further: full DEVICE+PATH is shown, but only if DEVICE was not given on the command-line.

 

Version 0.4.2: https://github.com/d...ases/tag/V0.4.2

 

The new look:

 

 

I found an interesting not-fatal omission in my earlier script: echo -n > (md)%mdbase%+%clussect% && raw dd (......) while %clussect% was not declared (anymore). However grub4dos didn't take notice and happily continued this script-line.

 

In the newer version of the grub4dos debugger can be seen only echo -n is noted as executed, the part: > (md)%mdbase%+%clussect% is not expanded. Can be seen in the print-screen below just below the middle.

 

 

Question: is this normal behavior of the grub4dos debugger, any explanation?

[deomsh]

Although ATTRIB.G4B contains protection, and will not change the directory-attribute and volume-attribute, I found out that changing attributes (A R S H) on a volume-name is possible by accident in the following case:

 

1) Volume-name (Label) is in high-case written to disk

2) The Volume-name is given is 8+3 File-name format

 

See first print-screen for an example.

 

 

So I changed ATTRIB.G4B in version 0.4.3 to prevent this happening. https://github.com/d...ases/tag/V0.4.3

 

However, I added read-out of attributes if the Volume-name is given is 8+3 File-name format, but high-case only

 

See next print-screens for using version 0.4.3 with a Volume-names

 

 

BTW be aware Windows Defender does not like this script, on my Windows 10 system copy-operations takes a bit longer. I found out with help of Task Manager. No idea why.

See last print-screen.