Custom Query (69 matches)

I always wonder why files that are part of another set of files need to included in other projects such as these: These are from \ddk\base\h

src\include\devclass.h src\include\devcmd.h src\include\devhdr.h src\include\devhelp.h src\include\dhcalls.h src\include\dskinit.h src\include\fsd.h src\include\fsh.h src\include\infoseg.h src\include\iorb.h src\include\reqpkt.h src\include\sas.h src\include\strat2.h

This is not a full list. There are others pulled from other subdirectorieis of the DDK sources.

Somebody send me that list. Also the inclusion of these files violates the IBM DDK license.

when chkdsk is run simultaneously against multiple FAT32 formatted drives, the second instance/further instances of chkdsk will trap with a:

run-time error R6002

• floating-point support not loaded

SYS1811: The process has stopped. The software diagnostic code (trap number) is 000D.

I think this needs to be done: Since UFAT32.DLL is using floating point (there are some casts from int to float etc.) it is essential to ensure that the /FPi87 switch is used for the MS compiler. That will directly inline floating point instructions and avoid the use of any floating library. The makefile for UFAT32.DLL does not specify this and therefore the default is used which is /FPi = "inline with emulator".

Since Pentium (and therefore HW floating point support) is now around for almost 20 years I think that this will not be a problem :-)

The driver seems to corrupt partitions that where formatted with other filesystems: on boot, I have a couple of USB sticks attached, 2 of these are formatted with FAT32, another one is partitioned with 2 partitions and formatted with JFS and HPFS respectively (yet another is partitioned with 1 partition and formatted with JFS but this is irrelevant for this problem). On this two partition stick, the HPFS partition is getting corrupted without having been accessed at all. Running chkdsk on this HPFS partition also kills the JFS partition. Normally, running chkdsk on that HPFS partition has never caused a problem. The only idea I have is that the changes done to FS_MOUNT entry point might be causing these problems. It's invoked for every partition for EVERY filesystem driver, so that might be the relation to other filesystem drivers and filesystems.

I can also remember a problem in FS_MOUNT where the pDevCaps pointer was NULL where it should not have been in which case it was requeried in an alternative way (by the "ReturnDriverCaps?" function which I had implemented for exactly this purpose). This code was now removed from FS_MOUNT (for whatever reason).

Running Ko Myung Hun's 9.13 version is not causing these problems.