OS/2 Programming (Fidonet) Saturday, 16-Oct-1999 to Friday, 22-Oct-1999 +----------------------------------------------------------------------------+ From: MIKE RUSKAI 17-Oct-99 12:19:00 To: ALL 17-Oct-99 19:31:19 Subj: Attn: HPFS gurus I've been collecting information on HPFS's system area lately, and to do that, I've been reading the HPFS SuperBlock using DosDevIOCtl(). Since I haven't seen information that says anything to the contrary, I've been assuming that the SuperBlock is on LSN 16 of a drive, period. However, I've had two people so far come up with odd results for their directory band size, and when I had them send me what's supposed to be their SuperBlock for the drive in question, it turns out to clearly not be. With one, I actually received 18 sectors of data (because I couldn't at first figure out how to read only one non-0 sector with DosDevIOCtl()). That one clearly contained Boot Manager code. The other may have been the same, but I only received one sector worth. Before I go further, here's the C code that's used to read the SuperBlock: /* reading SuperBlock */ ULONG bpParmLen, bpDataLen, sectorSize; HFILE driveHandle; /* handle from DosOpen() */ char *sdata; int i; TRACKLAYOUT *tl; #define SECC 1 /* sector count to read */ bpParmLen=sizeof(TRACKLAYOUT)+sizeof(ULONG)*SECC; tl=(PTRACKLAYOUT)malloc(bpParmLen); bpDataLen=sectorSize*SECC; sdata=(char*)malloc(bpDataLen); memset(sdata, 0, bpDataLen); tl->bCommand=0; tl->usHead=1; tl->usCylinder=0; tl->usFirstSector=0; tl->cSectors=SECC; /* The loop allows reading more than one sector with a simple change to the SECC definition. */ for (i=0; iTrackTable[i].usSectorNumber=i+17; tl->TrackTable[i].usSectorSize=sectorSize; } rc=DosDevIOCtl(driveHandle, IOCTL_DISK, DSK_READTRACK, tl, bpParmLen, &bpParmLen, sdata, bpDataLen, &bpDataLen); /* end */ The declarations are, of course, at the beginning of the entire source file (you can see it at http://home.att.net/~thanny/hpfssi.zip), and the only notable thing that's happened before the above is the retrieval of the drive's sector size, via a DosDevIOCtl() category 8, DSK_GETDEVICEPARMS call. Which is more likely, that in rare cases the above would not read LSN 16 at all, or that in rare cases the SuperBlock doesn't reside at LSN 16 at all? Naturally, I'm interested in solutions that address the problem in either case. Mike Ruskai thannymeister@yahoo.com ... Had to give away the kids - The cat got allergic. ___ Blue Wave/QWK v2.20 --- Platinum Xpress/Win/Wildcat5! v3.0pr2 * Origin: FIDO QWK MAIL & MORE! WWW.DOCSPLACE.ORG (1:3603/140) +----------------------------------------------------------------------------+ From: David Noon 15-Oct-99 18:39:00 To: David Van Hoose 17-Oct-99 22:38:02 Subj: GetGetInfoBlocks In a message dated 10-14-99, David Van Hoose said to All about "GetGetInfoBlocks" Hi David, DH>Does anyone here know if there is a Linux version DH>of DosGetInfoBlocks()? I doubt it, as UNIX system calls are rather different from the OS/2 API. Besides, it would be off-topic. We don't discuss LINUX programming in this echo. Regards Dave ___ * MR/2 2.25 #353 * Caffeine is not a drug, it's a vitamin! --- Maximus/2 3.01 * Origin: Air Applewood, OS/2 Gateway to Essex 44-1279-792300 (2:257/609) +----------------------------------------------------------------------------+ From: MIKE RUSKAI 18-Oct-99 01:44:00 To: ALL 18-Oct-99 09:06:05 Subj: DosDevIOCtl(), again Well, I think I figured out what I was doing wrong the first time around, in not always getting the HPFS SuperBlock. Rather than figuring out why there were 64 sectors of garbage before the boot sector on the drive, I kludged the code. It worked on most drives, because most drives apparently have the same number of hidden sectors. As it turns out, which at least some of you must know, there is a count of "hidden" sectors on a drive, retrievable via a category 8, DSK_GETDEVICEPARAMS call, in the BIOS parameter block data. So, rather than incrementing the heads value (to increase the sector offset by the drive's sectors/track value), I just added the hidden sector count, and it worked fine. More importantly, it should work on other drives. Neat stuff. Mike Ruskai thannymeister@yahoo.com ... "...we believe that OS/2 is the OS of the 90's" - Bill Gates, Comdex ___ Blue Wave/QWK v2.20 --- Platinum Xpress/Win/Wildcat5! v3.0pr2 * Origin: FIDO QWK MAIL & MORE! WWW.DOCSPLACE.ORG (1:3603/140) +----------------------------------------------------------------------------+ From: Vitus Jensen 17-Oct-99 11:35:00 To: MIKE RUSKAI 18-Oct-99 15:30:18 Subj: DosDevIOCtl, cat8, f64 Moin MIKE, 14.10.99 19:29, MIKE RUSKAI wrote a message to ALL : MR> I'm collecting information on the size of the HPFS directory MR> band, with respect to the size of the drive. To do this, I read MR> the Super Block by opening the drive as a file. MR> This fails, however, with drives over 2GB in size, since MR> DosRead() and cousins can't handle files that size (except MR> perhaps on Aurora - I had one person run it successfully on a MR> 14GB drive, and am awaiting information on what he's running). MR> To get around this, I figure I need to make a call to MR> DosDevIOCtl(), MR> category 8 (IOCTL_DISK), function 0x64 (DSK_READTRACK). ... No, you need the following IOCtl: =============================================== DosRead/Write in direct-access mode will normally fail if the partition is greater than four gigabytes in size. If you wish to write an HPFS editor or other tool, you will need to know the "secret password" that unlocks the big disks. After you use DosOpen to get a handle to that volume, use FSCTL FSC_SECTORIO (0x9014) and in the parameter list, put a pointer to 0xDEADFACE. Doing so will put the handle in "sector" mode. All offsets and sizes will refer to sectors instead of bytes, allowing you to address 64Gb. ================================================= From "Undocumented Features of OS/2" (os2undoc.zip, 48K) C-x C-s Vitus The Crazy Teaparty: X75 & V90S, 24h, 7d, 52w, +49-5136-893003 --- Sqed/rexx 300: * Origin: Just say NO! to Micro$oft Windows. (2:2474/424.1) +----------------------------------------------------------------------------+ From: David Van Hoose 18-Oct-99 09:55:00 To: David Noon 18-Oct-99 16:08:14 Subj: GetGetInfoBlocks -> I doubt it, as UNIX system calls are rather different from the OS/2 -> API. Besides, it would be off-topic. We don't discuss LINUX -> programming in this echo. Okay.. I am just having a nasty problem with C compilers making some very nasty machine code, so I have been writing my apps in C and outputing assembly to fix up. When I do this, I cannot access the command line parameters. -Dave --- PCBoard (R) v15.4 (OS/2) 250 Beta * Origin: Destiny BBS: 1-850-477-1262 (1:3612/333) +----------------------------------------------------------------------------+ From: MIKE RUSKAI 19-Oct-99 07:34:00 To: VITUS JENSEN 20-Oct-99 00:12:22 Subj: DosDevIOCtl, cat8, f64 Some senseless babbling from Vitus Jensen to Mike Ruskai on 10-17-99 11:35 about DosDevIOCtl, cat8, f64... VJ> Moin MIKE, VJ> 14.10.99 19:29, MIKE RUSKAI wrote a message to ALL : MR> I'm collecting information on the size of the HPFS directory MR> band, with respect to the size of the drive. To do this, I read MR> the Super Block by opening the drive as a file. MR> This fails, however, with drives over 2GB in size, since MR> DosRead() and cousins can't handle files that size (except MR> perhaps on Aurora - I had one person run it successfully on a MR> 14GB drive, and am awaiting information on what he's running). MR> To get around this, I figure I need to make a call to MR> DosDevIOCtl(), MR> category 8 (IOCTL_DISK), function 0x64 (DSK_READTRACK). VJ> ... VJ> No, you need the following IOCtl: VJ> =============================================== VJ> DosRead/Write in direct-access mode will normally fail if the VJ> partition is greater than four gigabytes in size. If you wish to write VJ> an HPFS editor or other tool, you will need to know the "secret VJ> password" that unlocks the big disks. After you use DosOpen to get a VJ> handle to that volume, use FSCTL FSC_SECTORIO (0x9014) and in the VJ> parameter list, put a pointer to 0xDEADFACE. Doing so will put the VJ> handle in "sector" mode. All offsets and sizes will refer to sectors VJ> instead of bytes, allowing you to address 64Gb. VJ> ================================================= VJ> From "Undocumented Features of OS/2" (os2undoc.zip, 48K) Interesting. I've already figured it out using DosDevIOCtl(), though the above might prove useful in the future. Is that to say that DosSetFilePtr() will also treat parameters as sector offsets? Mike Ruskai thannymeister@yahoo.com ... Keep your OS/2 system healthy by practicing safe REXX. ___ Blue Wave/QWK v2.20 --- Platinum Xpress/Win/Wildcat5! v3.0pr2 * Origin: FIDO QWK MAIL & MORE! WWW.DOCSPLACE.ORG (1:3603/140) +----------------------------------------------------------------------------+ From: Jonathan de Boyne Pollard 18-Oct-99 08:50:09 To: MIKE RUSKAI 21-Oct-99 06:19:18 Subj: DosDevIOCtl, cat8, f64 MR> The problem is that part of the parameters are the drive head and MR> cylinder. How do I figure out which head and cylinder I need to read MR> from? By using the BPB and other information obtainable through function 0x63. ¯ JdeBP ® --- FleetStreet 1.22 NR * Origin: JdeBP's point, using Squish (2:257/609.3) +----------------------------------------------------------------------------+ From: Jonathan de Boyne Pollard 18-Oct-99 08:56:09 To: MIKE RUSKAI 21-Oct-99 06:19:18 Subj: DosDevIOCtl() MR> The head/cylinder numbers are relative to the beginning of the MR> logical drive. Sort of. I *suspect*, from experience with the Graham Utilities DISKEDIT, that you'll find that your hypothesis does not work for multiple primary partitions (such as is the case if Boot Manager is installed at the start of the disc, for example). ¯ JdeBP ® --- FleetStreet 1.22 NR * Origin: JdeBP's point, using Squish (2:257/609.3) +----------------------------------------------------------------------------+ From: MIKE RUSKAI 21-Oct-99 11:25:00 To: JONATHAN DE BOYNE POLLARD 21-Oct-99 16:46:01 Subj: DosDevIOCtl() Some senseless babbling from Jonathan De Boyne Pollard to Mike Ruskai on 10-18-99 08:56 about DosDevIOCtl()... MR> The head/cylinder numbers are relative to the beginning of the MR> logical drive. Sort of. JDBP> I *suspect*, from experience with the Graham Utilities DISKEDIT, that JDBP> you'll find that your hypothesis does not work for multiple primary JDBP> partitions (such as is the case if Boot Manager is installed at the JDBP> start of the disc, for example). The category 8 functions are designed for logical disks, so outside of the given logical drive, it shouldn't matter what's going on. The handle used is from DosOpen(), and is not a physical drive handle. Nevertheless, I couldn't quite figure out why I wasn't getting the HPFS SuperBlock with some drives. I thought I nailed the problem by noting and using the hidden sectors value from the BIOS parameter block, but someone cured me of that pretty quickly. So, I put the drive into sector mode (using what Vitus posted), which makes things much simpler. After poking around, I've run into a strange situation, which you can read about in a post entitled "HPFS freespace bmp list". Mike Ruskai thannymeister@yahoo.com ... Cats are not pets; they own the house and let you live there. ___ Blue Wave/QWK v2.20 --- Platinum Xpress/Win/Wildcat5! v3.0pr2 * Origin: FIDO QWK MAIL & MORE! WWW.DOCSPLACE.ORG (1:3603/140) +----------------------------------------------------------------------------+ From: MIKE RUSKAI 21-Oct-99 11:29:00 To: ALL 21-Oct-99 16:46:01 Subj: HPFS freespace bmp list After poking around HPFS to determine the amount of space reserved by HPFS, compared to the size of the drive (the only part that varies by size is the directory band), I ran into something interesting. On a completely empty drive, the difference between the total drive size, and the free space (as reported by DosQueryFSInfo()) has a gap of 2MB not accounted for by HPFS structures. What I first did was make sure that the partition was indeed the size stated by DosQueryFSInfo(). I verified that by writing every sector of the drive to a file on another drive. What I did next was read all the freespace bitmaps (programmatically, of course), and add up the free sector count that way. The result was that there were 4096 free sectors not counted by whatever DosQueryFSInfo() does (via HPFS.IFS, no doubt). This number is the same on every drive I tested. What I'd like to do now is distribute the program that does this comparison, to get a wider range of data. Maybe HPFS386 doesn't have this problem, or a different version of HPFS, etc. The problem is that I'm not certain how to handle drives larger than 4GB. The freespace bitmap list is four sectors long, which allows for 512 data bands (about 4GB). Also in the HPFS SuperBlock is a pointer to a spare freespace bitmap list. What's not there is the length of this spare list. If it's only four sectors, like the primary list, then HPFS dies at 8GB, without another list. Unfortunately, I don't have any HPFS partitions larger than 4GB that I can poke around on. Does anyone know what the length of this secondary list is, or where to find the next list, if it's only four sectors (and so on)? Mike Ruskai thannymeister@yahoo.com ... Best way to dispose of the Borg: Give them Windows 3.1x ___ Blue Wave/QWK v2.20 --- Platinum Xpress/Win/Wildcat5! v3.0pr2 * Origin: FIDO QWK MAIL & MORE! WWW.DOCSPLACE.ORG (1:3603/140) +----------------------------------------------------------------------------+ From: Darin McBride 22-Oct-99 08:17:09 To: Mike Ruskai 22-Oct-99 23:30:00 Subj: HPFS freespace bmp list MR> What I'd like to do now is distribute the program that does this MR> comparison, to get a wider range of data. Maybe HPFS386 doesn't have this MR> problem, or a different version of HPFS, etc. MR> The problem is that I'm not certain how to handle drives larger than 4GB. MR> The freespace bitmap list is four sectors long, which allows for 512 data MR> bands (about 4GB). Also in the HPFS SuperBlock is a pointer to a spare MR> freespace bitmap list. What's not there is the length of this spare list. MR> If it's only four sectors, like the primary list, then HPFS dies at 8GB, MR> without another list. MR> Unfortunately, I don't have any HPFS partitions larger than 4GB that I can MR> poke around on. Send me the source (dmcbride@tower.to.org), and I'll send you back its output on my 7.99 GB HPFS drive. (8189MB) The reason I ask for source is so I can convince myself you're not going to damage my harddrive. ;-) Also, I assume you're using VAC 3.0 or gcc (EMX 0.9d) to compile it. MR> Does anyone know what the length of this secondary list is, or where to MR> find the next list, if it's only four sectors (and so on)? Unfortunately, my system isn't quite big enough to show a >8GB disk... :-) --- * Origin: Tanktalus' Tower BBS (1:250/102) +----------------------------------------------------------------------------+ From: Jonathan de Boyne Pollard 20-Oct-99 08:58:26 To: MIKE RUSKAI 22-Oct-99 23:30:00 Subj: Attn: HPFS gurus MR> Which is more likely, that in rare cases the above would not read LSN MR> 16 at all, or that in rare cases the SuperBlock doesn't reside at LSN MR> 16 at all? The former. As I said before, when one opens a volume for reading using category 0x08 DosDevIOCtl, logical sector 0 is in fact the start of the "drive" that contains the volume. This sector contains the MBR for that "drive". For primary partitions, this "drive" is the actual physical drive and the MBR is the primary MBR. The first primary partition usually starts on the next track boundary (because FDISK utilities try to align partitions on track boundaries). This was the cause of your previous problem. For secondary partitions, the "drive" is the "logical drive" (defined by a type 0x05/0x0F entry in the preceding MBR) containing the volume, and the MBR is the secondary MBR at the start of that "logical drive" that both defines any volumes within that "logical drive" and points to the next logical drive (and secondary MBR) in the partition table chain. By convention there is only one actual volume per "logical drive". Only two of the entries in the MBR at the start of the "logical drive" are used (one for the type 0x05/0x0F entry pointing to the next MBR). But there can be many volumes in the "drive" that encompasses the physical disc -- the one that starts with the primary MBR and that one sees when one attempts to access a volume that is a primary partition. Primary partitions apart from the first start further along within the "drive". In the case where the first primary partition is Boot Manager and the actual volume is the second primary partition, for example, the start of the area visible via category 0x08 will be the primary MBR and the whole of the Boot Manager partition is visible before the actual volume. (On my machine, this is in fact the case, and in the Graham Utilities' DISKEDIT to edit the boot sector of drive C:, logical block 0 of the volume, I have to skip 16065 logical sectors from the start of the "drive".) This is why on some machines you are seeing Boot Manager code. You are skipping one track to locate what you believe to be the start of the volume that you want, but this is taking you to the Boot Manager partition. Sector 16 within that partition thus contains Boot Manager code/data. For generic code that should work in all situations, therefore, what one has to do is to locate the actual volume within the "drive" by scanning the MBR at its start (logical sector 0 in the area accessible to you). One checks that the drive is partitionable and that the MBR contains a valid partition table, and if it is one scans the four partition table entries in the MBR for an entry with the correct type (i.e. skip Boot Manager, type 0x0A, and extended partition, type 0x05/0x0F, entries) and uses the sector offset field of that entry to locate the actual start of the volume. As you have found, however, asking the operating system for the BPB does this for you, since the operating system has itself already done all of this work when OS2DASD.DMD read the partition table during initialisation. If these mechanics still aren't clear, crank up DISKEDIT from the Graham Utilities, or use PARTLIST from the OS/2 Command Line Utilities version 2.0 (OS2CLU02.ZIP), and have a look at the raw structure of the partition "table". ¯ JdeBP ® --- FleetStreet 1.22 NR * Origin: JdeBP's point, using Squish (2:257/609.3) +----------------------------------------------------------------------------+ +============================================================================+