China DOS Union

How about windows disk defragmenting? Is it enough?

I also hope someone can write one.

Windows Disk Defragmenter is really too slow and inefficient, and not many people use it, not to mention it cannot run under DOS. And DOS6's DEFRAG does not support long filenames and FAT32...

Disk defragmenting requires knowledge of file systems and is relatively complex; it is not within my ability. I cannot do this work. Please let brothers skilled in this area do it.

不点: I wonder whether there is a blocklist command that runs under the DOS command line (rather than under GRUB's command line)? Because then it would be possible to check at any time whether the just-copied file is contiguous.

Let's simply put it this way: if there were a COPY command that could directly generate contiguous files, that would be good. Then there would be no need for the blocklist command either.

It would be good if someone could make such a COPY command. This difficulty should not be too great compared with defragmenting.

I do not have time; otherwise I would try it.

The following is quoted from Wengier's speech on 2003-11-16 21:42:49:
Windows Disk Defragmenter is really too slow and inefficient, and not many people use it, not to mention it cannot run under DOS. And DOS6's DEFRAG does not support long filenames and FAT32...

Right, I suddenly thought of what you said. Didn't you mention the DEFRAG program? Can this program add some kind of switch so that it only defragments one file? Or google the web and see whether there is such a thing?

The following is quoted from Wengier's speech on 2003-11-17 11:18:18:
不点: I wonder whether there is a blocklist command that runs under the DOS command line (rather than under GRUB's command line)? Because then it would be possible to check at any time whether the just-copied file is contiguous.

In order to test my vflopy, I once wrote one, under winnt and dos

The attachment is the dos one
C:\boot>blklstds.exe -h
blkls -f filename
Or
blkls -d device -f filename
-d (hd0,0) : partition where the files are C = (hd0,0) D=(hd0,4)

In order to test my vflopy, I once wrote one, under winnt  and dos  

Attachment for ddos and winnt
Open attachment

lyh728: So you are the author of VFLOPPY, thank you very much! I have two questions I want to ask:

1: When this DOS version blklstds.exe file runs, it often shows error messages such as "Exiting due to signal .." and cannot run (whereas the NT version blklst.exe does not have this problem). I don't know why. Also, when using -f to view a relatively large file, it often shows prompts such as "dir failed xx, 15, fat blocklist failed" and stops running. I wonder whether this is because the file is not contiguous, or some other reason?

2: Does the current latest version of VFLOPPY support 1.68MB floppy IMG images?

The following is quoted from Wengier's speech on 2003-11-18 0:00:16:
lyh728: So you are the author of VFLOPPY, thank you very much! I have two questions I want to ask:

1: When this DOS version blklstds.exe file runs, it often shows error messages such as "Exitingduetosignal.." and cannot run (whereas the NT version blklst.exe does not have this problem). I don't know why. Also, when using -f to view a relatively large file, it often shows prompts such as "dirfailedxx,15,fatblocklistfailed" and stops running. I wonder whether this is because the file is not contiguous, or some other reason?

2: Does the current latest version of VFLOPPY support 1.68MB floppy IMG images?

Thanks, moderator Wengier. I downloaded quite a few good things from you, and your boot disk is also great
1
The dos version of blklstds uses djgpp's dpmi, and I made it very hurriedly. It was rewritten when I ported the nt version of blklst to dos,
and testing was not very comprehensive, because I mainly tested on 2k. In this respect the nt version is in better shape
(however I indeed have not encountered an error like "Exiting due to signal .."; I guess this error is reported by djgpp's code,
and what the cause may be, I am not clear either, sorry)

As for the "dir failed xx, 15, fat blocklist failed" error appearing,
the meaning of this error is that this file xx cannot be found. In my use, this error always appears for newly created files (there may also be other times, but I have not discovered them yet),
because blklst directly reads
the physical hard disk, while 2k generally caches for a while after creating a file, and only then writes it to the hard disk. That is to say,
at this time the file system on the hard disk and the one in memory are inconsistent (at this time, if power suddenly fails, the file will be lost),

thus causing this problem. You can use a small tool from system internal, flushd (about that name),
which can force the os to synchronize the files in memory to the hard disk. Or wait for a while and try again.
I did not add this function in the program because I did not want every run of this small program to affect the os's caching strategy.

2 vfloppy only supports 144 and 288m floppy images. I feel 168m is of no use; after all, the image
file is on the hard disk, so who cares about that 1m of space
The earliest released vfloppy had a bug, causing it not to support 288M, but 1 to 2 days later I released a revised version
The one circulating online now should be the revised version

Hehe, experts are gathered here, gaining knowledge!

lyh728: Thank you for your reply. The NT version blklst indeed only rarely shows the "dir failed.." error message, so I estimate it is caused by the buffering reason you mentioned. However, the DOS version blklst often shows the "dir failed.." error message when encountering relatively large files (no buffering is loaded under DOS). I estimate this is because the porting you mentioned was relatively hurried.

Regarding VFLOPPY, what you said makes sense; 1.44MB and 2.88MB are basically enough. But could the function of writing to IMG be added in the future (just like GRUB for DOS), so that after VFLOPPY virtualizes the floppy, CONFIG.SYS and AUTOEXEC.BAT and other files can be configured/optimized under DOS at any time, making these modifications also take effect the next time it is virtualized (so this IMG virtual floppy can be used as a permanent DOS system on the hard disk or a real DOS boot disk), without having to regenerate a new IMG file under WIN?

Moderator Wengier:
Why are you always online in the early morning?

The write function you mentioned, I had this idea very early on, but I just have not had the energy to do it. I have already thought through the idea.
The current virtual floppy drive code reads all
img file contents into memory, just like that memdisk in syslinux (grub also loads that memdisk)
The advantages of this method are:
fast, completely in memory
after loading, it can be separated from the hard disk and can format, without affecting it
The disadvantages are: large memory usage, impossible to load large image files,
because of this reason, it only supports loading floppies up to 2.88M

So I originally planned to add the disk emulation method from diskem1x, that is, directly convert read operations directly into
operations on the image file on disk, and wanted to implement the write function here
Advantages:
supports large image files, and can even support iso files
Disadvantages:
cannot be separated from the hard disk, cannot delete, cannot format
These two methods complement each other; it is just that I have no time to organize the code (
The source code of Boot Scriptor contains a similar emulation method)

lyh728: I am now abroad, so the time zone is different. Night in China is afternoon here.

Regarding the current VFLOPPY reading the IMG into memory, I wonder if it can be like this: design a special command, for example a WRITEIMG command. When the user feels the modifications just made to the IMG are necessary or wants to save them, running this WRITEIMG command will automatically save the current virtual floppy being used, generated with VFLOPPY in memory, into the IMG image file on the hard disk that is used for virtualization (similar to SMARTDRV's /C option, writing the buffer in memory to disk), so that the modifications just made take effect permanently? In that case, all of VFLOPPY's existing advantages of fast speed, running completely in memory, being able to separate from the hard disk, etc. would all be retained, and it would also have the function of writing to IMG images and becoming a true readable/writable disk. What do you think?

FAST DEFRAG, I found some software in google that can quickly defragment disks. I don't know how this one is:

http://www.techtv.com/callforhelp/freefile/story/0,24330,3425341,00.html

It is a free download. Has anyone used it?