China DOS Union

Originally posted by johnsonlam at 2007-1-21 02:55 AM:



The D: partition that was copied to
could NOT be accessed by Windows/NT!

How exactly was it operated?

Is it: TOdisk partition TO D:
Or: TOdisk partition TO (D:\file) ?

Does WINDOWS NT only have FAT16 and NTFS file systems?
If D: is NTFS, the program is not supported. However, under DOS, DOS cannot see NTFS. If the operation is correct, it is unlikely to have problems.

Originally posted by GOTOmsdos at 2007-1-22 12:03 AM:
Does Windows NT only have FAT16 and NTFS file systems?
If D: is NTFS, the program is not supported. However, in DOS, DOS cannot see NTFS. If the operation is correct, it is unlikely to have problems.

Windows NT 4.0 also supports FAT32, and its hard disk only has FAT.
The problem occurred after this test.

His email:

====
Johnson,

Downloaded TODisk and tried it on my system, using both:

TODisk 1:1 to 1:2

TODisk C: to D:

Both commands copy my C: partition (1:1) to my D: partition
(1:2). Both ran fine with no errors, and my D: disk ended
up identical to my C: disk, as intended. A bit slow while
copying, your friend may want to set up larger I-O buffers.
But still an interesting program, which worked O.K. for me!

Best wishes,

Jack R. Ellis
====

1
Does Windows NT 4.0 also support FAT32?
2
Saw his EMAIL, but didn't mention the error situation
3
TOdisk only used a few 64KB buffers (this is because DOS has a 64KB limit for reading and writing files each time), this is the reason for the slow speed, and also the biggest shortcoming of the program.
Or I will release the source code in a few days, let you make some changes, can we add a large buffer to try to reach or approach the speed of GHOST... This is also my greatest desire

[ Last edited by GOTOmsdos on 2007-1-23 at 02:54 AM ]

Why not use compilers that support protected mode, such as Wattcom C++, DJGPP, or FreePascal, or Delphi + WDosX? Is it because calling interrupts in protected mode is relatively slow?

Originally posted by GOTOmsdos at 2007-1-23 02:47 AM:
1
Does Windows NT 4.0 also support FAT32?
2
I saw his email, but he didn't mention the error situation.
3
TOdisk only used a few 64KB buffers (this is because of the 64KB limit of each file read and write in DOS), which is the reason for the slow speed and also the biggest shortcoming of the program.
Maybe I will release the source code in a few days, let you modify it, can we add a super buffer to achieve or approach the speed of GHOST... This is also my greatest desire.

1) Sorry, I made a mistake, his was FAT16, because it is only 2GB.

2) I reversed the two emails one after another, and the next morning his NT4 couldn't see d: anymore.

3) 64K can also be very fast as long as it is aligned. Jack may have some good ideas.
Jack's latest plan is to complete QCACHE (Full Caching, that is, the kind of Norton Cache and Smartdrv) within 8K, so if you don't mind giving him the source code, you can ask him for advice.


[ Last edited by johnsonlam on 2007-1-23 at 06:17 AM ]

Originally posted by zqlcch at 2007-1-23 03:11 AM:
Is it because calling interrupts in protected mode is relatively slow?

Interrupts might not be, but moving memory, especially XMS, might be slow!
If the program's data block read and write times are not coordinated, there might be other problems...

However, I thought of a problem:
If the capacities of C: and D: are different, TODisk will copy with the capacity of the smaller disk as the target amount, so it won't overwrite the sectors after D:

(
Note: TODisk 1:1 to 1:2

TODisk C: to D:
Without the -d or -p switch, it's the free mode, and the free mode is for expert users! Although running the program in the free mode may cause the partition to be inaccessible, since it can freely handle sectors, the program has added this function, mainly for data recovery. If absolute safety is required, the switch of the matching mode -d or -P should be added!!
)

The running results of the free mode are as follows:
1
If D: is larger than C:, it's okay, although some space is wasted
2
If C: is larger than D:
The total number of sectors recorded in the DBR (partition information) of the copied D: is greater than the original D:, which may read and write the sector area after the D: disk, that is, may read and write the disk after D!: may cause the disk after D! or even D! itself to be inaccessible.

