fdos / fdisk Goto Github PK

As it turns out, most text files in the repository index are stored in LF endings, but not all of them. I am wondering what should be the line endings in the git index for a DOS based application?

Additionally Git interferes when checking out and committing files. Converting them in some form or another.

git ls-files --eol gives the following for my machine (i/ = index, w/ = working dir):

[...]
i/lf    w/lf    attr/                 	SOURCE/FDISK/NLS/regen.bat
i/lf    w/lf    attr/                 	SOURCE/FDISK/PCOMPUTE.C
i/lf    w/lf    attr/                 	SOURCE/FDISK/PCOMPUTE.H
i/lf    w/lf    attr/                 	SOURCE/FDISK/PDISKIO.C
i/lf    w/lf    attr/                 	SOURCE/FDISK/PDISKIO.H
i/lf    w/lf    attr/                 	SOURCE/FDISK/PRINTF.C
i/lf    w/lf    attr/                 	SOURCE/FDISK/PRINTF.H
i/lf    w/lf    attr/                 	SOURCE/FDISK/SMARTMBR.ASM
i/crlf  w/crlf  attr/                 	SOURCE/FDISK/SVARLANG/autoload.c
i/crlf  w/crlf  attr/                 	SOURCE/FDISK/SVARLANG/history.txt
i/crlf  w/crlf  attr/                 	SOURCE/FDISK/SVARLANG/makefile
[...]

My question is: Shall we store LF or CRLF in the index?

Optimal case would be to once correct the line endings for all files, and then tell the git clients to under no circumstances touch any line endings.

I am unsure how to proceed.

I mark this as a bug, because Microsoft FDISK works with these combinations.

Turns out that these quirky combinations work if a disk system reset is performed after a failed IO operation. I modified the read-write routines to retry up to three times, with a controller reset between each retry. This solves the problem for the hardware I tested.

Interestingly, I not only have fdisk 1.2.0, 1.2.1 and 1.3.1
but also fdisk132.zip here (2009-06-08) but we only talk
about 1.2.1 and 1.3.1 in this thread?

Source from user mceric post on DOS ain't dead forum on 12.01.2021

The code has a number of inline assembly calls for AH=7/INT 21h. Some of these are "press a key" instances. Others use it for accepting keyboard input.

getch() from conio.h is the closest equivalent. But Watcom C uses AH=8/INT 21h, which is similar.

AH=7/INT 21 is direct character input.
AH=8/INT 21 is character input checks for Ctrl+Break Ctrl+C and upon those key combos raises INT 23h.

The proposal is to replace inline assembly for AH=7/INT 21h with a keypress function that does the same thing.

Put this probably into USERINT1.C:

/* Read a single character from the keyboard, not buffered.
   Functionally very similar to getch() fron conio.h.
   returns an unsigned char for the key press. */
unsigned char Get_Keypress(void) {
        union REGS r;

	regs.h.ah = 7;        /* Direct Console Character Input without Echo. */
	intdos(&regs, &regs); /* Won't raise INT 23h on Ctrl+C or Ctrl+Break. */

	return regs.h.al;
}

Making this one fuction has an additional benefit that one could more easily place an #ifdef __COMPILER__ here for a compiler doesn't support intdos() or uses a different syntax. Also, the function could be easily edited to allow yielding.

The effect of this change would be to remove some of the inline assembly code in an effort to make the code a little more portable. Since, Watcom C uses a different inline assembly syntax.

If the 1.3.1 BETA is to be merged or not, this code should be done after that decision.

Sources:
http://spike.scu.edu.au/~barry/interrupts.html#ah07
https://dos4gw.org/08h_8_Console_Character_Input_without_Echo

Ben Russel wrote to the FreeDOS developer mailinglist:

This highlights a specific case where the "read error while reading drive" message will pop up on boot.
I have an HP Brio 8314 which has this problem. If you don't have this exact machine, 86Box has a machine with the same problem: Slot 1, "[i440LX] Micronics Spitfire". It is not a hardware bug, it is a BIOS bug.

For some reason, under some unknown circumstances, certain releases of PhoenixBIOS 4.0 Release 6.0 (with a copyright extending to 1997) will incorrectly set DL to 0x00 before jumping into the MBR code. This results in the MBR loader trying to load a partition boot sector from the first floppy drive.

