Alain writes with this report about the latest TDSK:
I have installed TurboDisk 2.41 in a real life heavy duty application (I am using it for indexes that keep changing) and it is running for 5 days 24h/day without problem :))
I have just one request for improuvement of TDISK: if the size requested is bellow the minimum as accidentally happended to be configured:DEVICE=TDISK.EXE 6 /E
it produces an unformated drive, which later produces many nasty errors. My suggestion is that this error situation should be solved by increasing the drive size to the minimum. This would reduce overall system erros...
I made a program to check if there is enough XMS memory and creates a .BAT file to load TDSK using DEVLOAD. It has no command line parameters, because I needed a much more complex test, reading .INI files, determining file sizes and testing more that one combination. All the basic tests are there if anyone wants to customize his own or make a more generic one. I can send it to any one, just ask ;-)
Matthias Paul responds with this note:
> I have installed TurboDisk 2.41 in a real life heavy duty application (I am using it for indexes that keep changing) and it is running for 5 days 24h/day without problem :))
Iīm happy to hear this, although I think thatīs the only thing what one can reasonably expect from well-designed software. If I would have known of anything but highly sophisticated and artifically created problems from the userīs perspective, I would have never released the BETA...
Anyway, I think that I canīt take the credit for this as it is mainly the memory manager and the kernel that might show bugs under heavy load, not the RAM disk driver. Itīs just a small interface layer between both, which, of course, must work correctly (but thatīs just mathmatics).
Since TDSK 2.42 had mainly useability fixes compared to Ciriīs 2.30, I think the remaining credit goes more to Ciri, the original author, not to me.
This might change with TDSK 2.43+, though. ;-) -- which will be a major revamping of the driver. But I havenīt found time to work on it for almost two weeks now due to other more important stuff in the queue (including 4DOS, FreeKEYB, RBIL, DRDOS, partitioning stuff, etc.).
> I have just one request for improuvement of TDISK: if the size requested ...
Itīs not a bug, but a feature... ;-)
I know of several TDSK users who explicitely make use of this feature, because sacrifying even as little as 8 Kb of precious XMS or EMS memory is too much for them, when they donīt currently use the RAM disk... (I know of at least one user who is using BITDISK instead of TDSK because TDSK is considered to be kind of a memory hog almost doubleing the BITDISK memory footprint -- at 0.5 Kb total for TDSK... ;-)
Personally I also donīt like unformatted drives, and have no problems to "waste" 8 Kb XMS/EMS just to have something reasonable there.
However, I recently found RAM disk drivers, which go down to 2 Kb for the minimal size, and I couldnīt sleep well any more, until TDSK was enabled to also support formatted drives downto 2 Kb. ;-)
So I can now save 6 Kb more as well...
The range of other parameters was also extended, and TDSK 2.43+ will now default to create a 64 Kb formatted drive without any other installation parameters, just like RAMDRIVE.SYS and VDISK.SYS do.
I also plan to add parameters to specify min and max allowed size ranges, a parameter to declare the drive geometry as "locked", and other conditions. This should help scenarios where TDSK is implicitely called from within batchjobs.
The only problem with this is the parameter handling. So far I was too lazy to rewrite the parameter handling from scratch, but I will have to do this, as the current code is just a dirty ad-hoc solution, which cannot be easily extended in a reasonable way.