home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 15 Message / 15-Message.zip / oe991023.zip / Pr991022.txt < prev    next >
Text File  |  1999-10-23  |  21KB  |  511 lines
  1.  
  2.                   OS/2 Programming                 (Fidonet)
  3.  
  4.                  Saturday, 16-Oct-1999 to Friday, 22-Oct-1999
  5.  
  6. +----------------------------------------------------------------------------+
  7.  
  8. From: MIKE RUSKAI                                       17-Oct-99 12:19:00
  9.   To: ALL                                               17-Oct-99 19:31:19
  10. Subj: Attn: HPFS gurus
  11.  
  12. I've been collecting information on HPFS's system area lately, and to do
  13. that, I've been reading the HPFS SuperBlock using DosDevIOCtl().
  14.  
  15. Since I haven't seen information that says anything to the contrary, I've
  16. been assuming that the SuperBlock is on LSN 16 of a drive, period.
  17. However, I've had two people so far come up with odd results for their
  18. directory band size, and when I had them send me what's supposed to be
  19. their SuperBlock for the drive in question, it turns out to clearly not be.
  20. With one, I actually received 18 sectors of data (because I couldn't at
  21. first figure out how to read only one non-0 sector with DosDevIOCtl()).
  22. That one clearly contained Boot Manager code.  The other may have been the
  23. same, but I only received one sector worth.
  24.  
  25. Before I go further, here's the C code that's used to read the SuperBlock:
  26.  
  27. /* reading SuperBlock */
  28.  
  29.     ULONG bpParmLen, bpDataLen, sectorSize;
  30.     HFILE driveHandle; /* handle from DosOpen() */
  31.     char *sdata;
  32.     int i;
  33.     TRACKLAYOUT *tl;
  34.  
  35.     #define SECC 1 /* sector count to read */
  36.  
  37.     bpParmLen=sizeof(TRACKLAYOUT)+sizeof(ULONG)*SECC;
  38.     tl=(PTRACKLAYOUT)malloc(bpParmLen);
  39.  
  40.     bpDataLen=sectorSize*SECC;
  41.     sdata=(char*)malloc(bpDataLen);
  42.  
  43.     memset(sdata, 0, bpDataLen);
  44.  
  45.     tl->bCommand=0;
  46.     tl->usHead=1;
  47.     tl->usCylinder=0;
  48.     tl->usFirstSector=0;
  49.     tl->cSectors=SECC;
  50.  
  51.     /*
  52.         The loop allows reading more than one sector with a simple
  53.         change to the SECC definition.
  54.     */
  55.  
  56.  
  57.     for (i=0; i<SECC; i++)
  58.         {
  59.         tl->TrackTable[i].usSectorNumber=i+17;
  60.         tl->TrackTable[i].usSectorSize=sectorSize;
  61.         }
  62.  
  63.     rc=DosDevIOCtl(driveHandle, IOCTL_DISK, DSK_READTRACK, tl,
  64.                    bpParmLen, &bpParmLen, sdata, bpDataLen, &bpDataLen);
  65.  
  66. /* end */
  67.  
  68. The declarations are, of course, at the beginning of the entire source file
  69. (you can see it at http://home.att.net/~thanny/hpfssi.zip), and the only
  70. notable thing that's happened before the above is the retrieval of the
  71. drive's sector size, via a DosDevIOCtl() category 8, DSK_GETDEVICEPARMS
  72. call.
  73.  
  74. Which is more likely, that in rare cases the above would not read LSN 16 at
  75. all, or that in rare cases the SuperBlock doesn't reside at LSN 16 at all?
  76.  
  77. Naturally, I'm interested in solutions that address the problem in either
  78. case.
  79.  
  80. Mike Ruskai
  81. thannymeister@yahoo.com
  82.  
  83.  
  84. ... Had to give away the kids - The cat got allergic.
  85.  
  86. ___ Blue Wave/QWK v2.20
  87. --- Platinum Xpress/Win/Wildcat5! v3.0pr2
  88.  * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)
  89.  
  90. +----------------------------------------------------------------------------+
  91.  
  92. From: David Noon                                        15-Oct-99 18:39:00
  93.   To: David Van Hoose                                   17-Oct-99 22:38:02
  94. Subj: GetGetInfoBlocks
  95.  
  96. In a message dated 10-14-99, David Van Hoose said to All about
  97. "GetGetInfoBlocks"
  98.  
  99. Hi David,
  100.  
  101. DH>Does anyone here know if there is a Linux version
  102. DH>of DosGetInfoBlocks()?
  103.  
  104. I doubt it, as UNIX system calls are rather different from the OS/2 API.
  105. Besides, it would be off-topic. We don't discuss LINUX programming in this
  106. echo.
  107.  
  108. Regards
  109.  
  110. Dave
  111. <Team PL/I>
  112. ___
  113.  * MR/2 2.25 #353 * Caffeine is not a drug, it's a vitamin!
  114.  
  115. --- Maximus/2 3.01
  116.  * Origin: Air Applewood, OS/2 Gateway to Essex 44-1279-792300 (2:257/609)
  117.  
  118. +----------------------------------------------------------------------------+
  119.  
  120. From: MIKE RUSKAI                                       18-Oct-99 01:44:00
  121.   To: ALL                                               18-Oct-99 09:06:05
  122. Subj: DosDevIOCtl(), again
  123.  
  124. Well, I think I figured out what I was doing wrong the first time around,
  125. in not always getting the HPFS SuperBlock.
  126.  
  127. Rather than figuring out why there were 64 sectors of garbage before the
  128. boot sector on the drive, I kludged the code.  It worked on most drives,
  129. because most drives apparently have the same number of hidden sectors.
  130.  
  131. As it turns out, which at least some of you must know, there is a count of
  132. "hidden" sectors on a drive, retrievable via a category 8,
  133. DSK_GETDEVICEPARAMS call, in the BIOS parameter block data.
  134.  
  135. So, rather than incrementing the heads value (to increase the sector offset
  136. by the drive's sectors/track value), I just added the hidden sector count,
  137. and it worked fine.  More importantly, it should work on other drives.
  138.  
  139. Neat stuff.
  140.  
  141. Mike Ruskai
  142. thannymeister@yahoo.com
  143.  
  144.  
  145. ... "...we believe that OS/2 is the OS of the 90's" - Bill Gates, Comdex
  146.  
  147. ___ Blue Wave/QWK v2.20
  148. --- Platinum Xpress/Win/Wildcat5! v3.0pr2
  149.  * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)
  150.  
  151. +----------------------------------------------------------------------------+
  152.  
  153. From: Vitus Jensen                                      17-Oct-99 11:35:00
  154.   To: MIKE RUSKAI                                       18-Oct-99 15:30:18
  155. Subj: DosDevIOCtl, cat8, f64
  156.  
  157. Moin MIKE,
  158.  
  159. 14.10.99 19:29, MIKE RUSKAI wrote a message to ALL :
  160.  
  161.  MR> I'm collecting information on the size of the HPFS directory
  162.  MR> band, with respect to the size of the drive.  To do this, I read
  163.  MR> the Super Block by opening the drive as a file.
  164.  
  165.  MR> This fails, however, with drives over 2GB in size, since
  166.  MR> DosRead() and cousins can't handle files that size (except
  167.  MR> perhaps on Aurora - I had one person run it successfully on a
  168.  MR> 14GB drive, and am awaiting information on what he's running).
  169.  
  170.  MR> To get around this, I figure I need to make a call to
  171.  MR> DosDevIOCtl(),
  172.  MR> category 8 (IOCTL_DISK), function 0x64 (DSK_READTRACK).
  173. ...
  174.  
  175. No, you need the following IOCtl:
  176.  
  177. ========<start>=======================================
  178. DosRead/Write in direct-access mode will normally fail if the partition is
  179. greater than four gigabytes in size.  If you wish to write an HPFS editor or
  180. other tool, you will need to know the "secret password" that unlocks the big
  181. disks.  After you use DosOpen to get a handle to that volume, use FSCTL
  182. FSC_SECTORIO (0x9014) and in the parameter list, put a pointer to 0xDEADFACE.  
  183. Doing so will put the handle in "sector" mode.  All offsets and sizes will
  184. refer to sectors instead of bytes, allowing you to address 64Gb.   
  185. ========<end>=========================================
  186.  
  187. From "Undocumented Features of OS/2" (os2undoc.zip, 48K)
  188.  
  189. C-x C-s
  190.     Vitus
  191.  
  192. The Crazy Teaparty: X75 & V90S, 24h, 7d, 52w, +49-5136-893003
  193. --- Sqed/rexx 300:
  194.  * Origin: Just say NO! to Micro$oft Windows. (2:2474/424.1)
  195.  
  196. +----------------------------------------------------------------------------+
  197.  
  198. From: David Van Hoose                                   18-Oct-99 09:55:00
  199.   To: David Noon                                        18-Oct-99 16:08:14
  200. Subj: GetGetInfoBlocks
  201.  
  202. -> I doubt it, as UNIX system calls are rather different from the OS/2
  203. -> API. Besides, it would be off-topic. We don't discuss LINUX
  204. -> programming in this echo.
  205.  
  206. Okay.. I am just having a nasty problem with C compilers
  207. making some very nasty machine code, so I have been writing
  208. my apps in C and outputing assembly to fix up.
  209. When I do this, I cannot access the command line parameters.
  210.  
  211. -Dave
  212.  
  213. --- PCBoard (R) v15.4 (OS/2) 250 Beta
  214.  * Origin: Destiny BBS: 1-850-477-1262 (1:3612/333)
  215.  
  216. +----------------------------------------------------------------------------+
  217.  
  218. From: MIKE RUSKAI                                       19-Oct-99 07:34:00
  219.   To: VITUS JENSEN                                      20-Oct-99 00:12:22
  220. Subj: DosDevIOCtl, cat8, f64
  221.  
  222. Some senseless babbling from Vitus Jensen to Mike Ruskai
  223. on 10-17-99  11:35 about DosDevIOCtl, cat8, f64...
  224.  
  225.  VJ> Moin MIKE,
  226.  
  227.  VJ> 14.10.99 19:29, MIKE RUSKAI wrote a message to ALL :
  228.  
  229.  MR> I'm collecting information on the size of the HPFS directory
  230.  MR> band, with respect to the size of the drive.  To do this, I read
  231.  MR> the Super Block by opening the drive as a file.
  232.  
  233.  MR> This fails, however, with drives over 2GB in size, since
  234.  MR> DosRead() and cousins can't handle files that size (except
  235.  MR> perhaps on Aurora - I had one person run it successfully on a
  236.  MR> 14GB drive, and am awaiting information on what he's running).
  237.  
  238.  MR> To get around this, I figure I need to make a call to
  239.  MR> DosDevIOCtl(),
  240.  MR> category 8 (IOCTL_DISK), function 0x64 (DSK_READTRACK).
  241.  VJ> ...
  242.  
  243.  VJ> No, you need the following IOCtl:
  244.  
  245.  VJ> ========<start>=======================================
  246.  VJ> DosRead/Write in direct-access mode will normally fail if the
  247.  VJ> partition is greater than four gigabytes in size.  If you wish to write
  248.  VJ> an HPFS editor or other tool, you will need to know the "secret
  249.  VJ> password" that unlocks the big disks.  After you use DosOpen to get a
  250.  VJ> handle to that volume, use FSCTL FSC_SECTORIO (0x9014) and in the
  251.  VJ> parameter list, put a pointer to 0xDEADFACE.  Doing so will put the
  252.  VJ> handle in "sector" mode.  All offsets and sizes will refer to sectors
  253.  VJ> instead of bytes, allowing you to address 64Gb.   
  254.  VJ> ========<end>========================================= 
  255.  VJ> From "Undocumented Features of OS/2" (os2undoc.zip, 48K)
  256.  
  257. Interesting.  I've already figured it out using DosDevIOCtl(), though the
  258. above might prove useful in the future.
  259.  
  260. Is that to say that DosSetFilePtr() will also treat parameters as sector
  261. offsets?
  262.  
  263. Mike Ruskai
  264. thannymeister@yahoo.com
  265.  
  266.  
  267. ... Keep your OS/2 system healthy by practicing safe REXX.
  268.  
  269. ___ Blue Wave/QWK v2.20
  270. --- Platinum Xpress/Win/Wildcat5! v3.0pr2
  271.  * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)
  272.  
  273. +----------------------------------------------------------------------------+
  274.  
  275. From: Jonathan de Boyne Pollard                         18-Oct-99 08:50:09
  276.   To: MIKE RUSKAI                                       21-Oct-99 06:19:18
  277. Subj: DosDevIOCtl, cat8, f64
  278.  
  279.  MR> The problem is that part of the parameters are the drive head and
  280.  MR> cylinder. How do I figure out which head and cylinder I need to read
  281.  MR> from?  
  282.  
  283. By using the BPB and other information obtainable through function 0x63.
  284.  
  285.  » JdeBP «
  286.  
  287. --- FleetStreet 1.22 NR
  288.  * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
  289.  
  290. +----------------------------------------------------------------------------+
  291.  
  292. From: Jonathan de Boyne Pollard                         18-Oct-99 08:56:09
  293.   To: MIKE RUSKAI                                       21-Oct-99 06:19:18
  294. Subj: DosDevIOCtl()
  295.  
  296.  MR> The head/cylinder numbers are relative to the beginning of the 
  297.  MR> logical drive.  Sort of.  
  298.  
  299. I *suspect*, from experience with the Graham Utilities DISKEDIT, that you'll
  300. find that your hypothesis does not work for multiple primary partitions (such
  301. as is the case if Boot Manager is installed at the start of the disc, for
  302. example).
  303.  
  304.  » JdeBP «
  305.  
  306. --- FleetStreet 1.22 NR
  307.  * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
  308.  
  309. +----------------------------------------------------------------------------+
  310.  
  311. From: MIKE RUSKAI                                       21-Oct-99 11:25:00
  312.   To: JONATHAN DE BOYNE POLLARD                         21-Oct-99 16:46:01
  313. Subj: DosDevIOCtl()
  314.  
  315. Some senseless babbling from Jonathan De Boyne Pollard to Mike Ruskai
  316. on 10-18-99  08:56 about DosDevIOCtl()...
  317.  
  318.  MR> The head/cylinder numbers are relative to the beginning of the 
  319.  MR> logical drive.  Sort of.  
  320.  
  321.  JDBP> I *suspect*, from experience with the Graham Utilities DISKEDIT, that
  322.  JDBP> you'll find that your hypothesis does not work for multiple primary
  323.  JDBP> partitions (such as is the case if Boot Manager is installed at the
  324.  JDBP> start of the disc, for example).
  325.  
  326. The category 8 functions are designed for logical disks, so outside of the
  327. given logical drive, it shouldn't matter what's going on.  The handle used
  328. is from DosOpen(), and is not a physical drive handle.
  329.  
  330. Nevertheless, I couldn't quite figure out why I wasn't getting the HPFS
  331. SuperBlock with some drives.  I thought I nailed the problem by noting and
  332. using the hidden sectors value from the BIOS parameter block, but someone
  333. cured me of that pretty quickly.
  334.  
  335. So, I put the drive into sector mode (using what Vitus posted), which makes
  336. things much simpler.
  337.  
  338. After poking around, I've run into a strange situation, which you can read
  339. about in a post entitled "HPFS freespace bmp list".
  340.  
  341. Mike Ruskai
  342. thannymeister@yahoo.com
  343.  
  344.  
  345. ... Cats are not pets; they own the house and let you live there.
  346.  
  347. ___ Blue Wave/QWK v2.20
  348. --- Platinum Xpress/Win/Wildcat5! v3.0pr2
  349.  * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)
  350.  
  351. +----------------------------------------------------------------------------+
  352.  
  353. From: MIKE RUSKAI                                       21-Oct-99 11:29:00
  354.   To: ALL                                               21-Oct-99 16:46:01
  355. Subj: HPFS freespace bmp list
  356.  
  357. After poking around HPFS to determine the amount of space reserved by HPFS,
  358. compared to the size of the drive (the only part that varies by size is the
  359. directory band), I ran into something interesting.
  360.  
  361. On a completely empty drive, the difference between the total drive size,
  362. and the free space (as reported by DosQueryFSInfo()) has a gap of 2MB not
  363. accounted for by HPFS structures.  What I first did was make sure that the
  364. partition was indeed the size stated by DosQueryFSInfo().  I verified that
  365. by writing every sector of the drive to a file on another drive.
  366.  
  367. What I did next was read all the freespace bitmaps (programmatically, of
  368. course), and add up the free sector count that way.  The result was that
  369. there were 4096 free sectors not counted by whatever DosQueryFSInfo() does
  370. (via HPFS.IFS, no doubt).  This number is the same on every drive I tested.
  371.  
  372. What I'd like to do now is distribute the program that does this
  373. comparison, to get a wider range of data.  Maybe HPFS386 doesn't have this
  374. problem, or a different version of HPFS, etc.
  375.  
  376. The problem is that I'm not certain how to handle drives larger than 4GB.
  377. The freespace bitmap list is four sectors long, which allows for 512 data
  378. bands (about 4GB).  Also in the HPFS SuperBlock is a pointer to a spare
  379. freespace bitmap list.  What's not there is the length of this spare list.
  380. If it's only four sectors, like the primary list, then HPFS dies at 8GB,
  381. without another list.
  382.  
  383. Unfortunately, I don't have any HPFS partitions larger than 4GB that I can
  384. poke around on.
  385.  
  386. Does anyone know what the length of this secondary list is, or where to
  387. find the next list, if it's only four sectors (and so on)?
  388.  
  389. Mike Ruskai
  390. thannymeister@yahoo.com
  391.  
  392.  
  393. ... Best way to dispose of the Borg: Give them Windows 3.1x
  394.  
  395. ___ Blue Wave/QWK v2.20
  396. --- Platinum Xpress/Win/Wildcat5! v3.0pr2
  397.  * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)
  398.  
  399. +----------------------------------------------------------------------------+
  400.  
  401. From: Darin McBride                                     22-Oct-99 08:17:09
  402.   To: Mike Ruskai                                       22-Oct-99 23:30:00
  403. Subj: HPFS freespace bmp list
  404.  
  405.  MR> What I'd like to do now is distribute the program that does this
  406.  MR> comparison, to get a wider range of data.  Maybe HPFS386 doesn't have
  407. this
  408.  MR> problem, or a different version of HPFS, etc.
  409.  
  410.  MR> The problem is that I'm not certain how to handle drives larger than 4GB.
  411.  MR> The freespace bitmap list is four sectors long, which allows for 512 data
  412.  MR> bands (about 4GB).  Also in the HPFS SuperBlock is a pointer to a spare
  413.  MR> freespace bitmap list.  What's not there is the length of this spare
  414. list.
  415.  MR> If it's only four sectors, like the primary list, then HPFS dies at 8GB,
  416.  MR> without another list.
  417.  
  418.  MR> Unfortunately, I don't have any HPFS partitions larger than 4GB that I
  419. can
  420.  MR> poke around on.
  421.  
  422. Send me the source (dmcbride@tower.to.org), and I'll send you back its output
  423. on my 7.99 GB HPFS drive. (8189MB)
  424.  
  425. The reason I ask for source is so I can convince myself you're not going to
  426. damage my harddrive.  ;-)  Also, I assume you're using VAC 3.0 or gcc (EMX
  427. 0.9d) to compile it.
  428.  
  429.  MR> Does anyone know what the length of this secondary list is, or where to
  430.  MR> find the next list, if it's only four sectors (and so on)?
  431.  
  432. Unfortunately, my system isn't quite big enough to show a >8GB disk... :-)
  433.  
  434.  
  435. ---
  436.  * Origin: Tanktalus' Tower BBS (1:250/102)
  437.  
  438. +----------------------------------------------------------------------------+
  439.  
  440. From: Jonathan de Boyne Pollard                         20-Oct-99 08:58:26
  441.   To: MIKE RUSKAI                                       22-Oct-99 23:30:00
  442. Subj: Attn: HPFS gurus
  443.  
  444.  MR> Which is more likely, that in rare cases the above would not read LSN
  445.  MR> 16 at all, or that in rare cases the SuperBlock doesn't reside at LSN
  446.  MR> 16 at all?
  447.  
  448. The former.
  449.  
  450. As I said before, when one opens a volume for reading using category 0x08
  451. DosDevIOCtl, logical sector 0 is in fact the start of the "drive" that
  452. contains the volume.  This sector contains the MBR for that "drive".  
  453.  
  454. For primary partitions, this "drive" is the actual physical drive and the MBR
  455. is the primary MBR.  The first primary partition usually starts on the next
  456. track boundary (because FDISK utilities try to align partitions on track
  457. boundaries).  This was the cause of your previous problem.
  458.  
  459. For secondary partitions, the "drive" is the "logical drive" (defined by a
  460. type 0x05/0x0F entry in the preceding MBR) containing the volume, and the MBR
  461. is the secondary MBR at the start of that "logical drive" that both defines
  462. any volumes within that "logical drive" and points to the next logical drive
  463. (and secondary MBR) in the partition table chain.
  464.  
  465. By convention there is only one actual volume per "logical drive".  Only two
  466. of the entries in the MBR at the start of the "logical drive" are used (one
  467. for the type 0x05/0x0F entry pointing to the next MBR).  But there can be many 
  468. volumes in the "drive" that encompasses the physical disc -- the one that
  469. starts with the primary MBR and that one sees when one attempts to access a
  470. volume that is a primary partition.
  471.  
  472. Primary partitions apart from the first start further along within the
  473. "drive".  In the case where the first primary partition is Boot Manager and
  474. the actual volume is the second primary partition, for example, the start of
  475. the area visible via category 0x08 will be the primary MBR and the whole of
  476. the Boot Manager partition is visible before the actual volume.  (On my
  477. machine, this is in fact the case, and in the Graham Utilities' DISKEDIT to
  478. edit the boot sector of drive C:, logical block 0 of the volume, I have to
  479. skip 16065 logical sectors from the start of the "drive".)
  480.  
  481. This is why on some machines you are seeing Boot Manager code.  You are
  482. skipping one track to locate what you believe to be the start of the volume
  483. that you want, but this is taking you to the Boot Manager partition.  Sector
  484. 16 within that partition thus contains Boot Manager code/data.
  485.  
  486. For generic code that should work in all situations, therefore, what one has
  487. to do is to locate the actual volume within the "drive" by scanning the MBR at 
  488. its start (logical sector 0 in the area accessible to you).   One checks that
  489. the drive is partitionable and that the MBR contains a valid partition table,
  490. and if it is one scans the four partition table entries in the MBR for an
  491. entry with the correct type (i.e. skip Boot Manager, type 0x0A, and extended
  492. partition, type 0x05/0x0F, entries) and uses the sector offset field of that
  493. entry to locate the actual start of the volume.
  494.  
  495. As you have found, however, asking the operating system for the BPB does this
  496. for you, since the operating system has itself already done all of this work
  497. when OS2DASD.DMD read the partition table during initialisation.
  498.  
  499. If these mechanics still aren't clear, crank up DISKEDIT from the Graham
  500. Utilities, or use PARTLIST from the OS/2 Command Line Utilities version 2.0
  501. (OS2CLU02.ZIP), and have a look at the raw structure of the partition "table".
  502.  
  503.  » JdeBP «
  504.  
  505. --- FleetStreet 1.22 NR
  506.  * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)
  507.  
  508. +----------------------------------------------------------------------------+
  509.  
  510. +============================================================================+
  511.