The patch I am using right now is roughly equivalent to the following DEBUG patch (MBR extracted via FDISK /SMBR using the 1.3 Live CD release and the BOOTNORM loader):

debug boot.mbr
a11d
jmp 1fe0:7d10

a210
mov dl, 80
jmp 122

w
q

However, a proper fix for this should be something like this, executed before one attempts to use INT 0x13:

;; Work around a bug in 1997 PhoenixBIOS 4.0 Release 6.0,
;; where DL can be erroneously set to 0x00 (first floppy drive)
cmp dl, 0x00
jne nodlbug
mov dl, 0x80
nodlbug:

(I release all code in this email into the public domain.)

I'd need to do further analysis to see how a second hard drive behaves, but this will cover the most common case.

Two further points of note:
1. In the MS-DOS 4.00 sources, the drive number is loaded from the MBR in such a way that it gets forced to 0x80. But that makes it effectively impossible to boot from a different drive number.
2. The PnP BIOS specifications require DL to be set to the boot drive, and this BIOS does have PnP support. This confirms that the behaviour from the BIOS is a bug.

Regards,
Ben R

P.S. If you have a later version of FreeDOS FDISK and you used an earlier version with the /SMBR switch, *DO NOT USE THE /LOADMBR SWITCH!* You will lose all partitioning information and probably have to wipe your disk and reinstall everything. Use /LOADIPL in that case instead! (or the /AMBR alias, which is what you would have been using before.) Yes, I learnt this from experience, unfortunately.

Here is a lea that can be replaced by a mov to save a byte:

You don't check for multiple partitions marked as active (lDOS oldmbr does):

If you address the relocated loader with segment zero then you only need one far jump (to relocate) and the jump to the next loader could be near instead:

The print function is only ever called to halt the machine so you could put the halting into this function rather than returning to after the ASCIZ message string:

The LBA packet could be aligned, at least on a word boundary (align 2 before the label):

The word "shoud" is a misspelling:

shr cx, 1 \ jnc ... is a byte shorter than using test because test needs an immediate byte:

The trail stc \ int 13h \ retn here can be shared with the CHS path, saving two bytes:

Function 42h doesn't use al so there is no need to init it to zero:

You're depending on the CHS tuple from the partition table entry if using CHS access (lDOS MBRs calculate CHS address from the LBA start using the geometry queried from function 08h):

I don't really see a reason why not to relocate to 600h like is standard for MBR loaders. If you combine this with my earlier cs = ds = es = 0 suggestion the relocation even may save a byte or two.

Over here you assume that there is enough space for the partition table. I think you should cause a build error if there would be overlap:

Finally, the reason I wanted to write this was I want the MBR to pass ds:si -> partition table entry being booted. This is what lDOS MBR do and also lDOS boot attempts to detect unless patched out eg using the build option or instsect /P none (in the instsect help).

@mateuszviste New issue to not pollute the french language issue.

I set up a Github action that builds master on my Linux system with Open Watcom v2, and as a build artifact stores the fdisk.zip distribution file.

If you see other use cases for this actions thing feel free to comment here.

Currently, FDISK can be made more or less compatible with different DOS / Win9X and FDISK versions through version flags. This code could benefit from a little cleanup. Especially the Win9x and FreeDOS compatibility modes seem a little bit outdated.

There is also a problem with drive letters differing between FDISK and DOS, in cases where FDISK supports file systems not supported by the kernel, or the other way around.

@PerditionC FDISK considers FreeDOS Kernel to be compatible with Win95 feature wise, but not Win98. This may be outdated? I am not aware of any functions regarding partitioning and FAT that Win98 supports, but FreeDOS Kernel does not?

I am thinking of streamlining it like this: FDISK compatibility versions:
Version 7 (Win95), 8 (Win98), 9 (FreeDOS)

With 9 being the default, enabling some new FDISK features:

• LBA_MARKERS (CHS value 1023 instead of wrap-around) = ON
• Logical LBA Partitions inside LBA extended

And DOS / Win9x compatibility <=8:

• LBA_MARKER=OFF, aka CHS cylinder overflow
• NO LBA partitions insidde LBA extended, regardless of end sector (MS-FDISK compatibility!)

