DOS ain't dead

I have created UPTIME, a tool to mimic UNIX uptime under 16 bit DOS.
It started as a FAST Compiler experiment, but is now in ASM:
http://nikkhokkho.sourceforge.net/static.php?page=UPTIME

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

Just announced in FreeDOS too:
https://sourceforge.net/p/freedos/news/2017/06/unix-like-utilities-for-freedos-uptime/

> I have created UPTIME, a tool to mimic UNIX uptime under 16 bit DOS.
> It started as a FAST Compiler experiment, but is now in ASM:
> http://nikkhokkho.sourceforge.net/static.php?page=UPTIME

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

Ingenious idea to create an UPTIME tool for DOS, Javier!

Alas, the provided Sourceforge project's homepage isn't supported by
the Links browser. I could only load it from the ibiblio.org location.

Static links to files on SF would be the best ... instead of loading a
5 KB Zipfile, Links starts to load a 99.9 MB FileOptimizerSetup.exe
from the presented link.

I just saw your ZEROFILL utility there. A good idea as well! I use the
FILL-0.COM tool from 1986 for the same purpose. Alas, some Unices exist
which do not possess a zero device, thus I happened to crowd a virtual
disk's partition with ZEROFILLed dummy files in order to improve the
image's compressibility. BTW, tools like ZEROFILL or FILL-0 should
*not* be used to clean solid state disks. From the SSD controller's
perspective, such action would mark the entire drive as being "used",
and consequently decrease it's write performance.

Greetings, Torsten

Glad you liked the idea. ZEROFILL is already in the FreeDOS repository, so you can easily grab it from there: https://www.ibiblio.org/pub/micro/pc-stuff/freedos...distributions/1.2/repos/pkg-html/zerofill.html. Unfortunately it is still 1.04, and not latest 1.05.

UPTIME, even if announced on the FreeDOS list, it is not yet at ibiblio AFAIK. So you can try those direct links:

https://downloads.sourceforge.net/project/nikkhokk...%2F&ts=1499069822&use_mirror=netcologne

https://downloads.sourceforge.net/project/nikkhokk...5%2F&ts=1499069819&use_mirror=10gbps-io


> Ingenious idea to create an UPTIME tool for DOS, Javier!
>
> Alas, the provided Sourceforge project's homepage isn't supported by
> the Links browser. I could only load it from the ibiblio.org location.
>
> Static links to files on SF would be the best ... instead of loading a
> 5 KB Zipfile, Links starts to load a 99.9 MB FileOptimizerSetup.exe
> from the presented link.
>
> I just saw your ZEROFILL utility there. A good idea as well! I use the
> FILL-0.COM tool from 1986 for the same purpose. Alas, some Unices exist
> which do not possess a zero device, thus I happened to crowd a virtual
> disk's partition with ZEROFILLed dummy files in order to improve the
> image's compressibility. BTW, tools like ZEROFILL or FILL-0 should
> *not* be used to clean solid state disks. From the SSD controller's
> perspective, such action would mark the entire drive as being "used",
> and consequently decrease it's write performance.
>
> Greetings, Torsten

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

Thank you, Javier!

Your description on ZEROFILLs usage matched own observerations, this is
why I was so pleased. Michal Necasek has written a VESA miniport display
driver for WinNT 3.1 to 6.2 aka Windows 7, the 1.44 MB floppy image is on
http://www.os2museum.com/files/videomp.img . While the driver files use
37413 bytes (12671 bytes zipped), videomp.img compresses to as much as
1.2 MB! The ZEROFILLed image compresses 82 times better, to 14591 bytes.
With huge image files, such effects become the more evident.

Yes, indeed, UPTIME 2.40 is (as on Thu, Jun 29, 2017) available on
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/uptime/chamorro/uptime240.zip

True static (and thus cacheable) URLs of the mentioned SF locations:
http://netcologne.dl.sourceforge.net/project/nikkhokkho/UPTIME/2.40/uptime.zip
http://10gbps-io.dl.sourceforge.net/project/nikkhokkho/ZEROFILL/1.05/ZEROFILL.ZIP

Regards, Torsten

Nice results!

> Thank you, Javier!
>
> Your description on ZEROFILLs usage matched own observerations, this is
> why I was so pleased. Michal Necasek has written VESA miniport display
> driver
> for WinNT 3.1 to 6.2 aka Windows 7, the 1.44 MB floppy image is on
> http://www.os2museum.com/files/videomp.img . While the driver files use
> 37413 bytes (12671 bytes zipped), videomp.img compresses to as much as
> 1.2 MB! The ZEROFILLed image compresses 82 times better, to 14591 bytes.
> With huge image files, such effects become the more evident.
>
> Yes, indeed, UPTIME 2.40 is (as on Sat, Jun 29, 2017) available on
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/unix/uptime/chamorro/uptime240.zip
>
> True static (and thus cacheable) URLs of the mentioned SF locations:
> http://netcologne.dl.sourceforge.net/project/nikkhokkho/UPTIME/2.40/uptime.zip
> http://10gbps-io.dl.sourceforge.net/project/nikkhokkho/ZEROFILL/1.05/ZEROFILL.ZIP
>
> Regards, Torsten

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

