Re: [Freedos-devel] Free FDISK interim builds
Hi, On Tue, 28 Feb 2023 at 20:31, Eric Auer wrote: > > PS: Interesting that Bing ChatGPT answers Aitor using his own > mails, does it at least include some thanks to the author? :-) > Lol it does not, but it links to the log of pages, etc. where it took the answers from. That's how I found out... Aitor ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, On Tue, 28 Feb 2023 at 12:23, tom ehlert wrote: > 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 > > to start with, your question is pretty much nonsense. IFS or the > "networking redirector" was definitively there in MSDOS 6.2 and most > likely in 7 (aka Win95). > Well it was strongly related but different, what went forward on 4.0 was taken back on 5.0. > > I thought, why not ask ChatGPT (Bing) about that? > > in the meantime everybody should know that ChatGPT has a very > convinced attitude telling nonsense. I think asking it to find new > pointers is legitimate. Taking the answer for truth is not. > Although no new pointers seem to appear, it is nevertheless fun. To me, it is like "UI interface for a search engine" 2.0 Aitor ___ 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 Eric, > Now I would like to know how long each of those bugs has been > in FDISK, can you see that in change logs or by comparing your > version to various older versions? It must have been ages :-o I will try to find out and leave a note in CHANGES.md for all critical (potential data loss) errors since when the error exists. In the last hour I found a new bug: Critical: Fix a partition location and size calculation error triggered when a new logical partition is created after deleting the first logical (since at least 1.2.1) It was a one liner to fix but hard to spot: https://github.com/boeckmann/fdisk/commit/95e102270117b4d79430433da1948b31d8c35947 The error was that pDrive->ptr_ext_part is a pointer to the extended partition itself and not a pointer to the logical drive, so the test if the logical partition was empty returned always returned false even it was actually true. After replacing with pDrive->log_drive[0] it seems to work correctly and to me makes logically sense. Would be glad if someone could double check. 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 Bernd, thank you for your work on FDISK! Version 1.3.5 (unreleased) -- - CRITICAL: Fix FDISK loading wrong head and sector values from MBR if operating in LBA mode. The previous incorrect behaviuor was hardcoding them to cylinder boundaries instead of calculating them from LBA address, resulting in corrupt partition tables especially if used in combination with other disk utilities. - CRITICAL: Fix different calculation errors leading to overlapping partitions, unnessessary free space between them, or partitions exceeding the end of the disk. - CRITICAL: Fix a bug resulting in detecting non-existant extra cylinders if detection of extra cylinders is enabled. Now I would like to know how long each of those bugs has been in FDISK, can you see that in change logs or by comparing your version to various older versions? It must have been ages :-o Regards, Eric PS: Interesting that Bing ChatGPT answers Aitor using his own mails, does it at least include some thanks to the author? :-) ___ 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 Rugxulo, thanks for the advice! > Is makefile.bor still maintained? Do you still (also) support building > it with that toolset (presumably freeware-ish TC++ 1.01 would work)? Yes! At the moment I have it compiling with Borland C++ 3.1, Turbo C++ 3.0 and Open Watcom 1.9. While mainly developing under Watcom I think it is a good idea to have it compile with different toolchains. Helps finding bugs. However, the makefile I started working on did not mention Turbo C++ 1.01, so I did not test that. If someone requests Turbo C++ 1.01 support I will see what I can do. GCC IA-16 support could also be desirable. > it seems you still use NASM (instead of WASM). Seems redundant > (no offense). I have not touched the NASM code yet. I could change the code to assemble under WASM, but because I plan to still support the Borland toolchains I am not aware of any benefit that would bring. > 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. Done as you suggested. > 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.) > 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. I guess it is a thing of preference, but at least for Watcom I actually like the generation of separate linker files. Nevertheless dropping it at least for Borland is perhaps a good idea if that removes the need for specifying the toolchain installation path. I will try to change that. Greetings, Bernd ___ 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 to start with, your question is pretty much nonsense. IFS or the "networking redirector" was definitively there in MSDOS 6.2 and most likely in 7 (aka Win95). it just just that's the LANMAN and MSCDEX part was implemented in the protected mode part of the OS. but I'm pretty sure that NTFSDOS, NTFS4DOS and friends would work on msdos 7 as well, allthough I never tried that. I don't even know where this idea even originated. it's pure BS, at least for MSDOS 6.2. > (although we had speculations), yes. speculations. > I thought, why not ask ChatGPT (Bing) about that? in the meantime everybody should know that ChatGPT has a very convinced attitude telling nonsense. I think asking it to find new pointers is legitimate. Taking the answer for truth is not. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
