DOS ain't dead

I recently tried FreeDOS's fdisk utility on a real machine and, to say it carefully, IMO this tool needs to be improved.

There are currently 2 binaries delivered in the fdisk package:

- FDISK.EXE, version 1.2.1, dated 4/2003
- FDISK131.EXE, version 1.3.1, dated 11/2008

On the machine was installed a "normal" WD SATA 1TB HD.

Launching FDISK131, it just emits:
"Error reading Hard DIsk! Addressed sector not found"
and exits.

FDISK.EXE starts without error and allows to create a new (primary) partition ( I tried size 8192 MB), but it's unable to correctly calculate the starting sector, resulting in overlapping partitions:

BI  Type                     Sector    Size         MB abs. Start-End
-----------------------------------------------------------------------
80  83 Linux ext2fs                  2048 390701056 190772 2048-390703103
00  0c Prim. DOS (FAT32,LBA)    390703104  16777216   8192 390703104-407480319
00  0c Prim. DOS (FAT32,LBA)    407472660  16787925   8197 407472660-424260584

As it can be seen, partition 2 and 3 do overlapp, sectors 407,472,660-407,480,319 are part of both partitions.

A nasty bug: if "too much" data is written to partition 2, partition3's boot sector/FAT will be overwritten, causing the corresponding drive to "disappear".

Are there any newer versions or does FD v1.3 indeed supply such buggy versions of an elementary tool like FDISK? Hard to believe...

---
MS-DOS forever!

I also have Fdisk 1.3.1 as last version. I have 1TB HDD and don't see any errors on startup and it seems my partitions are displayed OK but didn't checked in detail. Couldn't be some problem in INT13h services of your BIOS?

How did you created other partitions and how does it look under another disk tool? I assume they are not really overlaping that's only FFdisk bad interpretation. I rather used PQmagic or similar tool so don't use this FFdisk much...

Update - how FFdisk sees my 1TB disk:

Current fixed disk drive: 2                  (TC: -9471 TH: 254 TS:  63)

Partition   Status   Mbytes   Description     Usage  Start Cyl  End Cyl
 D: 1   6      A       494   FAT16               0%       0        62
    2   5             7538   Extended            1%      63      1023
 M: 3  12           477126   FAT32     (LBA)    50%    1024      -3688
 N: 4  12           468709   FAT32     (LBA)    49%    -3687      -9472

---
DOS gives me freedom to unlimited HW access.

> checked in detail. Couldn't be some problem in INT13h services of your
> BIOS?

No. My hdedit and other hd tool run fine.

> How did you created other partitions and how does it look under another
> disk tool?

I created the first partition with linux fdisk.

> I assume they are not really overlaping that's only FFdisk bad
> interpretation.

No, this error is real. I created 2 partitions on an 64 GB USB stick, the first a FAT16 with 2 GB, the second a FAT32 with 62 GB, and, after having written almost 2 GB to FAT16, the second drive showed garbage ( and "disappeared" after reboot ).

Also, Linux fdisk does detect those overlapping partitions and warns.

---
MS-DOS forever!

> No, this error is real. I created 2 partitions on an 64 GB USB stick, the
> first a FAT16 with 2 GB, the second a FAT32 with 62 GB, and, after having
> written almost 2 GB to FAT16, the second drive showed garbage ( and
> "disappeared" after reboot ).
>
> Also, Linux fdisk does detect those overlapping partitions and warns.

Ouuu, that's bad, other FD users should be warned! How did look CHS values? but it shouldn't matter as it's beyond 8GB and FFdisk probably use LBA by default (instead of MSDOS 6.x Fdisk). I wonder why just 407 sectors, weird number...
Can you reproduce it on a sata/ide HDD or with i a bit different partition sizes? FreeDOS kernel displays some partition info at boot maybe it also perform overlaping check?

---
DOS gives me freedom to unlimited HW access.

> I wonder why just 407 sectors, weird number...

That's a missunderstanding. I wrote:

sectors 407,472,660-407,480,319 are part of both partitions.

this is English large number notation, it should be read like this:

abs. sector numbers 407472660 up to 407480319 are part of both partitions.

Btw, does this forum software have no possibility to somehow select a fixed font?

---
MS-DOS forever!

> Btw, does this forum software have no possibility to somehow select a fixed
> font?

You can (ab)use the code tag for that.

---
Forum admin

> Are there any newer versions or does FD v1.3 indeed supply such buggy

I'm not aware of any.

> versions of an elementary tool like FDISK? Hard to believe...

Doesn't matter, what I believe on FDISK, because I don't use it very often. But I guess, there are many other bugs in FreeDOS. Reporting issues and fixing these happens very "asynchronously", to say nice, which disattracts many people.

---
Forum admin

> Launching FDISK131, it just emits:
> "Error reading Hard DIsk! Addressed sector not found"
> and exits.