> BTW, tools like ZEROFILL or FILL-0 should
> *not* be used to clean solid state disks. From the SSD controller's
> perspective, such action would mark the entire drive as being "used",
> and consequently decrease it's write performance.

We would need to program a DOS trim tool for SSDs. Maybe some code of zerofill could be reused for searching empty all clusters (I didn't checked how it works / on what level) and then send proper ATA trim command to sectors that have to be discarded...

---
DOS gives me freedom to unlimited HW access.

Hi,

On Thu, Jul 27, 2017 19:28 Raye R. wrote:
>DOS trim tool for SSDs. Maybe some code of zerofill could be reused
>for searching empty clusters [...] and then send ATA trim commands
>to sectors that have to be discarded.

I consider this as technically impossible. Tools like FILL-0 or ZEROFILL
write a perpetually rising file containing zeroes (00h) to every empty
cluster of a disk or disk image.

Only the operating system understands (and needs to know) where this file
is actually written. While there are some DOS tools which address clusters
directly (DISKEDIT, DEFRAG), deliberate TRIMming of particular clusters
(or, rather sectors) requires a close interaction with the file system
which, on it's side, needs to support this as well.

Under Linux, TRIM became available for ext4 since mkefs 1.41.10; or for
NTFS with Windows 7. If I got things right, both file systems store the
required data (information on TRIMmable sectors) within their structures.
FAT32 could hardly be extended in a similar manner.

At least, issuing ATA Security Erase commands is possible from within DOS.
In 2000, Alex Mina had written an ATA Password Tool, search for "atapwd"
(Readme in Ukranian or so, if you understand this). I had once used it to
unlock a password protected disk, but ATAPWD.EXE knows ERASE commands as
well. Never tested them, nor do I know how they work on SSDs. Used fstrim
and hdparm only.

I hope you don't mind me quoting from a personal mail here, it's because
your reflections may be of interest for others.

On Tu, Aug 3, 2017 03:25, Raye R. wrote:
>The trim tool is just in an idea state. I could look at the new
>ATA spec how exactly the TRIM command looks like. I would expect
>it accepts a list of LBA sectors address to discard. Then it would
>be needed to scan the entire FAT for unused clusters and send TRIM
>for all sectors of that clusters.
>I have a multiboot system with windows and linux so I can run a
>fstrim command to do the job
> http://man7.org/linux/man-pages/man8/fstrim.8.html

Nice idea, didn't consider this: while FAT/FAT32 cannot store information
on discardable sectors itself, it is still possible to collect such data
independently, and to pass these to an appropriate TRIM tool. Due to the
complexity of file system structures, reliable tools are difficult to implement.
For example, a FAT32-capable DEFRAGger is still unavailable, the
same applies to CHKDSK (only found the buggy DOSFSCK), and
ReactOS 0.4.4's CHKDSK[X] cannot correct neither FAT nor FAT32.
Essentials ought to come first.

Regards, Torsten

Hi,
also Eric mailed me, that use of zero fill utility is useless in this case (even it waste some SSD writes that are not necessary for TRIM). As I though about it later I agree.
BTW I tried fstrim again, it works fine on a Linux ext but it cannot work on FAT(32), it's a pity that they didn't implemented support for it.

---
DOS gives me freedom to unlimited HW access.

Hi,

> Only the operating system understands (and needs to know) where this file
> is actually written.
FAT32 is extremely well documented (and fairly easy to implement).

> While there are some DOS tools which address clusters
> directly (DISKEDIT, DEFRAG), deliberate TRIMming of particular clusters
> (or, rather sectors) requires a close interaction with the file system
> which, on it's side, needs to support this as well.
wrong. basically 'locate empty clusters and TRIM' requires no interaction
with filesystem at all; at least in single tasking OS.

> Due to the
> complexity of file system structures, reliable tools are difficult to
> implement.
if you consider FAT complex, stop writing in this forum.

> For example, a FAT32-capable DEFRAGger is still unavailable, the
> same applies to CHKDSK (only found the buggy DOSFSCK), and
> ReactOS 0.4.4's CHKDSK[X] cannot correct neither FAT nor FAT32.

I assume this is all new and undiscovered area for you.

DEFRAGGing and CHKDSK are orders of magnitudes more complicated to implement as this process has many more variables.