To be extended...

FDISK can be built as two different names: Free FDISK or FreeDOS FDISK. All the rest is strictly identical, only the names change.

Is this really necessary? I mean, it's a complication for the build and for translations, while it does not provide any functional difference. Maybe would it be possible to select one of the names and stick to it?
FDISK
Free FDISK
FreeDOS FDISK

My preference goes to just "FDISK", but if there is a risk of confusion with MS FDISK, then Free FDISK would be my second choice.

The I16-GCC makefile does currently not have correct dependency information for the targets. Especially if a header file gets updated, the targets depending on it do not get rebuilt.

It also does not contain support for building the distribution ZIP.

Hello,

on my system, fdisk v1.3.11 is unable to assign correct drive letters to partitions.

There are 2 disks on the system, with the following partitions:

Drive 0: EDD-Version=30 API-Bitmap=1
ExInt13: Flags=0000 Sectors=3907029168 (1907729 MB) SecSize=512
EDD3: bus=PCI interface=SATA IFPath=1/0/1/-1 [bus/dev/fn/chl] devpath=0,0,0
BI Type                    Start-C/H/S   End-C/H/S     Sector     Size      MB 
-------------------------------------------------------------------------------
80 83 Linux ext2fs            0/  0/ 1  460/254/63       2048  204800000 100000
00 82 Linux Swap            460/  0/ 1  480/254/63  204802048   16777216   8192
00 0c Prim. DOS,FAT32,LBA   480/  0/ 1  501/254/63  221579264   16777216   8192
00 0f Extended DOS,LBA      501/  0/ 1  428/254/63  238356480 3668672688 1791344
*1 0c Prim. DOS,FAT32,LBA   501/ 33/45  602/203/49         32   83888096  40960

Drive 1: EDD-Version=30 API-Bitmap=1
ExInt13: Flags=0000 Sectors=500118192 (244198 MB) SecSize=512
EDD3: bus=PCI interface=SATA IFPath=1/0/1/-1 [bus/dev/fn/chl] devpath=4,0,0
BI Type                    Start-C/H/S   End-C/H/S     Sector     Size      MB 
-------------------------------------------------------------------------------
80 0c Prim. DOS,FAT32,LBA     0/ 32/33 1007/254/63       2048   65536000  32000
00 83 Linux ext2fs         1007/  0/ 1   64/254/63   65538048   67108864  32768
00 07 HPFS,NTFS,exFAT        64/  0/ 1  146/254/63  132646912   67108864  32768
00 0e Prim. DOS,FAT16,LBA   146/  0/ 1  401/254/63  199755776    4096000   2000

As it can be seen, each disk contains at least 1 primary FAT partition. Disk 0 additionally contains a FAT partition in an extended partition, while disk 1 contains a secondary primary partition.

The problem is that FDisk assigns letter D: to the primary partition of disk 0, and letter C: to the (first) primary partition of disk 1.

MS fdisk ( contained in Win98SE ) assigns the drive letters correctly.

This is to aid system installers like the SvarDOS installer

Currently there is an incompatibility between the drive letter assignment of the (E)DR-DOS kernel and FDISK, as FDISK follows the FreeDOS (and Microsoft) way of assigning drive letters to partitions. But DR-DOS handles this differently.

We should detect if running under DR-DOS and adapt to its drive letter assignment.

A new FDISK config variable DLA will be introduced, defaulting to zero. This means that FDISK will try to auto-adapt its DLA to the operating system. DLA=1 means explicit FreeDOS DLA algorithm, while DLA=2 means explicit DR-DOS DLA algorithm.

Notice: The DLA of the FreeDOS kernel may be changed via a kernel config variable. There is currently no easy way to detect which DLA the FreeDOS kernel uses. But the default is to match the Microsoft way of doing it, and this is what FDISK assumes.

To fix this:

1. Remove -1 from CFLAGS.
2. Add options --best --8086 to UPX

yea i know, why would anyone in 2023 bang 8 drives in dos, but ya know, vmware lets me and i needed to detect disks and partitions in dos so i used /dump to list all disks then looped backwards through the numbers using /info %i% to get partitions for found disks in batch script. thats when i noticed fdisk doesnt apply a partitions to disk 8 (even if i jumble the disks so either scsi or ide lands in disk 8, neither will partition). It will read that its there, it will delete them, but it just wont apply them and so my batch always reads a disk with empty partition right after i partitioned them all. i tested this in win98 boot disk (so 7.10) and FDOS 1.3 which i think still ships with 1.3.4 but this happens in all versions i tested from 1.3.4 to 1.3.10.