Here's good news: this error can be cured. It happens if FDISK131 doesn't find its FDISK.INI file (strangely, it's claimed that this file is "optional").

The bad news is: The error concerning partition overlap has NOT been fixed in v1.3.1.

---
MS-DOS forever!

> You can (ab)use the code tag for that.

I did, but it's not really a monospaced font, it's just a bit "fixer" .

---
MS-DOS forever!

> Doesn't matter, what I believe on FDISK, because I don't use it very often.
> But I guess, there are many other bugs in FreeDOS. Reporting issues and
> fixing these happens very "asynchronously", to say nice, which disattracts
> many people.

Instead of spitting bitterness at FreeDOS (happy new year to you, too?) you could at least tell which of the reported but unfixed bugs annoy you most and where to find the bug report lists.

There are 229 bugs listed here:

https://sourceforge.net/p/freedos/bugs/?limit=250

Unfortunately, they are not grouped into affected
applications / distros / maintainers / anything??

While most sources mirrored at

https://github.com/fdos

claim to have zero issues. Exceptions:

https://github.com/FDOS/kernel/issues

* ecm wants a ZIP of the releases
* yuppox says "wmake?"
* petr-akhlamov has a problem with russian codepage

https://github.com/FDOS/freecom/issues

* Russian translations have spelling errors
* line-wrapping when using up-arrow history
* internal commands do not set errorlevel (should they?)
* French translations have room for improvement
* Same for Turkish translation
* FreeCOM fails to use int 21.6505 file name terminators (RxDOS compat)
* Improvements in a fork, see below
* Fritz Mueller wants COPY to mention target paths, not just drives (and some other issues)

The improvements by Piotr Durlej - it also lists all other
GIT based changes for the last centuries, but there was a
period of only 3 changes between 2011-07-29 and 2018-01-07:

https://github.com/p-durlej/freedos-freecom/commits/master

* the thing Fritz wanted for COPY
* a similar change for DEL
* TYPE tuning
* DIR support for 40 column mode
* improved English texts
* GCC compile support and other compile tricks
* CLS versus ctrl-L

Before that, there are 2019-12-29 changes by Bart Oldeman
and other older changes which hopefully are already used
more widely (0.84pre7) by the general FreeDOS audience?

---
FreeDOS / DOSEMU2 / ...

> On the machine was installed a "normal" WD SATA 1TB HD.

What is "normal" ? Non advanced format?

https://en.wikipedia.org/wiki/Advanced_Format

>
> https://github.com/FDOS/freecom/issues
>
> * FreeCOM fails to use int 21.6505 file name terminators (RxDOS compat)

The title of https://github.com/FDOS/freecom/issues/20 is "FreeCOM fails to match any commands in RxDOS 7.24 due to unsupported Int21.6505". Your reading does not match the contents however. FreeCOM *does* use that service. It depends on that service being implemented to work properly. The "unsupported" bit here is that current RxDOS does not yet provide this service, causing FreeCOM to fail.

---
l

> >
> > https://github.com/FDOS/freecom/issues
> >
> > * FreeCOM fails to use int 21.6505 file name terminators (RxDOS compat)
>
> The title of https://github.com/FDOS/freecom/issues/20 is "FreeCOM fails to
> match any commands in RxDOS 7.24 due to unsupported Int21.6505". Your
> reading does not match the contents however. FreeCOM *does* use that
> service. It depends on that service being implemented to work properly. The
> "unsupported" bit here is that current RxDOS does not yet provide this
> service, causing FreeCOM to fail.

In that case, RxDOS is not MS DOS 3.3 compatible, which
is not a bug in FreeCOM - it does not intend to work
with even older MS DOS versions, as far as I remember?

FreeCOM should probably specify system requirements, though.

---
FreeDOS / DOSEMU2 / ...

I again played a bit with FD fdisk. Here's again the 2 overlapping partitions:


  type          start sec  size            abs. sectors   
> FAT32,LBA     390703104  16777216   8192 390703104-407480319
> FAT32,LBA     407472660  16787925   8197 407472660-424260584


Now, one missing information is the geometry returned by Int 0x13, ah=0x48:

Cyl/Head/Sec=121601/255/63

This gives a good hint where the problem is:

1. Multiplying "heads" and "sectors": 255x63=16065
2. Dividing the 2. start sector thru this value: 407472660/16065=25364

The division has no remainder. And so I conclude: FD fdisk tries to align the partition's start sector (and size) to a "cylinder" boundary, either rounding or skipping remainders. This indeed works - as long as FD fdisk handles the MBR exclusively. Linux fdisk, however, doesn't seem to care about cylinder boundaries, at least not if the partition type is FAT32-LBA.

Another - minor - problem with FD fdisk's approach is that the cyl/head/sec geometry returned by Int 0x13, ah=0x48 may be invalid. There's a flag returned, indicating whether the information is valid, but FD fdisk ignores it

Here's the relevant fdisk source, file PDISKIO.C:


    asm {
      mov ah,0x48
      mov dl,BYTE PTR physical_drive
      mov ds,result_buffer_segment
      mov si,result_buffer_offset
      int 0x13

      mov BYTE PTR error_code,ah
      }

//    if(error_code>0) return(error_code);
    if(error_code > 0) Error_Handler(error_code);

    /* Compute the total number of logical cylinders based upon the number */
    /* of physical sectors returned from service 0x48.                     */

    number_of_physical_sectors = *(_u32*)(result_buffer+16);

    total_cylinders=((number_of_physical_sectors/total_sectors)/(total_heads+1));



---
MS-DOS forever!

> I again played a bit with FD fdisk. Here's again the 2 overlapping
> partitions:
>
>
> type          start sec  size            abs. sectors   
> > FAT32,LBA     390703104  16777216   8192 390703104-407480319
> > FAT32,LBA     407472660  16787925   8197 407472660-424260584
>

is it correct that the 1st partition was created by linux, the 2nd by FDISK?

>
> Now, one missing information is the geometry returned by Int 0x13,
> ah=0x48:
>
> Cyl/Head/Sec=121601/255/63
>
> This gives a good hint where the problem is:
>
> 1. Multiplying "heads" and "sectors": 255x63=16065
> 2. Dividing the 2. start sector thru this value: 407472660/16065=25364
>
> The division has no remainder. And so I conclude: FD fdisk tries to align
> the partition's start sector (and size) to a "cylinder" boundary, either
> rounding or skipping remainders. This indeed works - as long as FD fdisk
> handles the MBR exclusively. Linux fdisk, however, doesn't seem to care
> about cylinder boundaries, at least not if the partition type is
> FAT32-LBA.

most likely correct; DOS for historical reasons aligns partitions on track boundaries, linux and newer windows on 4K or 1M boundaries.

of course this is a FDISK bug; it should round up the 1st partition and not down.

> is it correct that the 1st partition was created by linux, the 2nd by
> FDISK?

it's actually the 2nd and 3rd partition, the first is an ext4. Partition 1 & 2 were created by linux, the 3rd by FD fdisk.

---
MS-DOS forever!

> > You can (ab)use the code tag for that.
>
> I did, but it's not really a monospaced font, it's just a bit "fixer" .

What are your requirements exactly?

---
Forum admin

> What are your requirements exactly?

That tables look like tables


80  83 Linux ext2fs                  2048 390701056 190772
00  0c Prim. DOS (FAT32,LBA)    390703104  16777216   8192
00  0c Prim. DOS (FAT32,LBA)    407472660  16787925   8197


I don't know how it looks in your browser, but in mine the columns are not
properly aligned (i.e. the column with items "2048", "390703104" and "407472660" should be right aligned).

---
MS-DOS forever!

> > What are your requirements exactly?
>
> That tables look like tables
>
>
> 80  83 Linux ext2fs                  2048 390701056 190772
> 00  0c Prim. DOS (FAT32,LBA)    390703104  16777216   8192
> 00  0c Prim. DOS (FAT32,LBA)    407472660  16787925   8197
>
>
> I don't know how it looks in your browser, but in mine the columns are not
> properly aligned (i.e. the column with items "2048", "390703104" and
> "407472660" should be right aligned).

at least in Windows Firefox it is proper aligned

which browser are you using?

> > > What are your requirements exactly?
> >
> > That tables look like tables
> >
> >
> > 80  83 Linux ext2fs                  2048 390701056 190772
> > 00  0c Prim. DOS (FAT32,LBA)    390703104  16777216   8192
> > 00  0c Prim. DOS (FAT32,LBA)    407472660  16787925   8197
> >
> >
> > I don't know how it looks in your browser, but in mine the columns are
> not
> > properly aligned (i.e. the column with items "2048", "390703104" and
> > "407472660" should be right aligned).
>
> at least in Windows Firefox it is proper aligned
>
> which browser are you using?

Relevant: Forum bug: code block has non-monospaced font in mobile Firefox

---
l

> which browser are you using?

It's FF, 78.6.0esr (64-bit), delivered with Debian 10.

I'm able to see tables correctly aligned if I go to preferences, find "Fonts and Colors", and then, clicking "Advanced...", select a monospaced font as proportional font.

I thought this sub-optimal, but just found out now, that, as long as I enable "allow pages to select their own fonts...", it works well enough.

---
MS-DOS forever!

> The division has no remainder. And so I conclude: FD fdisk tries to align
> the partition's start sector (and size) to a "cylinder" boundary, either
> rounding or skipping remainders. This indeed works - as long as FD fdisk
> handles the MBR exclusively. Linux fdisk, however, doesn't seem to care
> about cylinder boundaries, at least not if the partition type is
> FAT32-LBA.

after taking a look into FDISKs code (PCOMPUTE.C, create_primary_partition() and Determine_Free_Space() )

a) it's really ugly code
b) it looks ok in this respect;
at least it tries to start the next partition at the
end cylinder of the previous partition + 1.
this should automatically round up.
at least that's what I see.
c) all calculations are done with cylinders, with sector=1, head=0.
c) this is a candidate for obfuscated C code contest.