Supplementary note:
For the -P mode
That is:
TODisk 1:1 to 1:2 -p

TODisk C: to D: -p
I can't remember if the program forcibly requires C: to be smaller than D:. I'll check the TOdisk source code later. If not, I'll add this forced check.

[ Last edited by GOTOmsdos on 2007-1-23 at 07:55 AM ]

Originally posted by johnsonlam at 2007-1-22 07:06 AM:



Windows NT 4.0 also supports FAT32, but his hard drive only has FAT.
The problem occurred after this test.

His email:

====
Johnson,

Downloaded TODisk a ...

Recently I have some time, and I will improve TOdisk:
The problem he encountered last time is likely due to
1:
The reason that C: is larger than D: (although when copying, it is still copied according to the capacity of the smaller disk... However, because the partition capacity information of the DBR of the copied disk exceeds, this mode is used for data recovery...)
2:
The absence of a mode switch means free mode, which is used for data recovery
Because there is no -P partition mode switch, the program does not update the partition table (may not be accessible)

Using the -P switch will update the partition table

The absence of a -P mode switch means free mode..

******************************************
But, considering that users generally don't read the instructions carefully, so I think it would be better to change this problem:

Swap the modes:
That is, the absence of a mode switch is the matching mode (safe)
Set -F as free mode (FREE)
(Remove the -D -P switches, whether DISK, PARTITION mode is judged by the program itself)

For example:
TODISK 1:2 TO 1:3 (no mode switch, which is safe)
Or
TODISK C: TO D: (no mode switch, which is safe)

If C: is larger than D:, it will not be processed

If you must process, you need to add the -F switch, and use free mode
This can avoid the possibility of user errors

In addition, some parts of the program have also been polished and adjusted...

The program has been updated: (the documentation will be adjusted later..)
Download address:
http://zhenlove.com.cn/cndos/fileup/files/todisk.zip

[ Last edited by GOTOmsdos on 2007-3-10 at 12:37 PM ]

These days I have some time and plan to add the following several functions: (Seeing that the functions of small tools like DPIT are still relatively practical, so I plan to add them all, so that the functions of TODisk will be more comprehensive)

Among them, since TODISK itself is a partition data tool, the functions of backing up and restoring the partition table chain are very easy to add. Just supplement a few lines of code, and this function has been added today;
Other functions, such as displaying sector information and comparing the contents of sectors and files, will be added in the next few days...

It will be released in a few days...

Recently, I have some free time and am considering improving and perfecting TODisk from the following issues:

One:

The most important:
How to improve speed?
1) Enable extremely large conventional memory (both buffers are as high as 200KB each!), but the speed improvement is not obvious.
2) Enable extended memory (both buffers are as high as 200MB each!), but the speed improvement is still not obvious.
3) Switch to DJGPP 32-bit, enable extended memory (both buffers are as high as 200MB each!, and also break through the 64KB limit of DOS for disk and file reading and writing at one time!), but the speed improvement is still not obvious.

For the first and second methods, later consideration shows that they反而 slow down the speed!. Because the 64KB limit of DOS for disk and file reading and writing at one time is still not breakable, and increasing the buffer memory slows down the speed!. Because data still needs to be moved between the small buffer and the large buffer in 64KB sizes each time.
The third one seems effective, but essentially the internal operation is the same as the first two (needing to move).

Two:

Is the hard disk UDMA reading and writing mode related to the disk and file reading and writing speed?
(Or is there any function in the C language that can control the UDMA reading and writing mode?
For example: Delay writing until reaching the internal buffer of UDMA, and then write all at once?)


Three:
I tried running SMARTDRV before running TODISK and setting the partition to be operated to WRITE-BEHIND, but it didn't work.

I really hope that those who have an understanding of this problem can give help. Thanks in advance...

The bug that partitions after the partition value is set to 0 cannot be recognized has been corrected.

Hope there will be a complete version appearing