Re: [Freedos-devel] IFS API
Hi, On Mon, Feb 27, 2023 at 5:59 PM Aitor Santamaría wrote: > > As a matter of curiosity, given that we were unable to find a precise answer > to why Microsoft dropped IFS after MS-DOS 5.0 (although we had speculations), > I thought, why not ask ChatGPT (Bing) about that? > > I had hoped that there was some page that we weren't unable to find. Or even > it could have been better if ChatGPT had any access to information from > Microsoft that was not easily publicly accessible. > Neither seems to be true. Search engines are notoriously bad for anything niche. Heck, even popular stuff gives lots of wrong answers. There's still info out there, but you have to ask the right person. Most stuff is tucked away in storage or hidden in some retired guru's brain. The tech world overall is sadly not very interested in archaeology, neither preserving nor emulating nor documenting "obsolete" stuff. "Today and tomorrow" are all they care about. Everything else isn't important to them (mostly). > As a lover of computing archaeology, I fear that when Mr. Gates passes away, > we will have to do with ChatGPT's answer. Oh well. I'm not understanding exactly what you want to know. (But someone like Michal Necasek of OS/2 Museum probably could answer.) PC-DOS was the version for IBM hardware, and MS-DOS was licensed to others. While Microsoft was mostly responsible for DOS (and OS/2), IBM still played a heavy role. At least Wikipedia says "MS-DOS 4" was mostly IBM's work. When IBM "fired" MS, (AFAIK) IBM still had access to sources for Windows 3.0 and MS-DOS 5.0. So they kept updating PC-DOS until, what, 2003? MS-DOS 5 came out in 1991, right? And OS/2 1.0 came out in 1987. OS/2 was supposed to be "the future", and MS was primarily responsible for OS/2 1.x (the 16-bit version). 32-bit OS/2 didn't come until 1992, and 32-bit Windows NT (aka "MS's portable OS/2 rewrite") was 1993. NT did support HPFS, for example, for a few years. So why did the "buggy" DOS 4's IFS interface not survive? They were focused on other OSes. Wikipedia says that OS/2 later got drivers for UDF and JFS. Obviously NT preferred NTFS (journaled, unlike HPFS, with larger max file size) and eventually dropped booting atop FAT (e.g. Vista) for security and performance reasons. It could also just be a RAM issue. IIRC, the standard answer why Windows tools won't create FAT more than 32 GB is because it's too slow (esp. for a real-mode driver). Maybe they never could happily get a working HPFS driver for DOS. (The 16-bit HPFS driver for OS/2 allegedly only supports a 2 MB cache maximum.) So if nobody uses it or it's too buggy or it only helps a competitor OS, then why bother? (Sigh.) For example, a few years ago Linux removed the ext3 [sic] driver because they only needed ext2 and ext4 (backwards compatible). The main reason for keeping ext2 as a separate driver was because it was much cleaner and simpler code. (Besides, I guess some storage media won't require journaling.) Sorry if I am confused, I'm just trying to understand it myself. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi, On Sun, Feb 26, 2023 at 1:07 PM Bernd Boeckmann via Freedos-devel wrote: > > in the last two weeks I ported Free FDISK to Watcom C and started fixing the > bugs people mentioned > at the bttr forum and in the issue trackers. Great news! Thanks a ton for your work on this. BTW, it seems you still use NASM (instead of WASM). Seems redundant (no offense). > For people wanting to track the progress, I am doing the development at the > following repository: > https://github.com/boeckmann/fdisk. > > I will make merge requests to upstream https://github.com/fdos/fdisk in > regular intervals > > If you want something to be changed please send me an e-mail. I will try to > implement it if time permits it. Is makefile.bor still maintained? Do you still (also) support building it with that toolset (presumably freeware-ish TC++ 1.01 would work)? * https://github.com/boeckmann/fdisk/blob/master/SOURCE/FDISK/MAKEFILE.BOR 1. Invoking TLINK with a toolset path is unnecessary. You can use "tcc" (or bcc) to link as well. 2. You also don't need to manually create temporary linker response files. (I forget exactly, but it's something like @&&^ ... ^ to do it automatically.) See here for an example: * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/n16tcmak.zip Regarding OpenWatcom: * https://github.com/boeckmann/fdisk/blob/master/SOURCE/FDISK/MAKEFILE.WAT 1. Again, you don't need to manually create a temporary linker response file. Try using "LD = *wlink" instead, it will automatically handle long command lines. 2. "if exist *.OBJ @rm *.OBJ" is unnecessary, and you should be able to delete multiple files with Wmake's built-in "rm", e.g. "rm -f *.obj *.err *.lnk" with no error messages if not found. 3. Oh! And %UPX% is possibly a bad variable name since I think that's what the environment variable is also named, so that will override any internal makefile variable by default (if the user has set it). I recommend "PACKER" and "PACKERFLAGS", but this is not majorly important. Again, here's an example "makefile.wcd" of mine (but ignore the older Borland makefile in there): * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/nasm16.zip ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hey! As a matter of curiosity, given that we were unable to find a precise answer to why Microsoft dropped IFS after MS-DOS 5.0 (although we had speculations), I thought, why not ask ChatGPT (Bing) about that? The answer is quite curious (I can't send the image due to mailing list size limitations, but here it is the text): "Microsoft IFS (Installable File System) was a feature of MS-DOS 4.0 that allowed third-party file systems to be used with MS-DOS. However, it was not widely adopted by OEMs and had compatibility issues with some applications. MS-DOS 5.0 dropped support for IFS as it needed more conventional memory and focused on other improvements, such as memory management, disk utilities, and a full-screen editor". and it looks good, if it weren't because the main source for this answer was precisely my own previous email message in this mailing list. If asked THE SAME question (except that by accident I wrote "why" and not "Why"), I got a different answer, and had to interact with it: "I’m sorry, I couldn’t find any information about why Microsoft dropped support for IFS after MS-DOS 5.0. Do you have any more details about what IFS stands for or what it does? >> IFS is a feature that allows third-party file systems to be used with MS-DOS. Thank you for clarifying. I found some information about third-party file systems for MS-DOS. According to Wikipedia1, some examples of third-party file systems are HPFS, NTFS, CD-ROM and network file systems. However, I couldn’t find a clear reason why Microsoft dropped support for IFS after MS-DOS 5.0. One possible explanation is that Microsoft wanted to promote its own file system formats, such as FAT16B and later FAT3212, which were more compatible with Windows and other operating systems" Also sounds accurate. So the conclusions of this experience for me are: - The content was added fast to ChatGPT (this thread was recent) - ChatGPT was mostly able to "understand" the question (as much as a machine can "understand"), i.e. the algorithms are well tuned. And the answers look sensible. - Probably, there's no other information about IFS publicly available, so this is all we can have. I had hoped that there was some page that we weren't unable to find. Or even it could have been better if ChatGPT had any access to information from Microsoft that was not easily publicly accessible. Neither seems to be true. As a lover of computing archaeology, I fear that when Mr. Gates passes away, we will have to do with ChatGPT's answer. Oh well. Aitor On Sun, 26 Feb 2023 at 15:03, Liam Proven wrote: > On Fri, 24 Feb 2023 at 02:52, Ralf Quint wrote: > > > Well, it was OS2.NLM for Netware 3.1x up to 4.10, for 4.11, they named > > it LONG.NLM. > > Faint memory now but sounds right. > > > I think starting with Netware 5.0, it was a build-in > > module, no need to load a special name space anymore. > > Could be. I did a training course on NW5 but never deployed it in prod. > > > But by that time, > > the easy use of Netware was gone > > IMO that disappeared with 4. > > > > Yeah, that one I remember wasn't very popular, when thinking about that > > one, actually old "MC Hammer" comes into my head, "can't touch that"... > > > You needed a Mac client for Netware, and it wasn't popular. I did see > it a handful of times but the kind of companies who bought Macs and > Netware were, in my world, mutually exclusive. > > > Don't recall anything like this. Also hard to imagine, given the way how > > they handled permissions. After all, you wouldn't even see sub > > directories you didn't have the rights to access (one of the stupid > > things in Windows,). > > Even so. > > Internally: name begins with $XC%CVBE$%XD%, then don't let users > $45678 see that... > > > > IIRC, when trying once to do some data recovery on > > a Netware drive with the help of some folks at Compaq, it was very > > similar to a FAT filesystem. > > Yup. > > > Novell never published any technical info > > about the file system > > Yup. It was one nearly half meg file of handcoded assembly, and only a > few senior programmers understood it. It was the crown jewels and they > couldn't modernise or adapt it. > > Which is why NW5 brought in a whole new FS, but that didn't have the > performance and brough them down to mainstream nondedicated OS level. > > > > and the guys at Compaq could only give me hints > > over the phone, they had tech info from Novell but were not allowed to > > share anything in hard copy from that... > > Sounds highly plausible. > > > > I never used anything past 4.11, they tried to compete too much with NT > > Server at that time already and everything from 5.0 and up was a hot > mess. > > Somewhat but it did get better-integrated with time. > > > Might have to check if anyone ever continued to work on MARSNWE, which > > looked promising for a while until the original author dropped it. Just > > saw that a couple of years ago, it had been put up on GitHub (GitLab?) > > For a
Re: [Freedos-devel] Free FDISK interim builds
> However, when the disk already has a partition and is full… > > fdisk 1 /prio:2000 ; no error, no partition created, exit errorlevel 0 > fdisk 1 /pri:100,100 ; divide error, no partition created, exit errorlevel 3 Nice finding! Fixed in https://github.com/boeckmann/fdisk/commit/02990596691474cf93fb64fbdf13b12bffec47d0 > Should be good. Guess we will find out on Wednesday. Yes looks good, I will try it out :-) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi Bernd, > On Feb 27, 2023, at 12:57 PM, Bernd Boeckmann via Freedos-devel > wrote: > > >> Am 27.02.2023 um 17:28 schrieb jer...@shidel.net: >> >> I think I will go with a max partition of 2GB (FAT16) on real hardware and >> the entire disk (FAT32) inside Virtual Machines. > > If you want it to be FAT-16 I would suggest not doing /PRIO:2048 but instead > /PRIO:2047 or even less, because for the common CHS geometry .../254/63, 2048 > MB gets rounded up to 2055 MB. And that is beyond the maximum size of > „compatible“, 64 sectors per cluster, FAT-16 partitions. Just going to use 2000. After all, based on how hard drive manufacturers calculate sizes a 2GB hard disk would only be about 1907mb. > > FDISK always rounds the user specified size up to the next cylinder boundary. > It does not restrict the partition size but unconditionally sets the > partition type to FAT-16 if you specify /PRIO. So depending on the behaviour > of the format utility, it would either create a FAT-16 with a cluster size of > 128 sectors or waste space at the end of the partition. > > Greetings, Bernd After a little more testing, here is an interesting wrinkle found while experimenting on a 500mb VM hard drive. fdisk 1 /clear /prio:2000 ; no problem, creates a 500mb FAT16 fdisk 1 /clear /pri:100,100 ; no problem, creates a 500mb FAT32 However, when the disk already has a partition and is full… fdisk 1 /prio:2000 ; no error, no partition created, exit errorlevel 0 fdisk 1 /pri:100,100; divide error, no partition created, exit errorlevel 3 Since the installer first tests for partitions and only auto-partitions an empty drive, this is probably not a big problem. Unless for some reason, FDISK cannot create the partition for some unknown reason. Anyhow, I’ve implemented the partitioning changes in both installers. Basically, their new logic is something like this: if AnyPartitions(drive) = true then begin FDISK drive end else begin If IsVirtualMachine = true then begin FDISK drive /PRI:100,100 end else begin FDISK drive /PRIO:2000 end if ErrorOccured = true then begin FDISK drive end end REBOOT Should be good. Guess we will find out on Wednesday. :-) Jerome ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> Am 27.02.2023 um 19:31 schrieb jer...@shidel.net: > > Using your example, I think it would be easier for a user to understand as: > > fdisk 1 /clear /pri:2048 /ext:max /log:4096 /log:max > I agree and implemented it as you suggested. The MAX quantifier now internally is the same as the 100,100 thing. https://github.com/boeckmann/fdisk/commit/1933d8723a10ccf1128e5e7181f2aa76001d7756 /? help screens should get some overhaul. I will take care of it when I am through with bug fixing. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> On Feb 27, 2023, at 12:02 PM, Bernd Boeckmann via Freedos-devel > wrote: > >> Seriously, thank you. :-) > > Glad I could help :-) > >> On a side note: It might be nice to support '/prio:max’ and '/pri:max’. > > > Shouldn’t do /pri:100,100 the trick? Yep, works fine. > The ,100 indicates that the first value is to be interpreted as a percentage. > If you want to specify the size in MB you must NOT give the ,100 as a second > argument. As an example: > > fdisk 1 /clear /pri:2048 /ext:100,100 /log:4096 /log:100,100 > > Will wipe the disk, create a ~2048 MB primary partition, an extended > spawning the rest of the disk and two logical partitions, the first ~4096 MB > in size and the second filling the rest of the extended partition. Interesting, the HELP simply says: Creating primary partitions and logical drives: sizes in MB or [,100] in percent /PRI:[,100] [/SPEC:] [drive#] Creates a primary partition. Using your example, I think it would be easier for a user to understand as: fdisk 1 /clear /pri:2048 /ext:max /log:4096 /log:max But, that installer will just use 100,100 and not worry about it. :-) Jerome > > Greetings, Bernd > > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> I'm not sure if this fdisk can already do that, but additionally it > would also be very useful if it could align partitions to 4k rather > than 63 sectors to lower wear on flash drives (SSD, CompactFlash). You can certainly make a case for aligning things on 4k boundaries on both modern and old disks, but I don't think it has anything to do with wear on non-magnetic disks. From what I understand, much like magnetic disks a non-magnetic disk can (theoretically) be read a virtually infinite number of times -- it's only the writing that wears things out. And again, much like modern magnetic disks, even if the native physical alignment is 4k (instead of 512 like the older disks) the firmware in the disk handles that all automatically. That is, if you are modifying only a single 512-byte sector the firmware does a read-modify-write sequence (it reads the entire 4k physical sector the 512-byte virtual sector is part of, modifies the part that's changed, and then writes the entire 4k sector back to disk). That's only one read and one write operation and the write is (supposedly) the only one that causes wear. If you use some sort of disk caching program (especially one that caches the writes) it gets more complicated, but in general the caching makes things more efficient both in terms of speed and wear. I think the justification for 4k alignment would come from speed rather than wear, since if cluster alignment and physical sector alignment don't match writing a _cluster_ can take multiple writes (but not to the _same_ physical sector so wear doesn't really come into play). On older magnetic disks, the reason they aligned things on odd-numbered sector boundaries was not for wear but for speed. The old disks would sometimes needed to physically move the head to a new location and wait for the disk to spin around again before it could start reading or writing. If that happened in the middle of a cluster read/write it slowed things down and did cause wear on the head movement mechanism. But odd-numbered sectors never aligned with cluster sizes of more than one sector anyway, so the alignment never really made much (if any) difference in terms of wear or speed. In reality, 4k alignment is just as good as odd-numbered alignment for both speed and wear on older disks, and 4k alignment is much better on new disks. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> Am 27.02.2023 um 17:28 schrieb jer...@shidel.net: > > I think I will go with a max partition of 2GB (FAT16) on real hardware and > the entire disk (FAT32) inside Virtual Machines. If you want it to be FAT-16 I would suggest not doing /PRIO:2048 but instead /PRIO:2047 or even less, because for the common CHS geometry .../254/63, 2048 MB gets rounded up to 2055 MB. And that is beyond the maximum size of „compatible“, 64 sectors per cluster, FAT-16 partitions. FDISK always rounds the user specified size up to the next cylinder boundary. It does not restrict the partition size but unconditionally sets the partition type to FAT-16 if you specify /PRIO. So depending on the behaviour of the format utility, it would either create a FAT-16 with a cluster size of 128 sectors or waste space at the end of the partition. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
On Mon, 27 Feb 2023 16:55:31 +0100
tom ehlert wrote:
> I hate feature flags as they must be decovered first.
>
> hiding it behind
>
>if lba_supported_by_disk and
> total_disk_size > 8,4 GB // max total size for CHS addressing
> {
> place partitions on 4K boundary
> }
>
> Tom
Hi,
Unless CompactFlash cards do some firmware magic to solve the 4k
alignment problem that I'm not aware of, there are plenty of
CompactFlash cards that are smaller than 8.4GB. This may also be
true of SD cards. util-linux fdisk detects if a mass storage device is
flash or not and automatically aligns to 4K as appropriate. But this
may be much harder to do with DOS/older computers. So an unconditional
switch like /4K would be better here.
--
WWW: https://metalpunks.info
GPG: C90CAB7122AC1231
pgp9zmhDtni4x.pgp
Description: OpenPGP digital signature
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> Seriously, thank you. :-) Glad I could help :-) > On a side note: It might be nice to support '/prio:max’ and '/pri:max’. Shouldn’t do /pri:100,100 the trick? The ,100 indicates that the first value is to be interpreted as a percentage. If you want to specify the size in MB you must NOT give the ,100 as a second argument. As an example: fdisk 1 /clear /pri:2048 /ext:100,100 /log:4096 /log:100,100 Will wipe the disk, create a ~2048 MB primary partition, an extended spawning the rest of the disk and two logical partitions, the first ~4096 MB in size and the second filling the rest of the extended partition. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi, > On Feb 27, 2023, at 7:27 AM, Bernd Boeckmann via Freedos-devel > wrote: > > Hi Jerome, > >> Am 26.02.2023 um 23:31 schrieb Jerome Shidel : >> >> Unfortunately, the current FDISK performs this task be creating a bunch of >> 2GB partitions. This tends to annoy users installing on real hardware with >> very large disks. > > Yes at the moment it sadly is hardcoded to creating partitions of 2048 MB in > size. > >> I propose two additional options that could be added to modify what occurs >> when partitions are automatically created. >> >> First, the ability to only create a single partition automatically. Leaving >> the the remainder of the disk unallocated. >> >> Second, an option to tell it to use FAT32 and create the partitions as large >> as possible. >> >> The options could be used together or separately along with the >> auto-partition option. > > FDISK should already be able to create primary partitions etc. from the > command line. Therefore suggest the following: > > fdisk /ifempty /pri: … We learn something new every day… Where were you about 7 or 8 years ago when I was creating the installer? I had not been used FreeDOS much up to then and it would have been great to have this simple answer at that time. Seriously, thank you. :-) I just did a simple test inside a VM with a 32gb drive. Booted T2302 Live CD and ran: fdisk /pri:8589934592,100 1 Invalid partition size specifed ; should be ‘specified' Program terminated fdisk /pri:8589934591,100 1 ; no error or other messages displayed I ran fdisk and checked. Entire drive used with single partition. Good enough. Now lets see if I can squeeze an update to both installers out the door before the next OS Interim Build (T2303) in just under 48 hours. Not difficult to implement. But, I’m tied up with other things at the moment. I will try to work it in later today or tomorrow. If it is not ready for T2303, then definitely by T2304. I think I will go with a max partition of 2GB (FAT16) on real hardware and the entire disk (FAT32) inside Virtual Machines. On a side note: It might be nice to support '/prio:max’ and '/pri:max’. > The proposal here is /ifempty. That would make FDISK terminate if the > partition table is not empty, and in effect ignoring all the arguments behind > it. So the partitions are conditionally created only if the disk is > „uninitialized“. > > Perhaps the FreeDOS installer could make the user choose between a few > different partition layouts if it detects that the partition table is empty. > If you need a way to make FDISK tell the installer if the disk is empty give > me a note. I can make FDISK return that info via exit code in a fdisk > /isempty like call. > > The /auto option then could for compatibility reasons stay as it is. > > Greetings, Bernd At present, the installer looks to see if there is an existing usable DOS partition. If there is not and if there are no partitions at all, it auto-partitions the drive. If there is not and any partitions exist, it executes fdisk and lets the user worry about the problem. It performs the check for partitions by using FDISK and parsing the returned information about the drive. While having an /isempty option is not required at present, it would be much better to have FDISK perform the test instead of the installer. That way in the future, no problems occur if the return information from FDISK is modified in such a way that the installer cannot figure out. That would simplify that portion of the installer to just… Hey, try and make a partition if it is empty. Failed? Ok, run then fdisk. It would also permit the installer to “auto-partition” an empty drive when it was not able to create a ram disk. Which is required to parse the return information by the batch based installer when no existing usable drives are ready. :-) Jerome ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hallo Herr Bernd Boeckmann via Freedos-devel,
am Montag, 27. Februar 2023 um 13:07 schrieben Sie:
>> Am 27.02.2023 um 07:26 schrieb Deposite Pirate :
>>
>> I'm not sure if this fdisk can already do that, but additionally it
>> would also be very useful if it could align partitions to 4k rather than
>> 63 sectors to lower wear on flash drives (SSD, CompactFlash).
> The current behaviour is to always align partitions to cylinder
> boundaries. This may be a multiple of 63 sectors if it corresponds to the
> disk geometry.
> I did not find any option in the source code to force FDISK to use
> other alignment options . All the calculations are done on a
> cylinder basis, and the sector size is hardcoded to 512 bytes.
> Can it be modified with reasonable effort to at least support 4k
> alignment without rewriting 50% of the code? I think yes. One
> solution could be that within the calculated cylinder boundaries one
> could increase the starting sector by at most 7 to force an
> alignment to 4k. That would make the partition start on a 4k
> boundary.
that sounds like a really good idea, and old versions of anyDOS should
also handlethis well.
> I am not sure if it is also necessary to decrease the end
> sector by at most 7 to make the partition size a multiple of 4k, but
> for safety reasons one should consider doing that.
I don't think this would be necessary; I don't think any reasonable
formatter that allows for a starting sector != 0 but not respecting
endsector!= maxsec-1
> This method would have the shortcoming that there can be little
> gaps of at most 15 sectors between the partitions. And I am not sure
> what that change would mean to the compatibility with older DOS
> versions in general, so that should better be hidden behind a feature flag.
I hate feature flags as they must be decovered first.
hiding it behind
if lba_supported_by_disk and
total_disk_size > 8,4 GB // max total size for CHS addressing
{
place partitions on 4K boundary
}
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi Jerome, > Am 26.02.2023 um 23:31 schrieb Jerome Shidel : > > Unfortunately, the current FDISK performs this task be creating a bunch of > 2GB partitions. This tends to annoy users installing on real hardware with > very large disks. Yes at the moment it sadly is hardcoded to creating partitions of 2048 MB in size. > I propose two additional options that could be added to modify what occurs > when partitions are automatically created. > > First, the ability to only create a single partition automatically. Leaving > the the remainder of the disk unallocated. > > Second, an option to tell it to use FAT32 and create the partitions as large > as possible. > > The options could be used together or separately along with the > auto-partition option. FDISK should already be able to create primary partitions etc. from the command line. Therefore suggest the following: fdisk /ifempty /pri: ... The proposal here is /ifempty. That would make FDISK terminate if the partition table is not empty, and in effect ignoring all the arguments behind it. So the partitions are conditionally created only if the disk is „uninitialized“. Perhaps the FreeDOS installer could make the user choose between a few different partition layouts if it detects that the partition table is empty. If you need a way to make FDISK tell the installer if the disk is empty give me a note. I can make FDISK return that info via exit code in a fdisk /isempty like call. The /auto option then could for compatibility reasons stay as it is. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
> Am 27.02.2023 um 07:26 schrieb Deposite Pirate : > > I'm not sure if this fdisk can already do that, but additionally it > would also be very useful if it could align partitions to 4k rather than > 63 sectors to lower wear on flash drives (SSD, CompactFlash). The current behaviour is to always align partitions to cylinder boundaries. This may be a multiple of 63 sectors if it corresponds to the disk geometry. I did not find any option in the source code to force FDISK to use other alignment options . All the calculations are done on a cylinder basis, and the sector size is hardcoded to 512 bytes. Can it be modified with reasonable effort to at least support 4k alignment without rewriting 50% of the code? I think yes. One solution could be that within the calculated cylinder boundaries one could increase the starting sector by at most 7 to force an alignment to 4k. That would make the partition start on a 4k boundary. I am not sure if it is also necessary to decrease the end sector by at most 7 to make the partition size a multiple of 4k, but for safety reasons one should consider doing that. This method would have the shortcoming that there can be little gaps of at most 15 sectors between the partitions. And I am not sure what that change would mean to the compatibility with older DOS versions in general, so that should better be hidden behind a feature flag. Greetings, Bernd ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