could you post a dump of the partition table or verify yourself if the
ending cylinder of the 2'nd partition corresponds to the LBA value.

> could you post a dump of the partition table

I'll dump the partition table of a 64GB USB memory stick, because the math is easier. The stick's first partition is a FAT16, created with linux fdisk. The second (primary,FAT32) partition was created with FD fdisk 1.2.1, using the remaining space.

Here's the MBR dump:

Drive 2: EDD-Version=30 API-Bitmap=5
ExInt13: Flags=0006 Sectors=124825600 (60950 MB) SecSize=512 [CHS=60950/64/32]
EDD3: bus=PCI interface=USB bus/dev/func=1/0/0

BI Type                    Start-C/H/S   End-C/H/S     Sector     Size      MB  abs. Start/End
-----------------------------------------------------------------------------------------------
80 0e Prim. DOS,FAT16,LBA     0/  1/ 1  975/ 63/32         32    4096000   2000 32-4096031
00 0c Prim. DOS,FAT32,LBA   976/  0/ 1  534/ 63/32    4096000  120731648  58951
00 00 Free Entry              0/  0/ 0    0/  0/ 0          0          0      0
00 00 Free Entry              0/  0/ 0    0/  0/ 0          0          0      0

one "cylinder" is 2048 sectors or 1 MB.
The overlapping part in this case is 32 sectors only, start sector of second partition should be 4096032.
Interestingly, size of the second partition is 120631648 (58951 cylinder), and that exceeds the stick's capacity by one cylinder!