if i use microsofts fdisk's with 'fdisk 8/pri:65536' , it makes the full partition and then ffdisk can do anything after that.

tried in vmware with 4-ide(1gb) drives and 4-scsi(2gb) drives, then on w98 bootdisk i tried with both scsi and ide in disc 8 position, then i switched over a mini 1.3 fdos floppy and tried the same and it also failed to create the disc, on fdos i only tried 1 dirve (not sure if it was ide or scsi at that time and i did not try ms's fdisk on fdos as i assumed for ffdisk to have the best chance to work in fdos and after the first fail i assumed the results would be the same), i even tried the interactive menu and that has the same results which it can do anything but apply a partition to disc 8

FDISK comes with Makefiles for OpenWatcom and Borland.

Is there a reason to look over two builds? Sticking to one (preferably OW?) would make it less of a nuisance for developers to take care of the code. Not that I am particularly concerned of course. It's truly an open question.

FDISK gives up reading and / or writing a sector after one failed try. This should be tried multiple times before giving up.

Created from GitLab Archive FDISK Issue 3

Trying to write the BootEasy MBR to disk just prints

C:\>fdisk /bmbr 1
Syntax Error...Operation Terminated.
C:\>fdisk /mbr 1
C:\>

The blinking cursor is not shown in FDISK interactive user interface if launched from the FreeDOS installer. As a workaround, cursor settings should be stored / restored on FDISK start / termination, and the blinking cursor should be activated (via INT10,01?).

This is because some disk controller firmware seem to return garbage in AH if carry is clear (no error), and Open Watcom 1.9, I86LIB _bios_disk function calls do not check carry, but simply return AH as error code.

Currently there is a zoo of output routines that is a bit confusing. Also there are hardcoded cursor positioning calls, which is bad for localisation.

The idea is to replace output functions with ONE function called ansi_printf (yet to be implemented if not found somewhere else) that understands a subset of the ansi sequences described by https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/ANSI.txt

tnyprntf could be used as a base.

FDISK is rather an important utility to get a FreeDOS system up and running. Having this utility only in English is not ideal.

After reordering my PATH variable I noticed that the CWSDPMI build of NASM does not work anymore when invoked by Borland make.

Seems there are different versions of the make utility: A 16-bit protected mode version shipped with Turbo C++ 3.0 and Borland C++ 3.1 and a real mode version shipped with Borland Pascal 7.

If using the real mode make from Pascal the build runs perfectly, but NASM fails to launch if invoked by 16-bit protected mode version.

My guess is that this is "only" a problem under DosBox and DOS without a proper 16/32 bit DPMI host loaded prior to building the software. It should run fine under Win 3.1 - Win ME.

I am not sure how to solve this for all build tool combinations but document it here if someone has the same problem.

If one could please have a look at commit 68af979?

I translated the inline assembler to C and want to make sure I did not break anything. This code now also compiles with I16GCC.

Thanks!

This imposes a problem if INT13,41h is broken. The Book8088 device seems to be affected by this.

Currently, if an FDISKPT.INI exists, (longer) partition type names are read from this file. However, these these descriptions can also be included directly in the source code, because the memory is reserved anyway as part of the data structures.

I think we should throw out support for it, and with it the code needed to parse this file.

Hello @cardpuncher, I have bundled a translation package containing everything needed to generate and test the FDISK translation for french. Please see https://nextcloud.iww.rwth-aachen.de/index.php/s/w8nmaH8gMB9H3Rj

There is a HowTo.md describing the process. You can view it in the browser by clicking on the file. Would be great if you give me feedback so I can improve the howto for the other translators.

You may download all files as a ZIP archive.

Thanks for helping!

I noticed that when changeing the background color to something other than black via the above fdisk.ini option there are some parts of the screen getting a black background.

Is is a result of something like textattr or textbackground never being called. flags.screen_color is in fact only being used in the Clear_Screen function.

This is more work than I have thought, because I have yet to find a way to keep the unneeded SvarLANG strings out when not building the UI.

In the following help text (example) makes the user think that the drive number can be specified for each command individually. But that is not true.

  /CLEARMBR [drive#]       Deletes all partitions and boot code\n
  /LOADMBR  [drive#]       Loads part. table and code from \"boot.mbr\" into MBR\n

This is how it works: The command line gets parsed before executing the commands. If a number is encountered this gets set as the drive number. That number is used for every command. So for example the following is VERY dangerous:

FDISK /CLEARMBR 1 /INFO 2

The user can expect the first disk to be wiped and the partition info of drive two to be shown. But in fact the second drive gets wiped.

FDISK currently accepts the drive number as the first argument:

FDISK 1 /CLEARMBR /PRI:2000 /INFO

So the help text should be adjusted to make the user always give the drive number as the first argument. For backwards compatibility FDISK should continue to accept a drive number not as the first argument, but it should issue an error if more than one drive number is given in the command sequence.

If I understand correct, a zero-sized string is used as a termination marker in the compiled translation files. In the source translation files, there are lines like:

3.0:\t

I guess to prevent zero-sized strings? While doing german translation one of my multi-line strings was shorter than the original one, and I had a line like

3.5:

in the file, which totally broke things.

Perhaps one could reconsider to use $FFFF instead of 0 as a table termination marker? Would allow empty strings. I am also not sure if its wise to strip the trailing spaces. Please correct me if I understood it wrong.

The (E)DR-DOS kernel refuses partitions that exceed the disk size as reported by the BIOS. The size reported by the BIOS may be a few cylinders smaller than the disk actually is.

The Free FDISK default behaviour is to scan for one extra cylinder, and if found, allow partitions to use that additional cylinder, making the (E)DR-DOS kernels refusing to "login" the partitions.

For compatibility reasons, I tend to disable the scan for extra cylinders by default. This may be enabled by the .INI file shipped with the FreeDOS package.

In the section

For instance, if I modify the first entry as such:

9.10:\n\nPartition   Status   Mbytes   Description      Usage    Start CHS       End CHS\n
9.10:\n\nBölüntü     Status   Mbytes   Description      Usage    Start CHS       End CHS\n

the Status starts at a different line number than the original (22 vs. 25).

How to properly approach these strings?

I noticed that at least @ecm-pushbx s EDR-DOS and Calderas OpenDOS kernel 7.03 accept an unformatted partition created by Free and MS FDISK as valid FAT-16 volume. My first guess is that the fill value of 0xF6, which FDISK uses to erase the volume boot sector, is interpreted as valid media type by the DR-DOS kernel, and therefore the kernel tries to make sense of the BPB in some form. The volume shows with serial number F6F6:F6F6. MS-DOS kernel interprets F6 as invalid media type, and thus refuses to access the disk.

This is especially annoying in connection with FAT-32 partitions, because the DR kernel, regardless auf the partition type, ALWAYS interprets such unformatted partitions as FAT-16, and FreeDOS format tries to format it as FAT-16 accordingly.

There are three options:

• change Free FDISK
• and/or change EDR-DOS kernel to refuse access on media type F6
• ignore

It is available if FDISK is started in extended mode via /XO command line argument, but currently seems to do nothing.

On an older 486 emulation I noticed that FDISK did not work.

FDISK tried to access the 504 MB disk with ext. INT13 functions 4x.

While the BIOS returned general support for extended INT13 functions when queried with subfunction 41h, it did NOT set the required bit 1 in the CX register, indicating that functions 42h-44h,47h,48h are supported for the specific drive. But FDISK did not make use of this information and thought that support was there, resulting in reads and writes to fail.

Lastest version has cryptic error message when fails to find optional fdisk.ini configuration file.

Main cause of trouble porting it should be the inline assemly.

This is further complicated by the fact that I16-GCC crashes under my DosBox-X development environment.

See https://www.bttr-software.de/forum/forum_entry.php?id=17463

Apparently in rounding to cylinder boundary, fdisk rounds down when it should round up. Additionally, it should verify it is not creating overlapping partitions, especially if some were created by other partitioning software.

Windows 95/98 prevent FDISK from writing to partition table back to disk. Lock drive to make FDISK work under Win95+.