> if the ending cylinder of the 2'nd partition corresponds to the LBA value.

But the ending cylinder is limited to 1023 and so cannot correspond to the LBA value.

---
MS-DOS forever!

> > What are your requirements exactly?
>
> That tables look like tables
>
>
> 80  83 Linux ext2fs                  2048 390701056 190772
> 00  0c Prim. DOS (FAT32,LBA)    390703104  16777216   8192
> 00  0c Prim. DOS (FAT32,LBA)    407472660  16787925   8197
>
>
> I don't know how it looks in your browser, but in mine the columns are not
> properly aligned (i.e. the column with items "2048", "390703104" and
> "407472660" should be right aligned).

Here now with Linux FireFox v68.12.0esr
the columns are correctly aligned.

BRB with DOS Arachne v1.97

---
--
http://glennmcc.org/

> > > What are your requirements exactly?
> >
> > That tables look like tables
> >
> >
> > 80 83 Linux ext2fs 2048 390701056 190772
> > 00 0c Prim. DOS (FAT32,LBA) 390703104 16777216 8192
> > 00 0c Prim. DOS (FAT32,LBA) 407472660 16787925 8197
> >
> >
> > I don't know how it looks in your browser, but in mine the columns are
> not
> > properly aligned (i.e. the column with items "2048", "390703104" and
> > "407472660" should be right aligned).
>
> Here now with Linux FireFox v68.12.0esr
> the columns are correctly aligned.
>
> BRB with DOS Arachne v1.97


Also no problem....

http://glennmcc.org/images/correctly_aligned.jpg

---
--
http://glennmcc.org/

> c) all calculations are done with cylinders, with sector=1, head=0.
> c) this is a candidate for obfuscated C code contest.

Is two times "c)" for obfuscation?

---
Forum admin

> > which browser are you using?
>
> It's FF, 78.6.0esr (64-bit), delivered with Debian 10.
>
> I'm able to see tables correctly aligned if I go to preferences, find
> "Fonts and Colors", and then, clicking "Advanced...", select a monospaced
> font as proportional font.
>
> I thought this sub-optimal, but just found out now, that, as long as I
> enable "allow pages to select their own fonts...", it works well enough.

Why did you disable this before?
Can this bug be "closed" now?

---
Forum admin

> > > which browser are you using?
> >
> > It's FF, 78.6.0esr (64-bit), delivered with Debian 10.
> >
> > I'm able to see tables correctly aligned if I go to preferences, find
> > "Fonts and Colors", and then, clicking "Advanced...", select a
> monospaced
> > font as proportional font.
> >
> > I thought this sub-optimal, but just found out now, that, as long as I
> > enable "allow pages to select their own fonts...", it works well enough.
>
> Why did you disable this before?
> Can this bug be "closed" now?

No such setting on mobile Firefox.

---
l

> > > which browser are you using?
> >
> > It's FF, 78.6.0esr (64-bit), delivered with Debian 10.
> >
> > I'm able to see tables correctly aligned if I go to preferences, find
> > "Fonts and Colors", and then, clicking "Advanced...", select a
> monospaced
> > font as proportional font.
> >
> > I thought this sub-optimal, but just found out now, that, as long as I
> > enable "allow pages to select their own fonts...", it works well enough.
>
> Why did you disable this before?
> Can this bug be "closed" now?

That seems to be a misunderstanding. Japheth was forced to either tell his browser to use a typewriter (monospaced) font even for things which would otherwise be using a normal, proportional font. Or he has to allow websites to use fully custom fonts, as far as I understand his comment.

That is not the best solution to the problem. Just a tedious workaround. The forum should work in a way which only tells the browser to use a monospace font. Without the requirement to let the website (BTTR) select which font exactly to use. I hope the website at least does not tell the browser to download fonts somewhere? That would be the most annoying solution, but some websites do this for "perfect" styling :-p

Still, I can say that table alignment on BTTR is okay with newer Firefox versions, so the bug seems to be specific to the version used by Japheth.

PS: I wonder why FDISK tries to win obfuscation contests.

---
FreeDOS / DOSEMU2 / ...

> Why did you disable this before?

I did not "disable" anything. All I changed is to select a monospaced font as "proportional" font. I first thought that this may make look all websites terrible, but actually it's hardly noticeable.

> Can this bug be "closed" now?

Yes. If the bug is indeed restricted to the ff version that debian 10 provides it will become obsolete as soon as debian 11 becomes "stable".

---
MS-DOS forever!

> Yes. If the bug is indeed restricted to the ff version that debian 10
> provides it will become obsolete as soon as debian 11 becomes "stable".

the table is surrounded by
<code>
table
</code>

according to 15 seconds of internet research,

"The <code> tag is used to define a piece of computer code. The content inside is displayed in the browser's default monospace font."

and that is what you wanted.

how your browser interprets this is beyond the forums possibility to influence

> > Why did you disable this before?
>
> I did not "disable" anything. All I changed is to select a monospaced font
> as "proportional" font. I first thought that this may make look all
> websites terrible, but actually it's hardly noticeable.

Your sentence I thought this sub-optimal, but just found out now, that, as long as I enable "allow pages to select their own fonts...", it works well enough. made me think, that you re-enabled the "Allow pages to choose their own fonts" option now and all looks fine.

> > Can this bug be "closed" now?
>
> Yes. If the bug is indeed restricted to the ff version that debian 10
> provides it will become obsolete as soon as debian 11 becomes "stable".

Okay. Then let's wait for Debian 11.

---
Forum admin

> > > I'm able to see tables correctly aligned if I go to preferences, find
> > > "Fonts and Colors", and then, clicking "Advanced...", select a
> > monospaced
> > > font as proportional font.
> > >
> > > I thought this sub-optimal, but just found out now, that, as long as I
> > > enable "allow pages to select their own fonts...", it works well
> enough.
> >
> > Why did you disable this before?
> > Can this bug be "closed" now?
>
> That seems to be a misunderstanding. Japheth was forced to either tell his
> browser to use a typewriter (monospaced) font even for things which would
> otherwise be using a normal, proportional font. Or he has to allow websites
> to use fully custom fonts, as far as I understand his comment.

The latter is the default setting in Firefox and other standard browsers. That's why I asked, why he disabled this setting in the past.

> That is not the best solution to the problem. Just a tedious workaround.
> The forum should work in a way which only tells the browser to use a
> monospace font.

This is what it does with the <code> tag, as tom already pointed out.

> Without the requirement to let the website (BTTR) select which font
> exactly to use.

But that's how the WWW worked for decades. The forum uses "font-family: courier-new, courier;" for <code>. Both fonts are widely used. If these fonts are not available on the user's computer, then the user's browser has a fallback mechanism to use a similar font instead.

> I hope the website at least does not tell the browser to download fonts
> somewhere?

It does not. See https://www.bttr-software.de/forum/style.css for the fonts used.

> That would be the most annoying solution, but some websites do this for
> "perfect" styling :-p

I know. And these downloads are sometimes larger than what fits on a 3.5" floppy.

---
Forum admin

> how your browser interprets this is beyond the forums possibility to
> influence

May be. But my guess is that putting the <code> tags inside a <pre> block would make the issues with "non breaking spaces" disappear.

---
MS-DOS forever!

> > how your browser interprets this is beyond the forums possibility to
> > influence
>
> May be. But my guess is that putting the <code> tags inside a <pre> block
> would make the issues with "non breaking spaces" disappear.

At first, let's try something else: I changed the CSS a little. Please tell me your results. (Make sure to clear your browser's cache first.)

---
Forum admin

> Update - how FFdisk sees my 1TB disk:
>
> Current fixed disk drive: 2                  (TC: -9471 TH: 254 TS:
> 63)
>
> Partition   Status   Mbytes   Description     Usage  Start Cyl  End Cyl
> D: 1   6      A       494   FAT16               0%       0        62
> 2   5             7538   Extended            1%      63      1023
> M: 3  12           477126   FAT32     (LBA)    50%    1024      -3688
> N: 4  12           468709   FAT32     (LBA)    49%    -3687     
> -9472

Negative values for Start/End Cyl?

---
Forum admin

> But that's how the WWW worked for decades. The forum uses "font-family:
> courier-new, courier;" for <code>.
>
> It does not. See https://www.bttr-software.de/forum/style.css for the fonts
> used.

That could be the problem: You ONLY mention explicit, non-generic names for code, while for the normal text, you also mention the generic "sans-serif" after "arial or verdana".

https://www.w3schools.com/cssref/css_websafe_fonts.asp (where you can also see what it looks like) recommends:

Arial, Verdana, Helvetica, Tahoma or Trebuchet MS for sans-serif
Times New Roman, Georgia or Garamond for serif
Courier New for monospace and
Brush Script MT for cursive.

So I suggest to use "font-family: courier-new, courier, monospace;" for <code>.

Edit: Looks like that is what you have done when you said "you have changed the CSS a little". So we agree and have to wait for Japheth to check whether it helped.

PS: You say FDISK overflows for disks above 1 TB (above 2^31 sectors)? Not good at all!

---
FreeDOS / DOSEMU2 / ...

> At first, let's try something else: I changed the CSS a little. Please tell
> me your results. (Make sure to clear your browser's cache first.)

if this:


+---------+---------+---------+---------+---------+---------+---------+---------+
|         |         |         |         |         |         |         |         |         
+---------+---------+---------+---------+---------+---------+---------+---------+
|         |         |         |         |         |         |         |         |         
+---------+---------+---------+---------+---------+---------+---------+---------+


looks like 2 lines of 8 rectangles then it's mostly ok (mostly, because I'm limited to 8 rectangles, if I enter more, it rejects them [ error: the word ... in the text field is too long ].

Here's once more the table displayed by the mbr tool:

BI Type                    Start-C/H/S   End-C/H/S     Sector     Size      MB
-------------------------------------------------------------------------------
80 0c Prim. DOS,FAT32,LBA     0/  1/ 1  521/254/63         63    8385867   4094
00 07 HPFS,NTFS,exFAT       522/  0/ 1  542/254/63    8385930  115491285  56392
00 07 HPFS,NTFS,exFAT       543/  0/ 1 1002/254/63  123877215  204796620  99998
00 05 Extended DOS         1003/  0/ 1    0/254/63  328675326  921588402 449994


---
MS-DOS forever!

> FreeCOM should probably specify system requirements, though.

yes of course. FreeCOM requires a DOS-compatible operating system.

Now I can test, how it looks in my browser, but I'm interested in how it looks in your Debian's FireFox.

---
Forum admin

> > FreeCOM should probably specify system requirements, though.
>
> yes of course. FreeCOM requires a DOS-compatible operating system.

Of course I mean "FreeCOM docs should tell you which DOS version
you have to have at minimum". I remember that it can gracefully
adapt to whether or not you have FAT32 support or LFN, but I do
not know whether it is supposed to work smoothly on DOS versions
which are not at least MS DOS 3.3/newer compatible, for example.

---
FreeDOS / DOSEMU2 / ...

> ... but I'm interested in how it looks in your Debian's FireFox.

Oh, I forgot to mention: with debian 10 FF ( and the font setting restored to the default ), I can see both the nice 16 rectangles and the properly aligned MBR table header.

Fantastic work, admin - I love you!

---
MS-DOS forever!

> > ... but I'm interested in how it looks in your Debian's FireFox.
>
> Oh, I forgot to mention: with debian 10 FF ( and the font setting restored
> to the default ), I can see both the nice 16 rectangles and the properly
> aligned MBR table header.

Nice.

> Fantastic work, admin - I love you!

Love you too.

---
Forum admin

> I recently tried FreeDOS's fdisk utility on a real machine and, to say it
> carefully, IMO this tool needs to be improved.

definitively!

>
> There are currently 2 binaries delivered in the fdisk package:
>
> - FDISK.EXE, version 1.2.1, dated 4/2003
> - FDISK131.EXE, version 1.3.1, dated 11/2008

that's a bug by itself.
by what criteria are users expected to choose the right one?

> On the machine was installed a "normal" WD SATA 1TB HD.
>
> Launching FDISK131, it just emits:
> "Error reading Hard DIsk! Addressed sector not found"
> and exits.
most likely due to
  VERSION W98
in the (missing) .INI file. if this is not set, during initialization

  if( (flags.version==W95) || (flags.version==W95B) || (flags.version==W98) )
   Check_For_INT13_Extensions();

and later it is not able to access some sectors above 2GB and (correctly) exits due to disk I/O error. better save than sorry.

>
> FDISK.EXE starts without error and allows to create a new (primary)
> partition ( I tried size 8192 MB), but it's unable to correctly calculate
> the starting sector, resulting in overlapping partitions:
>
> BI  Type                     Sector    Size         MB abs.
> Start-End
> -----------------------------------------------------------------------
> 80  83 Linux ext2fs                  2048 390701056 190772 2048-390703103
> 00  0c Prim. DOS (FAT32,LBA)    390703104  16777216   8192
> 390703104-407480319
> 00  0c Prim. DOS (FAT32,LBA)    407472660  16787925   8197
> 407472660-424260584
>
> As it can be seen, partition 2 and 3 do overlapp, sectors
> 407,472,660-407,480,319 are part of both partitions.

I still haven't found the precise bug location, but the problem seems to be:

FDISK does all inner computations with cylinders, and simply assumes heads=0 sector = 1.

even reading the partition table, head and sector are basically ignored

Read_Partition_Tables()
{
...
          pDrive->pri_part[index].start_sect=1;
          pDrive->pri_part[index].start_cyl
           =Extract_Cylinder_From_LBA_Value(
           pDrive->pri_part[index].rel_sect
           ,pDrive->pri_part[index].start_head
           ,pDrive->pri_part[index].start_sect
           ,pDrive->total_head
           ,pDrive->total_sect);

          pDrive->pri_part[index].end_head=pDrive->total_head;
          pDrive->pri_part[index].end_sect=pDrive->total_sect;
          pDrive->pri_part[index].end_cyl
           =Extract_Cylinder_From_LBA_Value(
           /* */
           (pDrive->pri_part[index].rel_sect
           +pDrive->pri_part[index].num_sect)
           ,pDrive->pri_part[index].end_head
           ,pDrive->pri_part[index].end_sect
           ,pDrive->total_head
           ,pDrive->total_sect);


now in your partition table,

BI Type                    Start-C/H/S   End-C/H/S     Sector     Size      MB  abs. Start/End
-----------------------------------------------------------------------------------------------
80 0e Prim. DOS,FAT16,LBA     0/  1/ 1  975/ 63/32         32    4096000   2000 32-4096031
00 0c Prim. DOS,FAT32,LBA   976/  0/ 1  534/ 63/32    4096000  120731648  58951
00 00 Free Entry              0/  0/ 0    0/  0/ 0          0          0      0
00 00 Free Entry              0/  0/ 0    0/  0/ 0          0          0      0


the FDISK cylinder is one larger than the ending cylinder of the first partition.

yes, this is a bug. unfortunately fixing this would probably require a major code change. should be possible.

the real problem here is that code changes in partition creating/deleting/whatever code is dangerous stuff as this risks losing data.

my recommendation: stop using FDISK. there are better alternatives anyway.

> that's a bug by itself.
> by what criteria are users expected to choose the right one?

Somewhat hidden (in file NEWS.TXT) there's an explanation:

Current Stable Production Release: 1.2.1
Current Beta Release: 1.3.1

> yes, this is a bug. unfortunately fixing this would probably require a
> major code change. should be possible.

I don't think a "major code change" is necessary. fdisk may remain focused on "cylinders", wasting 1 or 2 MBs. That won't hurt.

> the real problem here is that code changes in partition
> creating/deleting/whatever code is dangerous stuff as this risks losing
> data.
> my recommendation: stop using FDISK. there are better alternatives anyway.

Well, yes, of course, but the current status is that the risk already exists.
Even if the bug won't be fixed and recommended to use another tool for partitioning, there still exist potential data losses due to the usage of FD fdisk in the past 15-20 years. Is this to be ignored? Wouldn't it at least be necessary to supply a tool that detects those overlaps and warns the user?

---
MS-DOS forever!

> Even if the bug won't be fixed and recommended to use another tool for
> partitioning, there still exist potential data losses due to the usage of
> FD fdisk in the past 15-20 years. Is this to be ignored? Wouldn't it at
> least be necessary to supply a tool that detects those overlaps and warns
> the user?

That sounds like a great idea. It could even mark the affected clusters as broken to prevent using them. FDISK itself should probably show a big warning when it sees overlap, but I do not know whether just truncating the overlapping partition would not cause too many side effects itself. At the very least, DOS
will be upset about mismatching partition and filesystem (boot sector data) sizes.

Also thanks to everybody who is investigating what and why FDISK messes up!

---
FreeDOS / DOSEMU2 / ...

> Well, yes, of course, but the current status is that the risk already
> exists.
> Even if the bug won't be fixed and recommended to use another tool for
> partitioning, there still exist potential data losses due to the usage of
> FD fdisk in the past 15-20 years. Is this to be ignored? Wouldn't it at
> least be necessary to supply a tool that detects those overlaps and warns
> the user?

Such a tool should be included in every new FreeDOS release then. It should become part of the install/upgrade process to check for overlapping.

---
Forum admin

> > that's a bug by itself.
> > by what criteria are users expected to choose the right one?
>
>
> Somewhat hidden (in file NEWS.TXT) there's an explanation:
>
> Current Stable Production Release: 1.2.1
> Current Beta Release: 1.3.1
>
> > yes, this is a bug. unfortunately fixing this would probably require a
> > major code change. should be possible.
>
> I don't think a "major code change" is necessary. fdisk may remain focused
> on "cylinders", wasting 1 or 2 MBs. That won't hurt.
it's certainly not about 1 or 2 MBs.

I think I understand the problem now, and it's not easy to fix.

for ease of arithmetic, assume a cylinder size of 1000 sectors.

if an existing 4500 sector partition extends from 5200 to 9700, FDISK will "round down" this partition to 5000 through 9999, will create the next partition at 10000, and everybody is happy.

if an existing 4500 sector partition extends from 5600 to 10100, FDISK will "round down" this partition to 5000 through 9999, will create the next partition at 10000, and everybody is unhappy (sooner or later).

this error comes up similarly when calculating available space before/after/between partitions.

good luck coming up with an efficient solution.


IMO the only way to fix this is to transform the code to use sectors, not cylinders. and that's a major transformation.

or use either FDISK exclusively, or use your Linux/windows/pqmagic partitioner only.

> > Even if the bug won't be fixed and recommended to use another tool for
> > partitioning, there still exist potential data losses due to the usage
> of
> > FD FDISK in the past 15-20 years. Is this to be ignored? Wouldn't it at
> > least be necessary to supply a tool that detects those overlaps and
> warns
> > the user?
>
> That sounds like a great idea. It could even mark the affected clusters as
> broken to prevent using them.

it's a bit demanding to mark clusters in EXTFS/NTFS/BTTRFS partitions as broken to avoid overwriting a broken FAT partition.

anyway: when would such a tool be used, even if it existed?
after partitions have been set up, FDISK will typically never be used again.

at update time? typically every 5-10 years?

IMO the right point to check this would be in the kernel at INIT time.
it scans the partition tables anyway.

adding code to check for overlap between any partition and any other partition (including unknown partition types) is trivially a N^2 operation, certainly acceptable at init time.

and the kernel InitDisk code is executed regularly. printing a warning would be easy, and helpful.

and it would be really interesting to learn what Windows/Linux to with such damaged partitions.

> I think I understand the problem now, and it's not easy to fix.
>
> for ease of arithmetic, assume a cylinder size of 1000 sectors.
>
> if an existing 4500 sector partition extends from 5200 to 9700, FDISK will
> "round down" this partition to 5000 through 9999, will create the next
> partition at 10000, and everybody is happy.
>
> if an existing 4500 sector partition extends from 5600 to 10100, FDISK will
> "round down" this partition to 5000 through 9999, will create the next
> partition at 10000, and everybody is unhappy (sooner or later).

I do not understand... Why should FDISK "round down" the
start or end of the partition at all? It always has to
round AWAY from the actual start and end of existing
partitions. So in your example, if new partitions are
to have boundaries which are multiples of 1000 sectors,
the previous partition has to end at or before 5000 in
both examples and the next partition has to start at
10000 or later in the first and 11000 or later in the
second example. Rounding to NEAREST cylinder boundaries
seems to be always a bad idea?

Or are you saying the rounding just fails to know whether
it has to be up or rather down at the relevant moment, so
the author decided to simply round to nearest all times?

Regarding your next post: You say it would be hard to mark
clusters in non-FAT filesystems as blocked. My assumption
was that the FDISK bug only makes the END of FAT partitions
overlap later partitions. I was not expecting the bug to
also make the START of FAT partitions overlap non-FAT ones,
but indeed a FAT-based workaround cannot help you there.

I agree that it is a good thing if the KERNEL detects any
overlaps. Which makes me wonder whether it would be easy
to automatically block access to trailing overlapping FAT
clusters? Of course that still will not help you when the
partitions are also accessed by OTHER operating systems, so
a tool to mark overlapping clusters bad still sounds good.

So yes, I do like the suggestion to make the kernel check,
at least as a part of the solution.

---
FreeDOS / DOSEMU2 / ...

> > I think I understand the problem now, and it's not easy to fix.
> >
> > for ease of arithmetic, assume a cylinder size of 1000 sectors.
> >
> > if an existing 4500 sector partition extends from 5200 to 9700, FDISK
> will
> > "round down" this partition to 5000 through 9999, will create the next
> > partition at 10000, and everybody is happy.
> >
> > if an existing 4500 sector partition extends from 5600 to 10100, FDISK
> will
> > "round down" this partition to 5000 through 9999, will create the next
> > partition at 10000, and everybody is unhappy (sooner or later).
>
> I do not understand...
exactly. You do not understand.
It could help to read the relevant source code; search for Read_Partitiontables().


> Why should FDISK "round down" the
> start or end of the partition at all? It always has to
> round AWAY from the actual start and end of existing
> partitions. So in your example, if new partitions are
> to have boundaries which are multiples of 1000 sectors,
> the previous partition has to end at or before 5000 in
> both examples and the next partition has to start at
> 10000 or later in the first and 11000 or later in the
> second example. Rounding to NEAREST cylinder boundaries
> seems to be always a bad idea?
it's not 'rounding to NEAREST'. it's round DOWN for partition start,
round UP for (partition end + partition size). basically, FDISK thinks that partitions start at head=0, sector = 1, and end at head = 255, sector 63.


> Or are you saying the rounding just fails to know whether
> it has to be up or rather down at the relevant moment, so
> the author decided to simply round to nearest all times?
no.

> Regarding your next post: You say it would be hard to mark
> clusters in non-FAT filesystems as blocked. My assumption
> was that the FDISK bug only makes the END of FAT partitions
> overlap later partitions.
this bug has absolutely nothing to do with partition types.

> I agree that it is a good thing if the KERNEL detects any
> overlaps. Which makes me wonder whether it would be easy
> to automatically block access to trailing overlapping FAT
> clusters?
I really doubt other OS will implement code not to overwrite
partitions created by some buggy FDISK.

> Of course that still will not help you when the
> partitions are also accessed by OTHER operating systems, so
> a tool to mark overlapping clusters bad still sounds good.
Sure. And of course, you are not in charge to create such a tool