Re: [Freedos-user] virt-install freedos
>I believe the simplest will be to create the VM on another machine and learn >how to import it to the host machine. No, the simplest thing is to open up virt-manager on the other machine, go to "File -> Add connection", fill out the dialog to connect to the host machine, then go to "File -> New virtual machine" and select the connection you just added in the "connection" dropdown. Once you've done that, you can create and use a VM on the host machine exactly as if it were local to the machine you're running virt-manager on. That's the beauty of virt-manager: you can administer VMs on anything you can reach by ssh just as if they were local. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] virt-install freedos
>KVM is the underlying hypervisor here. It uses QEMU tools for creating disk images and things, but it doesn't use the core QEMU emulator for running x86 OSes on x86. KVM is a kernel component, so userland processes use it for things, not the other way around (specifically, it's a virtualization driver that turns the kernel into a hypervisor). It's more accurate to say that when the architecture of the guest OS matches that of the host CPU, QEMU uses the host CPU via KVM rather than emulating it. In any case, Cesar was talking about running QEMU via a front end vs. launching it bare, and that's independent of whether QEMU is using its own emulation or KVM as the backend to provide a CPU for the VM. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] virt-install freedos
>It would probably be more straightforward for me to use qemu directly, but as >I already have several VMs running managed by virt-manager, I wanted to keep >using it for FreeDOS. So virt-install is a tool for virt-manager, but I don't think I've ever used it directly (there's a good possibility the VM creation wizard for virt-manager uses it on the back end, I've never peeked under the hood to confirm that). Virt-manager can manage VMs on remote hosts, so I use the full-up graphical environment even for my headless VM host. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] virt-install freedos
>KVM/qemu as presented by virt-manager/virsh does something funny with the >config of the VM. After initial boot it’ll “forget” about the CDROM. I think what's happening is that it detaches the disk image if the virtual CD drive receives an eject command. On real hardware, if the software opens the CD tray but you still want the install media for the next boot, you just push the tray back in instead of removing the disk. On virtual hardware, if "eject" is interpreted as "detach", the ejection becomes a bit more of a hassle. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] "The very weird Hewlett Packard FreeDOS option"
>*I'll note that I don't see the same pre-installed OS options when I click on >the "HP Zbook Fury 17.8 G8" in the article. I only see "Windows 11 Pro," >"Windows 10 Pro," "Windows 11 Home," and "Ubuntu Linux 20.04." So either HP >has changed it, or the "FreeDOS" option is not available in the US (the >article's screenshots show purchase prices in Euro). I've heard of modern systems shipping with FreeDOS before: around 2012, apparently half of all laptops in Russia shipped with FreeDOS; the acquaintance that told me this said that it was basically a way of selling a PC without an operating system while still selling something that would boot (so that the technophobes don't come back complaining that you've sold them a brick), though I'd think Ubuntu would do that job just as well, in terms of licensing cost. Desktops in Russia, apparently, are almost exclusively built from parts by the owner or by a hired entrepreneur. I imagine shopping in the US vs. abroad has something to do with it: Russia is outright hostile to the US (and thus US companies), and the EU tends to do better than the US at restraining the kind of anticompetitive deals with manufacturers that MS gained infamy for cutting back in the 90's. So I'd imagine that companies like HP might well find themselves constrained by local law to offer a "no OS" (i.e. FreeDOS) option in those markets. So if MS is still cutting such deals, this is about what I'd expect to see: manufacturers offering FreeDOS abroad and not in the US. OTOH, my understanding is that most of MS's income these days is from enterprise volume licensing and support, and relatively little from per-machine licensing or the consumer market in general, so they don't have to have reformed any, morally speaking, for the reptuational risks of such deals to outweigh the rewards. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Country Code
The issue is memory-mapped hardware. Any hardware that exposes configuration resisters or data buffers on the main address bus ends up taking a block of physical address space that could be used by RAM. If your CPU, motherboard, and/or OS can't deal with physical addresses wider than 32 bits, then you can have a maximum of 4 GB of RAM *and* hardware that can addressed. So if you have 4 gigs of RAM and a graphics card with half a gig of VRAM exposed to the bus, then you end up with half a gig of main RAM that's unusable. Even with a CPU/OS/mainboard that can handle >32 bit physical addresses, you may see some RAM unusable: if the mainboard assigns DIMMs to consecutive addresses starting from zero, with no holes, and you have 4+ GB of RAM and a device that only handles 32-bit addresses, then the device will end up stealing addresses from some of your RAM under 4GB. Note that "dealing with physical addresses wider than 32 bits" doesn't mean "64-bit". Motherboards generally don't have a neat power-of-two bus width, and and when a CPU or OS is called 32/64 bit, that generally refers to *virtual* addresses. For x86, a 32-bit CPU/OS with PAE will handle 36-bit physical addresses. Dec 31, 2021 19:12:31 Travis Siegel : > Reminds me of my last XP machine, supposedly, XP could handle up to 4GB of > ram, but when I installed 4GB in my machine, XP only saw 3.5GB. No idea why, > I never did find out what the technical reason was, but it was a commonly > known problem, since almost everywhere I tried to get the ram from for the pc > insisted XP wouldn't see more than 3.5GB. Kind of odd I thought, but it > accomplished what I needed, so I was ok with it. I still have that machine > around here somewhere, though I've not turned it on in a couple years. :) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Country Code
Dec 30, 2021 12:22:48 Liam Proven : > > I have been using NT since the first version, 3.1, in 1993. There is > no built-in facility or tool to run DOS under it and never has been. > That is why I asked. This is highly relevant and important to the > question. There are no "dots" to follow. NTVDM exists and runs a stripped down version of MS-DOS 5. I think it even does have non-stripped versions of the relevant files available if the user decides to sys a floppy. But I've never heard of it being possible to run anything but there provided build of MS-DOS 5 in NTVDM. Maybe he ran the FreeDOS installer and managed to pull in components of FreeDOS, but unless he's using an emulator or VM, I agree that he certainly isn't running FreeDOS on top of XP. Jon Brase ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Video complains that DOS should not be maintained
On 12/26/21 3:18 PM, Aitor Santamaría wrote: My point here is, NT has indeed quite a bunch of more stable and better thought features of an operating system that was conceived in the late 80's rather in the late 70's (a better filesystem, more suitable to networks, and basically, a brand new Win32 API more suitable for writing stable applications), but I don't see multitasking as the feature that killed DOS. It was the feature that killed DOS. It's not that DOS couldn't multitask (though that depends a bit on how you define multitasking), it's that it couldn't do so safely and fully back-compatibly. The first generation x86 processors that DOS originally ran on didn't have any features to allow the operating system to isolate applications from the hardware. So tons of applications opted to interact with the hardware directly, because that was often more performant. By the time that the 286 and 386 added features that allowed robust multitasking, there were too many applications that interacted directly with the hardware, and by the time that features that would allow the OS to emulate hardware showed up in the 386, there were just too many different bits of hardware that the OS might need to emulate. So at that point, any DOS that wanted to multitask had to choose whether to maintain back-compatibility with applications that performed direct hardware access, at the cost of less completely isolating applications from each other, and from the OS, or whether to go for strict isolation, at the cost of back compatibility. Jon Brase ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Video complains that DOS should not be maintained
, Two things here: First, I've heard rumors (possibly true, possibly just people trying to make MS look incompetent) that MS actually lost the source code to some unspecified legacy version of Windows at some point (has to be legacy because if it had been a then-current main product line it probably would have killed them). So if they lost the entire DOS-kernel Windows source tree sometime after the release of XP, the reason they're not releasing sources for Win 3.x/9x may be that said sources no longer exist. Second, assuming they still have the sources, perhaps we can make it worth their while: basically, propose that they name a price and start a crowdfunding campaign. If the campaign meets the price they name, they release the code. Even if they did lose the code, getting a friendly license applied to the binaries and to stuff like the example code in the DDKs would be massively helpful: the binaries are definitely floating around, and being able to write compatibility drivers for FreeDOS/DOSBox/etc. would be quite helpful. We'd just need to find someone in the retrocomputing or FOSS community with the right connections and personality to pitch it to MS, and then we'd need the right sort of campaign to get people to pitch in (establishing a precedent of proprietary projects crowdfunding themselves to an open source release would be a huge win, we'd just need to convince people of that). Dec 25, 2021 16:35:41 Liam Proven : > > > Today, the entire DOS and Windows 3/9x codebase is basically entirely > obsolete and the company does not sell any products based on it. It > *could* release everything prior to the Windows NT line with no > substantial impact on any current product. > > However, this would cost it money. The code is probably a mess, and it > contains material from third parties which would have to be removed. A > large cleanup operation would be needed, which would take dozens of > people maybe years of work, and MS stands to gain nothing from it. > > However, it would help FreeDOS, and WINE, and ReactOS, and several > other FOSS projects, which MS management almost certainly does not > want to do. > > So, given it would benefit others but not the company, *and* it would > cost them serious money, I doubt it will happen. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Video complains that DOS should not be maintained
This is much more recently than I think you're thinking: https://github.com/Microsoft/MS-DOS Dec 24, 2021 22:42:44 Travis Siegel : > That was caldera that released their opendos as opensource, not Microsoft. > > There were versions of ms dos that escaped into the wild, but it wasn't a > sanctioned release from microsoft. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Video complains that DOS should not be maintained
I should probably add to my previous message that I don't think that the possibility that someone might expose FreeDOS in a business-critical embedded system to the network means it shouldn't be maintained, just that such an opinion isn't completely far-fetched. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Video complains that DOS should not be maintained
They're not talking about it in the context of log4j itself, they're talking about it in the context of other open source projects, that don't have something like the Apache foundation behind them, that are critical infrastructure, but have one or two maintainers working on them as a labor of love alongside a day job, and the potential, as such projects become legacy software, for them to still be half-maintained (and maybe maintain a significant user base) long after an institutionally maintained project would have officially been EOLed. And there is something of that kind of risk with any DOS variety still in use. Any remote execution vulnerability, through any network-aware DOS software, is basically automatically a remote root vulnerability by the nature of the system. Now, most FreeDOS users are probably using it for retrogaming and such and not for anything business-critical, but anybody using it in an embedded setting needs to be really careful about exposing it to the network. >I really wonder how that would effect DOS, after all there is no web >interface, nor any Java in (Free)DOS. So (without having watched this rather >long video yet), any such conclusion seems to be a bit far fetch IMHO... ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] reminder reminder?
I use Gmail, got one copy. Jon Brase ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FDNET missing from FreeDOS 1.3-RC4
Oct 13, 2021 23:39:17 Jim Hall > > > It appears that somewhere along the line, someone (at AMD?) had access > to the sources, probably in a larger source tree, and ran a batch job > or script to apply the "AMD" statement to a bunch of source files. And > that happened to catch these GPL and public domain source files. I > believe that was done in error. The original public domain and GPL > declarations trump the latter "AMD" statement. The only issue I see here is if AMD added any code to the public domain files. For the GPL files, the AMD violated the existing license by marking them as AMD proprietary, whether they added anything or not, and the only way for them to come back into compliance is to relicense the code under a GPL compatible license. So the GPL files are clean in any circumstance. For the public domain stuff, they can't claim copyright to anything that existed in the files when they received them, but they can claim copyright to anything that they added. If the original files can be traced and it can be demonstrated that AMD added nothing more than the copyright notices, then they're clean, otherwise it has to be determined what code was added by AMD, and that has to be stripped out. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] PCI SATA adapters with DOS
On 6/23/21 3:24 PM, Eric Auer wrote: > > Hi! > > Really odd that MS DOS does not see the SATA, > while FreeDOS apparently does? Maybe your SATA > controller comes with an odd LBA-only BIOS? > > If your MS DOS is limited to 1.3 GB because > of the IDE CHS geometry (which geometry is > that, exactly?) then you should use the MS > DOS of Win9x which supports LBA, or simply > use FreeDOS, which also supports LBA and > FAT32 :-) I'm not actually finding that DOS is having any trouble with its partition extending above 1.3 GB. It's just that I can't boot anything above that line. My DOS 6 environment is there to support a QEMM+Win3.11 setup, which simply will not work on FreeDOS. I do have a FreeDOS environment on the same partition for when I'm not working with that, and when the configuration was still single IDE I had Win95 on there as well. I've been trying to get Win98 installed, but that's where the 1.3 GB issue becomes problematic, as I'd like to have 2 GB for DOS (already working) plus at least 2 GB for Win9x, but whichever partition is second has to begin below 1.3 GB or Grub chokes on trying to boot it. Ideally, I wouldn't even have Win9x on the IDE drive as Win98 has drivers that will handle the SATA card, but, unfortunately, the Win98 installer isn't actually a Win98 environment, and in any case, won't allow me to load drivers before the install, so it won't see the SATA drive. > >> I'm able to boot from the SATA card if the IDE drive is on the secondary >> IDE channel, but not if it's on the primary channel. > > Apparently your BIOS insists to boot from > whatever is primary, which sounds plausible, > but unfortunately your SATA seems to work > with your combined BIOSes when it also is > primary? So why not just keep the SATA SSD > as primary? > You can still add the IDE as > a secondary drive for any CHS-only DOSes. Because when the SATA drive is present and the IDE drive is on the secondary channel, no DOS, not even FreeDOS, will even see the IDE drive. FreeDOS will see the SATA drive in any configuration, but MS-DOS never sees the SATA drive, and, like FreeDOS, only sees the IDE drive if it's on the primary channel. Win95 will not see the SATA drive. Win98 should be able to see the SATA drive if I can get it installed with the proper drivers, but has the chicken-and-egg problem that its installer won't let me load drivers before it's already installed (and I'm not actually sure, once its installed, that the drivers will even be loaded before the Win32 environment comes up, so it may well not be able to boot from the SATA drive under any circumstances). > > Which is exactly the other way round as your > current setup. I think both options should > be okay. Why would you want to hide your SSD > from DOS by making it unsupported secondary? It's not hidden from FreeDOS under any circumstances, and it's not visible to MS-DOS under any circumstances (except maybe to MS-DOS 7 once Win98 and its drivers for the SATA card are installed, but I'm not sure that WDM drivers are even loadable on Win9x in DOS mode. If not, then the SATA drive will be visible to Win98, once it's booted, as a data drive, but won't be usable as a boot drive). > Eric > > PS: You can even tell GRUB to reassign BIOS > drive numbers before booting DOS, by keeping > some small resident part active, I think. > I don't believe this is actually an issue with BIOS drive numbers. Note that FreeDOS is perfectly capable of seeing and booting off the SATA drive whether it's primary or secondary, but doesn't see the IDE drive unless the IDE drive is primary. Jon Brase ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] PCI SATA adapters with DOS
Hi! I am not sure if we have understoood Jon's question correctly. Not so much a question just as a review of what I was able to achieve with the plan of action Liam had suggested back in March and the constraints existing in my configuration. As I said, I have the most crucial bits of my configuration working. Does he need any changes for the BIOS at all? Maybe the issue is simply that MS DOS can only use the first 8 GB of your disk, with at most 2 GB per partition, because it is FAT16 CHS only? Yeah, but I don't really need more than that. The original plan had been to boot everything from the SATA disk (SSD, using an expanded version of the partition layout from when the machine was single-IDE) with the IDE disk (magnetic) reserved for swap, but MS-DOS simply will not see anything on the SATA card, so a 2 GB partition on the IDE disk does nicely for it. Where things get a bit sticky is: 1) That MS-DOS will quite happily deal with a 2 GiB FAT16 partition on the IDE drive (and even a second one above it), but BIOS can only address the first 1.3 GB of the IDE drive due to the interaction of the reported CHS geometry of the drive with the BIOS's CHS limits. Ideally, I'd like to do something like: 2GB FAT16 (DOS) -> Several GB FAT32 (Win98) -> Linux swap on the rest of the drive But I'm using Grub legacy (because I ran into trouble earlier on this machine getting Grub2 to boot both DOS 6 and Win95, I forget the exact details), and Grub legacy uses BIOS for disk access on the IDE disk (it deals quite happily with the SATA disk), so all the entry points for OSes on the IDE disk have to be below the 1.3 GB mark. This will mean some partition juggling. 2) Win98 drivers exist for the SATA card, so in principle, I should be able to install it in the existing Win95 FAT32 partition on the SATA disk, but the install environment is straight DOS and doesn't see the SATA disk, and while it gives a nice overview of the install process that includes loading drivers for hardware, that's *after* "install the OS to disk" and "reboot" steps (rather than the very first thing like any sensible OS installer). It even seems to struggle with anything other than a FAT16 CHS partition (FAT32 isn't visible, FAT16 LBA is visible but it screams when trying to actually access it). This may have to do with the install CD I chose, but unless different media presents me with more options, it looks like the existing partition on the SATA disk will only be usable as a data partition after the install is complete. Many old BIOSes already work fine for the first 128/137 GB if you have a LBA FAT32 DOS such as FreeDOS, EDR-DOS or Win98 DOS 7 :-) And as far as I have understood, he can boot either from onboard IDE (PATA) controllers or from his add-on SATA controller card. I'm able to boot from the SATA card if the IDE drive is on the secondary IDE channel, but not if it's on the primary channel. If the IDE drive is on the secondary channel, it's invisible to any sort of DOS (including FreeDOS, which sees all FAT partitions of any type on both drives if the IDE disk is on the primary channel). So the IDE drive has to be on the primary channel. This complicates boot a bit, but Grub can see and launch anything on either drive from either drive, so it just means that Grub has to be on the IDE drive. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] PCI SATA adapters with DOS
Continuing a conversation from back in March, I took Liam's suggestion of using a PCI SATA adapter. I ended up getting a card with a SiI3114 chipset. I actually got the card a while ago, but took my sweet time getting around to installing it. The good: The card is bootable, and with only a SATA drive on it the machine will boot Linux and FreeDOS. Linux will recognize both SATA and IDE drives in any combination and configuration. The bad: My configuration includes MS-DOS 6, which will not see any drives on the SATA card at all, so a mixed configuration is required, despite Liam's warnings. This does have consequences: The ugly: If the IDE drive is mounted on the secondary IDE channel, neither MS nor FreeDOS will see the IDE drive. If the IDE drive is mounted on the primary IDE channel, the SATA card is not bootable (the BIOS seems to try booting from the primary IDE channel and then gives up without passing boot off to the SATA card, so Grub has to be on the IDE disk), but at least both MS and FreeDOS will see the IDE disk. FreeDOS itself will still see the SATA disk. However, in this configuration FreeDOS fdisk claims to find no fixed disks. MS fdisk claims a bogus HDD size, so only Linux tools can be used to reliably partition the disk (despite giving dire warnings about messing with FAT volumes containing bootable MS-DOS systems). My configuration includes Win95 (though I can run most of what I'd run there on other machines, so it's not as critical). Win95 has no drivers for the SATA card (earliest drivers are WDM drivers, so Win98 at the earliest). Win98 is supposed to support the card, but its installer seems to run completely under DOS, and doesn't give an opportunity to load drivers before installing, so it only sees the IDE disk. Because of my BIOS's limitations in dealing with large drives, it will take some finagling of partition sizes and locations to allow both DOS 6 and Win98 to boot from the IDE disk whilst giving both a decent amount of space (though hopefully Win98 will be able to use a FAT32 partition on the SATA disk as a data/program disk once the drivers are installed). Still, despite everything under "the ugly", the most crucial elements of my configuration are up and running with a lot more space than they used to have. Jon Brase On 3/11/21 4:37 AM, Liam Proven wrote: I do not see any info about what the host machine is. If it is new enough to have PCI slots, then a SATA controller with a BIOS of its own should, in theory, bypass all this nightmare. Citation with model recommendations: https://www.vogons.org/viewtopic.php?t=62958 A firmware-equipped SATA controller (i.e. not some cheap thing that just adds additional ports and is not bootable) will appear to the PC as a SCSI controller and its firmware will take over the INT13 BIOS calls for disk access completely. If you do decide to go that route, though, I advise _against_ mixing SATA and EIDE/PATA disks. Let the SATA controllers' firmware take over completely and do not use the motherboard's EIDE channels at all. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Forwarding and commenting a FreeDOS 1.3rc3 critical review
On 4/29/21 4:57 PM, Jim Hall wrote: We could bolt on a graphical desktop environment onto FreeDOS, but the "graphical desktop" discussion never goes anywhere. Some people want *this* GUI and others want *that* GUI. We have three graphical desktops for FreeDOS: SEAL, oZone and OpenGEM. None are actively maintained, but OpenGEM is the most mature. When I demo'd SEAL and oZone for the YouTube channel, I found lots of bugs still present in both of these desktop environments. So I'd hesitate to promote either of those as "the one and only" FreeDOS graphical desktop. I'm not particularly attached to any particular GUI, or to having a GUI in FreeDOS per-se, but I'm a bit concerned, in terms of preserving historical software, that the Win16 API is not well served by existing options (Wine, NTVDM, MS-DOS/Win3 under virtualization, Win3 under DOSBox, etc), compared to the resources that are available for DOS, so I'd really like to see something I'll call "Free-point-one", a FOSS implementation of Win16 built on FreeDOS. I imagine that you probably regard it as out of scope for FreeDOS, and in any case it's late for such a project to get started, but given the history of the Win16 API, it's a very DOS-adjacent problem, if you know what I mean. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS was dead...
Apr 15, 2021 1:10:25 PM tom ehlert : >you probably meant 'OS architecture' (not CPU). Nope, I meant CPU. You start out with an unprotected CPU architecture like the 8086. The OS is basically just a set of hardware access libraries that applications can use or not as they wish (as they have direct access to the hardware). When a protected architecture like is the 386 is introduced (the 286, of course, didn't have a way of running 8086 code with protection enabled) it immediately opens up this can of worms, because back compatibility with applications that access the hardware directly often requires that they continue to be allowed hardware access, while system stability with multiple legacy OS instances running tends to demand that they not be allowed hardware access. So there is inevitably an incremental transition process, rather than an immediate snapover to a fully protected environment. The PC wasn't the only hardware platform and DOS wasn't the only OS that this happened to. Of course, talking about this process in the present tense, as if it's something that still happens today, may not be the best, as any unprotected architecture introduced with modern transistor budgets likely has a specific purpose like hard realtime and will never see a transition to a protected architecture, and any general-purpose architecture introduced today is almost certain to have memory protection. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS was dead...
>Apr 14, 2021 2:00:05 PM Ralf Quint : >And I stand by my comments that none of Windows 9x/ME is "running on DOS". I >don't have the time right now to provide the detailed proof for that, but just >look at the addresses of some of the DOS services before the booting of the >Windows 9x GUI and afterwards (in a DOS prompt). They will be decisively >different. You can install a TSR before the booting of Windows 9x GUI that >redirects some of the DOS vectors to produce some debug output and you will >not see that debug output when calling the same DOS vector while running under >Windows 9x. That was also the problem with some DOS drivers for some SCSI >adapters for example, which would not work under Windows 95, until the >manufacturer provided a proper Windows driver for it. I will note that Windows 95 *could* use DOS drivers. I/O performance suffered horribly since DOS drivers weren't thread safe, but there was a copy of DOS in the system VM for this purpose, even if it had nothing to do under normal circumstances. But to some degree this is a philosophical debate that will be present whenever you have a transition from a CPU architecture without protected memory to one with it and you move incrementally from a single-tasking OS to an environment where multiple instances of that single-tasking OS are virtualized alongside each other. At what point does your protected memory management software cease being an application running in top of the legacy OS and start being the actual OS? Is it the first software package that runs the legacy OS entirely in the architecture's equivalent to v86 mode, even if it remains single-tasking and falls back on the legacy OS for all hardware services except memory management? Is it the first software package that allows multi-tasking multiple instances of the legacy OS? Is it the first software package that prevents applications from accessing system memory? Is it the first software package that provides its own driver layer that bypasses the legacy OS? Is it the first software package that completely removes the ability for the legacy OS to access hardware at all? The two bit things I will point out / opine here are: 1) The software that has control of the machine is different (EMM386 vs VMM32) depending whether you load Windows or not on a Win95 system. 2) Whether you say it is running "on top" of DOS or not VMM32 is the product of an incremental evolution of the DOS ecosystem, not an OS built from the ground up like NT, so it to some degree makes sense to say that Win95 *is* DOS. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Using a USB stick and an optical drive
> Full spec of laptop here: https://www.comx-computers.co.za/laptop-specification-sheet.php?laptop=40065 The CPU is listed as a Pentium T4500, which is a processor from 2010-ish using the Penryn-L microarchitecture. Intel processors in that market segment didn't have virtualization support features until 2012/2013-ish with the introduction of the Ivy Bridge microarchitecture. So the likely reason that your BIOS does not have virtualization support is because your hardware just doesn't support it. That doesn't mean you can't use virtualization at all, but it does mean that what virtualization software you can use and what operating systems you can run under virtualization will be limited. For example, my old 2009-era Core 2 Duo laptop can't run 64-bit operating systems under virtualization, but VirtualBox can handle 32-bit OSes just fine. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Using a USB stick and an optical drive
> Is there a reason why no such almost trivial thing exists? both for windows and linux, less then 500 MB? Two reasons: 1) Because a standard system utility for disk imaging exists on Linux (or any other Unix-like, for that matter), which has been around since before Linux, or even DOS was around: dd 2) Because the interfaces that Windows and Unix provide to applications for raw disk access are different, so equivalent disk imaging programs will basically share no code, so few if any such programs on either system have had their developers bother to release a version for the other platform. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FSF?!
ry to stop this from happening, but alas the Linux kernel is still on version 2 so is not protected and we're in this situation where although the code is open and available under the GPL, it still can't be used. This probably has more to do with the attitude of the kernel team than with the GPL 2 vs 3. AFAIK, the GPL2, as intended by the FSF, *would* consider kernel modules to be derivative works of the kernel, and thus require them to be GPLed. I'm not sure of all of the intricacies here, legal or in the attitude of the kernel team, but if the kernel team wanted to enforce the GPL against such modules, they probably could (and the same attitude that makes them not want to enforce it against modules is also why they aren't moving to the GPLv3). The biggest loss I see in the kernel not being under GPLv3 isn't in proprietary modules being a thing, it's the fact that the anti-Tivoization clauses of the GPLv3 don't apply to the kernel. Frankly, my ideal copyleft license wouldn't necessarily even include a requirement to release sources. However, it would: 1) Require any derivatives have a license applied to whatever does get released. 2) Require that the end user be allowed to use the software, copy it, and redistribute it, as received without restriction. 3) Require that reverse-engineering of binaries be allowed (since we aren't requiring release of sources). 4) Require that if the software, or a derivative work, is cryptographically protected from modification, the owner of the device have ultimate control of the keys. 5) Specify that no attack on the software, or a derivative work, by the device owner in order to obtain control of a device that does not comply with 3 may be considered a circumvention of a technical protection measure under the DMCA (preferably written to cover similar laws in other countries as well). 6) Specify that nobody that creates a derivative work and distributes it may bring a copyright or patent action against any user or distributor of the original work, or any derivative, except to enforce the terms of the copyleft license. 7) Provide language like I used above for distinguishing between internal and external interfaces of a program, and excluding use of the external interfaces from creating a derived work. The author of a given bit of software could then fill those sections in with the actual interfaces covered. Jon Brase ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Raspberry Pi ISA card (was: networking/wifi)
> >> >>> Mar 20, 2021 7:29:45 PM Adam Nielsen via Freedos-user >>> : At any rate, the bit I'm stuck on is trying to find out how to get so many I/O pins from the ISA bus into the Pi. I am thinking it might have to be done with an FPGA as many of them have enough I/O pins to do it, then the question is how to get the relatively high bandwidth result across to the Pi, since GPIO probably won't cut it. I'm guessing you'd have to use either USB3 or the Pi's camera input, with USB3 probably being better documented and also more flexible since it could then allow you to connect the board to a normal PC and run all the software there if you didn't want to have a Pi sitting inside the DOS PC. There's a project called the "Unibone" that does this for the PDP-11 Unibus with a BeagleBone Black. http://www.retrocmp.com/projects/unibone The BBB has two real time coprocessors that handle high speed GPIO, which are used for interaction with the bus, and then Linux on the main processor does the user interaction and less time-critical heavy lifting. It can even drive the real bus with an emulated CPU running on the BBB. ISABone, anyone? ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/13/21 5:42 AM, Adam Nielsen via Freedos-user wrote: As I said before, I suspect what's happening is that the adapter is detecting something that the BIOS is doing while trying to figure out the capacity of the disk, and "helpfully" setting up an HPA on the drive (and doing so so aggressively that all but a thousandth of the capacity of the disk is lost). It wouldn't be a Host Protected Area (HPA) as that by definition is an area the host (PC) can't access under normal conditions. The thing is, an HPA can be either "permanent" or "temporary" (the former case is the default power-on capacity of the drive until the HPA is next resized, the latter lasts only as long as the drive remains powered). I suspect in this case that the adapter is detecting that the BIOS is struggling with the disk size, and "helpfully" setting up a very small HPA on the disk. Each time an the IDE standard was changed to work around a limitation, the standard dictated what to set in the "old" variables which typically were the maximum value possible. So if you plug in a 200 GB disk, a PC with a 504MB limit will see a 504MB disk, a system with a 137GB limit will see a 137GB disk, etc. So the device wouldn't have to do anything special to support an old BIOS. That is indeed what *should* be happening, but I don't think it is. 1) The BIOS in this machine has a 504 MB limit for manually configured drive geometries, but will autodetect some larger geometries (up to a limit I've not yet determined. Often a disk will be detected at something larger than 504 MB but smaller than 8GB, and for most disks, it's different, but generally smaller than the actual size of the drive). However, the autodetected size of the drive in question is only 130 MB. It might, however, have gotten these fixed values wrong. Since modern systems ignore all the obsolete capacity fields if newer ones are present, they wouldn't notice any mistake. But if your system is looking at one of the old capacity fields and seeing the wrong values, perhaps this is why. That could easily be the case for the BIOS, but past kernel version 2.5 Linux is supposed to ignore BIOS information and get the size of the disk directly from the disk. All the Linux kernels I've tried to boot are 2.6 kernels. And the kernel isn't subject to any of the old BIOS limitations, so when it asks the disk it should be asking for the newer capacity fields, and should be getting the full size of the disk. This is indeed what happens when the disk is plugged in to a machine with a newer BIOS. The same applies to OnTrack: it's entire reason for existence is to get disk size information from the disk directly and to intercept BIOS calls for access to large disks that the BIOS would mishandle. So there is no reason it should be seeing the same crippled total disk size that BIOS sees unless the disk (or the SATA adapter) is lying about the total size of the disk. Since this doesn't occur on a machine with a newer BIOS, I think that the adapter is picking up on something the old BIOS is doing and is trying to "help" by telling the drive to set a temporary HPA. Once that happens, the drive under-reports its size to software that can handle the actual size, and refuses reads/writes to LBA values in the HPA. I imagine a diagnostic program might be able to do some probing for IDE devices and show what values are reported by which fields. On a newer machine, hdparm shows CHS values totaling to 8 GB, and LBA values totaling to the correct size of the disk. On the machine in question, I haven't been able to get a Linux instance with hdparm available booted (the Debian installer CD I'm booting from doesn't have hdparm, and the Linux instance I'm trying to bring up on disk won't boot). These also bypass the BIOS and talk to the hardware directly. I used HWINFO to diagnose an issue on a PC once where a drive wasn't visible, and it turned out the PnP ICU I was using had moved the IDE port to the tertiary spot which the BIOS didn't support. So that one definitely bypasses the BIOS as it could see the drive on the 3rd IDE controller the BIOS didn't know about. The machine has 40 MiB of RAM installed. I notice that all three boards show a maximum capacity of 128 MiB of RAM. If I could ever find compatible RAM, that's a tempting option. Is it 72-pin RAM, in pairs? Most Pentium boards were. Although it's becoming less common, it still comes up pretty regularly on eBay where I am. Curious how you get to 40 MB if it's in pairs though as it's not a power of 2, unless it's 48 MB and the video adapter is stealing 8 MB for itself or something like that. One of my replies to Liam has some links to motherboards that are candidates to be the one in this machine, with the 40 MB configuration given as 4M * 36 on the first two banks and either 1M * 36 on the 3rd and 4th, or 2M * 36 on the third. Unless I buy an entirely new optical drive, that will at least stay on IDE, as all the SATA
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/12/21 2:59 PM, Eric Auer wrote: Hi Jon, actually I do not expect "drivers" like OnTrack, Ez Drive etc. to mess with host protected areas. It's not OnTrack that I think is messing with the HPA, it's the SATA <-> IDE adapter. Because when I boot from the OnTrack installation floppy, I find that the disk in question shows up with a reported *physical* (not paritioned) size of 130 MB. This is the same size that a Linux Live CD shows for the disk, even though the kernel version on the disk is recent enough that it only pays attention to what the disk tells it and completely ignores reported BIOS values. So I have two software packages (Linux and OnTrack) which are known to ignore the geometry that BIOS gives them and ask the disk directly (that's the entire *point* of OnTrack), and both of which are known to be able to handle disks (much) larger than 130 MB, and both are reporting the same bogus disk size as BIOS is giving (whereas Linux, at least, gives a correct size for the drive with the same adapter on a machine whose hardware and BIOS are about 5 years newer). My conclusion, then, is that some sort of pathological interaction between the BIOS and the adapter is happening that's causing the adapter to set an HPA on the drive, with the result that the drive reports a bogus capacity when Linux/Ontrack gets control of the machine and starts querying the drive for its size, and also refuses I/O to addresses beyond the HPA limit. Most likely, I think is that the adapter is seeing a certain pattern of ATA commands from the drive that indicates to it that the BIOS is having trouble with the size of the drive, and is "helpfully" setting an HPA to cripple the drive down to whatever it thinks the BIOS can handle (which turns out being less than the biggest drive geometry the user can manually set in BIOS, which is in turn less than the biggest geometry the BIOS can auto-detect). ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
Mar 12, 2021 7:30:03 PM Liam Proven : >Caveat: you might find that it only has enough tag RAM in its L2 cache to >cache 64MB of RAM. >This was quite common in early Pentium boxes. Finding tag RAM these days is... >unlikely, I suspect. I'm not holding my breath about finding RAM of any kind for this machine. >In my testing, adding more RAM past 64MB actually slowed down machines without >enough tag RAM. So that would probably slow it down under DOS/Win95, but under Linux total memory usage on the machine tends to be around 120 MiB, so an upgrade to 128 MiB would greatly reduce pressure on swap, which can only improve performance. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
Drat, sent my reply to Dennis only (again... :-/); resending to the whole list. On 3/10/21 5:31 PM, dmccunney wrote: I can't agree. We are not in the single-user, single tasking DOS days when one thing was going on at a time. At any moment, there are a number of things going on in a current consumer computer. Some of them will be OS routines, and some will be programs. Users may well start a program that will take time to do what it does (like compile code to create an executable,) push it into the background, and do other things in the foreground. Yes, but the point is that the user tends to have trouble finding enough for the machine to do. There may be an audio program so they can listen to music while they do things like work on code in an editor, or review documentation, and a download manager or a torrent client uploading/downloading in the background. While writing this e-mail with Rhythmbox playing in the background, my system load average has remained below 1, with significant amounts of time below 0.4. On a four-core machine, that means any given core is only spending 10%-25% of its time with a process scheduled. The human is the slowest component in the chain, but waiting for the human is *not* the only thing that machine will be doing. Not the only thing, but still the primary thing. I have occasionally started long running processes and gone to bed, assuming they would be domn in the morning. I'm out of the loop, but the machine is not in a wait state. It's still doing work. As have I. But most of the time I don't have such things for it to do. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/11/21 4:37 AM, Liam Proven wrote: Also, IIUC, you are trying to access _existing_ partitions? No, I do not think a disk manager will help you there. Disk managers bypass the BIOS restrictions by remapping or translating disks' real values, but they do not just fix the problem. Once you have a disk manager installed, I think you will need to create _new_ partitions after getting a DiskMgr working, using whatever translated scheme it creates. As far as I can tell, OnTrack partitions the disk as part of installing its translation scheme. So I have an existing disk, and took an image of each partition on it with partimage(1). I got my new SSD+adapter, partitioned it (with blank partitions), blasted the partition images to the new partitions, and expanded the filesystems to fill the partitions. And then ran into trouble with no more than the first 130 MB of the SSD showing up when booted in this machine (it's fine in another IDE machine that's ~5 years newer, which is the machine I used to do the imaging). Really, at least Linux *should* have been booting at that point, because kernel versions as recent as what I'm using are *supposed* to ignore the information that comes from the BIOS on drive sizes. So I beat my head against the wall trying to get that working, gave up, and decided to nuke everything to the ground and start over with OnTrack. Then it turned out that even OnTrack doesn't see more than the first 130 MB of the disk, which makes me really suspect that more than just BIOS is involved (as the entire point of OnTrack is to work around BIOS limitations). As I said before, I suspect what's happening is that the adapter is detecting something that the BIOS is doing while trying to figure out the capacity of the disk, and "helpfully" setting up an HPA on the drive (and doing so so aggressively that all but a thousandth of the capacity of the disk is lost). However, saying all that: I do not see any info about what the host machine is. The case is marked as an AST Bravo MS P/75. The information I can find on that online suggests it has one of the following two mainboards: A) https://stason.org/TULARC/pc/motherboards/A/AST-RESEARCH-INC-Pentium-BRAVO-MS-P-75-221478-F01.html B) https://stason.org/TULARC/pc/motherboards/A/AST-RESEARCH-INC-Pentium-BRAVO-MS-P75-202759-111-2.html However, the actual layout of the board in the case is more like this (given as Bravo MS/MS-T/MS-L): C) https://stason.org/TULARC/pc/motherboards/A/AST-RESEARCH-INC-Pentium-BRAVO-MS-MS-T-MS-L-PENTIU.html C), interestingly, is not supposed to run at 75 MHz (that page shows jumper settings for 60, 66, 90, and 100 MHz), but software running on the physical board (not the blueprint :-) ) detects the CPU as running at 75 MHz. The machine has 40 MiB of RAM installed. I notice that all three boards show a maximum capacity of 128 MiB of RAM. If I could ever find compatible RAM, that's a tempting option. It has a riser with 2 ISA slots and a PCI slot on the left side, and an ISA and a PCI on the right. The ISA slots on the left side are occupied with an ethernet card and a soundblaster. The PCI slot on the left looks like it may be fouled by the ethernet card, there's not a lot of space between it and the ISA slot above, and I'm not sure if I could actually fit a card into that slot without it coming into contact with the ethernet card. The slots on the right side are free. If it is new enough to have PCI slots, then a SATA controller with a BIOS of its own should, in theory, bypass all this nightmare. Citation with model recommendations: https://www.vogons.org/viewtopic.php?t=62958 A firmware-equipped SATA controller (i.e. not some cheap thing that just adds additional ports and is not bootable) will appear to the PC as a SCSI controller and its firmware will take over the INT13 BIOS calls for disk access completely. If you do decide to go that route, though, I advise _against_ mixing SATA and EIDE/PATA disks. Let the SATA controllers' firmware take over completely and do not use the motherboard's EIDE channels at all. Unless I buy an entirely new optical drive, that will at least stay on IDE, as all the SATA optical drives in the house are in use by other computers. OTOH, the prospect of actually being able to boot the thing directly from optical is enticing. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/9/21 4:35 PM, dmccunney wrote: As a general rule, consumer machines are I/O bound, not compute bound. The CPU spends most of its time in an idle loop waiting for stuff to be read from/written to disk. Actually, as a general rule, on a consumer machine, both the CPU and the disk spend most of their time waiting for user input to give them something to do. Disk waits are nothing compared to the eternity between the keystrokes of a fast typist, and that's if the user is neither away nor lost in thought. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/10/21 10:50 AM, dmccunney wrote: The fascinating bit for me is that the distinction between RAM and disk is steadily blurring. Things like nVME make it possible to have what works like RAM but is non-volatile storage whose content will survive a reboot. We are just scratching the surface here. I don't think this will make as much difference as people often think. Remember, we've been there before: Core memory was non-volatile, and some of the really early machines had drums for main memory, but systems that were born on architectures with storage that was 100% physically non-volatile still ended up with a distinction between logically volatile working memory and logically non-volatile long term storage, and were thus able to transition to volatile transistor RAM with minimum fuss. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
Accidentally responded to Liam instead of the whole list, resending. On 3/9/21 3:40 PM, Liam Proven wrote: On Tue, 9 Mar 2021 at 22:28, Jon Brase wrote: On 3/3/21 7:30 AM, Liam Proven wrote: Yes. Use a disk manager. It will install a tiny overlay before the OS boots and that will allow you to use arbitrarily-large disks without problems. (Probably not with Linux, but with DOS, Win9x, OS/2 and maybe even NT). Actually, it looks like, through kernel 2.5., Linux explicitly detected and worked with both OnTrack and EasyDrive. Since that version, it has a tunable offset parameter that can be set appropriately for either one by the user (63 sectors for OnTrack, 1 for EasyDrive). All other avenues seem to have failed, so I may well be going that route next. That is actually quite impressive! I did not know that. Thanks for the info. Once installed, it's a good, simple, easy solution. I used to use them a lot back in the day (late 1990s, roughly.) Unfortunately, it's not working. OnTrack sees the same ultra-small capacity for the drive as the BIOS and Linux see on that machine. It picks up the other 40 GB 2.5" PATA drive, but the SSD + Adapter can't be extended from what the BIOS sees to the actual size of the drive. I even tried a different SSD on the adapter, and got almost the exact same crippled size (130 MB), so I don't even get to test if Linux's offset parameter works, even OnTrack isn't seeing the full drive size. My working theory at this point is that the adapter is detecting that it's working wtih an old BIOS and "helpfully" setting up a temporary Host Protected Area on the drive, after which it refuses to acknowledge that any area after the 130 MB mark even exists until poweroff. I haven't been able to boot an environment that has hdparm(8) available, so I haven't been able to test this. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/3/21 7:30 AM, Liam Proven wrote: Yes. Use a disk manager. It will install a tiny overlay before the OS boots and that will allow you to use arbitrarily-large disks without problems. (Probably not with Linux, but with DOS, Win9x, OS/2 and maybe even NT). Actually, it looks like, through kernel 2.5., Linux explicitly detected and worked with both OnTrack and EasyDrive. Since that version, it has a tunable offset parameter that can be set appropriately for either one by the user (63 sectors for OnTrack, 1 for EasyDrive). All other avenues seem to have failed, so I may well be going that route next. Jon Brase ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
w big it is". In this case I'm not so confident of getting DOS and Win95 working without moving them over to what's supposed to be the swap drive, but at least Linux will be able to use the whole SSD once it starts questioning the BIOS value. Any ideas? Jon Brase ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Windows 95
>Going back to the original point, I remember finding it interesting how >if you booted Win9x natively it pretty much took over the environment >and DOS all but disappeared, however if you booted into MS-DOS mode and >then ran "win", DOS was still there in the background (just not being >used if you had all native Windows drivers). In that case when you >chose the option to shut down Windows, instead of getting the "It's now >safe to turn off your computer" screen, it would return you back to the >DOS prompt, just the way Win3.1 used to work. I believe the "it is now safe to turn off your computer" screen was actually just a DOS executable that ran after Windows exited if Windows had launched at boot, and I think what executable to run (or whether to just go to a DOS prompt) was configurable (not sure though, my Win3/Win95 retrocomputing box is disassembled at the moment). In any case Win9x was certainly a DOS-based system (though in more and more of a "grandfathers axe" or "ship of Theseus" sort of way as it evolved from 95 to 98 to ME). In 95, at the very least, Windows was launched from DOS whether by the user or at boot time, and real-mode DOS remained resident and continued to be called for various services, even if the hardware was completely driven by native Windows drivers. Aside from that, there remained a significant amount of Win16 code in the system, and the whole system, all the way up to Windows ME, was the result of incremental, kludge-by-kludge additions to DOS. Win9x was basically just DOS plus an overgrown DOS extender, even if by the end there was more extender and less DOS, it belonged solidly in the DOS family. Even Windows NT, though it shared the Win32 API with Win9x at the application level, was nothing like it at the kernel level. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Windows 95
Accidentally replied to Eric instead of the whole list, my apologies to him that he's receiving it twice: On 2/1/21 7:47 AM, Eric Auer wrote: If you have a few GHz of ARM speed, try DOSBIAN: https://cmaiolino.wordpress.com/dosbian/ Regards, Eric I'll note that DOSBIAN violates the GPL on DOSBox, and probably on Raspbian, too (I don't see stated anywhere that he's using Raspbian as a base, but it's almost certain that he is, given the name and platform). The developer asserts, falsely, that "Dosbian doesn’t contains any copyrighted material." (Untrue, DOSBox and Raspbian are copyrighted works licensed under the GPL). He then has: "Terms of use and distribution Dosbian is a donationware project, this means you can modify, improve, customise it as you like for your own use. IT IS STRICTLY PROHIBITED: USE DOSBIAN FOR COMMERCIAL PURPOSES. DIFFUSE YOUR OWN CUSTOMIZED COPY OF DOSBIAN." Locking the download behind a donation doesn't actually violate the GPL, but restricting commercial use or distribution of modified works does. That doesn't mean anything for users, due to the nature of the GPL, but it does mean that the developer is not himself legally in the clear. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
Dec 27, 2020 3:03:02 AM Frantisek Rysanek : > On 27 Dec 2020 at 6:42, Jon Brase wrote: > >> OK, if modern SATA gets 75, then 25 isn't too concerning. I was >> worried it might be more like an order of magnitude (or two) >> difference. >> > Um... note that real HDDs have a memory buffer, acting as a > write-back cache. Not sure how much RAM the CF cards have, > possibly a couple hundred kilobytes. > 10-15 years ago, not sure if 2 or 8 MB was the norm in spinning rust. Mostly my point is that the old PATA drive I'm replacing isn't going to outperform a modern drive, so if the random access performance of a modern drive is only 75 IOps / sec, then my old drive isn't going to outstrip the 25 that a CF card gets by too much, so hopefully I won't lose too much performance replacing the old drive with CF (unless a new CF card can be expected to have enough less cache than a 15-25 year old spinning rust drive to make a difference). But yeah, using a modern SATA drive with lots of cache is an intriguing idea. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
Dec 27, 2020 12:05:46 AM Frantisek Rysanek : > On 26 Dec 2020 at 22:40, Jon Brase wrote: >> > 40 MB of RAM in Windows95 - that's something I once had in a Pentium > 75 MHz :-) Possibly the same model of machine, given that both RAM and CPU match, and 40 MiB is a rather idiosyncratic amount of RAM (add opposed to a power of two). Mine's an AST, forget the exact model number and can't check right now. > > Linux on 40 MB of RAM... there was a time this was perfectly okay, > including a GUI. I believe something like RedHat 6.2 or Debian 3-4 > would fly on that setup. Currently it's running Debian 4, with a repository mirror served from my main desktop. I've run the numbers, and 6 should be able to run too, but it's actually the installer that constrains things. Debian 6 doesn't have drivers for older PATA stacks in the initrd for the install medium, and needs more memory than 40 MiB before it gets to the point in the installer where it can load additional drivers, so it can't mount swap early enough and fails to install. Debian 4 is able to recognize the HDD from the get-go, and can thus use swap to get around memory limitations. I think an in-place upgrade 4 -> 5 -> 6 should let me get Debian 6 onto the machine, and that project is planned after the migration to new storage. > I haven't seen a harddisk of that era for a decade or so, and I don't > recall testing one with hddtest - but based on the average seek times > quoted in the old days (12 to 16 ms), and based on the audio > impression I recall, I'd say that the hard drives of that era would > exceed 25 totally random IOps. Modern 7200rpm desktop SATA drives > during the last 15 years can typically achieve some 75 random IOps. > About 60 IOps for laptop drives. And those numbers do not grow > significantly during the years, with new disk drive generations. OK, if modern SATA gets 75, then 25 isn't too concerning. I was worried it might be more like an order of magnitude (or two) difference. > > and I'd like to say that you consistently respond in a way that makes > me believe that you know your trade, when it comes to partitioning > and the various size boundaries - you have my thumbs up :-) > Thanks! ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
Dec 26, 2020 3:47:44 PM Frantisek Rysanek : > I've noticed that you want to have about 4 times the swap space > compared to physical RAM. This means to me that your historical > machine is starved of RAM, and you envisage enhancing the volume of > RAM by a quick swap space. Hmm. > The actual success of that idea will depend on how large your typical > "DRAM working set" actually is. Actually I anticipate swap usage at about double physical RAM (for a total memory usage of 3x physical RAM). I'm using Debian to administer the machine (with DOS/Win95 for actual retrocomputing), and empirically that runs well (shell only) with that amount of swap (at least with the swap partition on a magnetic disk). If I start XFCE, then it starts thrashing, but I don't really need a graphical environment there. > It gets worse. If your machine thrashes the swap space intensively, > generating lots of those tiny write transactions, a typical CF card > will quickly get its relatively tiny transaction buffer (and "SLC > zone", if used) full of pending writes and will slow down noticeably > at the outer ATA interface. Don't be surprised to see 25 IOps or even > less, pauses lasting a couple seconds etc. A pretty far cry from > those ~4k IOps that you might come to expect, based on random read > performance. 25 IOps doesn't sound good. How does that compare to a similar I/O pattern on a late 90s/early 2000s magnetic disk? > > Try comparing your CF-based swap-on-flash solution with an > alternative setup, using some SATA-based SSD/CFast/mSATA > and a SATA/IDE converter. How about converting this all the way to a > small Optane drive :-) Those have like 6k of permitted overwrites, if > memory serves - and have really short latencies. Except that ehh... > they seem to be NVMe = PCI-e based, rather than SATA. Ahh well. Well, the absolute ideal for swap, if I could find it, would be an IDE device that used a couple GiB of modern DRAM and initialized itself at boot from some partitioning plan (for instance "1 Linux swap partition", or "1 Linux swap partition, 1 empty FAT partition"), or an image on a read only flash device. There's no need for a swap device to actually be non-volatile (beyond keeping formatting information for the OS to recognize it as a swap device), and DRAM doesn't have write limits. > I can't seem to find any figure, how much RAM your machine actually > has, just that you want 4 times that much in swap. As above, I'm not going for quite 4x RAM for swap, but the exact numbers in the current magnetic disk configuration are 40 MiB RAM, 80 MiB swap, and I plan to overprovision swap significantly on CF to spread out write wear. Part of what I'm trying to figure out is what kind of overprovisioning I'll need to get a decent lifetime for the swap device. > I actually wanted to say this: if you > only have use for maybe 1 GB of swap, it's no problem that your > partition can only be 2 GB, Actually only 512 MiB for anything DOS will be touching (or when BIOS first sees the drive), but that won't be a problem for the Linux swap partition once I've done the whole "trick the BIOS" dance. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
Dec 25, 2020 3:26:42 PM Frantisek Rysanek : > A) standard desktop Windows (XP or earlier) with swapping left operational, 1 > year of lifetime sounds about right. It sounds like you're using the card for the OS + swap, though, rather than having separate cards for the OS and swap. My plan is to separate them, and probably to overprovision the swap device significantly. Could people that are quoting lifetimes for CF cards used as swap provide the following information?: 1) Are you combining swap and file partitions on the same CF card? 2) What overprovisioning factor are you using (total device size divided by sum of typical runtime swap usage plus any files stored on the device)? 3) How deeply is the machine typically swapping (total memory usage including swap divided by available RAM) For the machine I'm considering, the answers are: 1) No 2) To be determined, based on answers I get here 3) About 3:1 > Though I cannot rule out that a particular BIOS would in fact inspect the > partition table and would not approve of partitions larger than some > arbitrary size :-) The BIOS for the machine in question does this whenever it sees a change in hardware on a given ATA connector. However, if you sneakily take the drive to another machine, change the partition table, and connect it back to the same ATA connector, it will happily use the drive with the new partition table. Win95 and Linux are then able to work with any over-sized partitions. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
>Remember FAT16 partitions are limited to 2GiB in MS/PC-DOS. >So, drives are limited to 8GiB. The BIOS on this machine doesn't like partitions outside of the first 512 MiB of the disk, so DOS is limited to 512 MiB per disk (but I'm able to run Linux and Win95 beyond that point). ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] IDE <-> CF adapters
>Regarding your Linux: On a modern computer, you probably want >to use a RAM filesystem for temporary files. But you say you >need a lot of swap, so this is probably no option for you. I >can predict that if your swap is on CF, your Linux will be at >least as slow as it was with a harddisk ;-) My primary goal is to future-proof the machine (as I anticipate CF to be available further into the future than IDE magnetic storage), a secondary goal that is fulfilled by the small size of CF cards is to fit multiple drives into the machine (there's only one free drive bay, but three free IDE connectors). I figure on a layout like this: Primary master: 512 MiB DOS partition, Win 95 above 512 MiB Primary slave: possible 512 MiB DOS partition, Linux home and root above 512 MiB, plus anything Unixy I feel like experimenting with. Secondary master: 512 MiB FAT partition for Win 3/9x page files, Linux swap above 512 MiB. Secondary slave: CD-ROM The 512 MiB partitions at the beginning of each disk are due to limitations in the machine's BIOS, which Linux and Win95 don't seem to be affected by (except that when the BIOS first sees a disk, all partitions must reside within the first 512 MiB, or the BIOS will refuse to use the disk. If the partition table is changed later, everything works fine as long as DOS isn't in a partition that hours beyond 512 MiB). I figure I'll have a dedicated drive for swap in order to: a) Not have swap competing with file I/O for reads/writes to the same disk. b) Minimize filesystem damage if the swap device busts its write lifetime. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] IDE <-> CF adapters
IDE <-> Compact Flash adapters seem to be popular for extending the life of old computing hardware, and I'm looking at replacing the magnetic disks on my old machines with CF. However, there seem to be issues with ensuring that the motherboard <-> adapter <-> CF card chain is all compatible. I presume that there are likely a fair number of people on this list that have already done this. Can anyone provide recommendations as far as manufacturers/devices to seek or avoid? Furthermore, I use Linux to administer my DOS machines (stuff like file transfers to the rest of the network), and on the older of the two, the Linux installation is quite swap-dependent. Obviously, the write-lifetime limitations of flash memory are a concern here. Would it be best to just buy a bunch of small CF cards and replace them as they die, or to get a few over-large CF cards and rely on the card firmware to do write levelling, or to just hold on to magnetic storage until I can't find any more drives? Lastly, are there any good solutions for mounting multiple CF adapters at the front of a 5.25" drive bay? Most of the adapters I've found that seem to be meant for external mounting seem to either be meant to fit in a rear PCI slot or to fit a single adapter at the front of a 3.5" bay, but it seems like the dimensions are such that most adapters could fit 2 wide x 2 high in a 5.25" bay if there were any way to mount them. Jon Brase ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Modern add-ons for ancient PC
One thing I'd really like to see is a single board computer that plugs into a USB and/or SATA cable on one end and a pair of PATA cables and a floppy cable on the other. You put a multi-terabyte hard drive or SSD (or several of them) at the USB/SATA end, and an old PC at the PATA end, then stuff the hard drive full of disk images. You then have software on the SBC that can receive ATAPI commands over the PATA cable to set which images get presented on the ATA and floppy cables, and some management software whatever operating systems you want to run on the PC that can issue those commands (or maybe a bootloader that can switch images). That way, if you're multi-booting, you don't have to worry about finding space to fit everything on an 8 GIB drive if one of your OSes (or your BIOS) can't handle anything larger: you just give each such OS its own 8 GiB image, which the SBC presents to the PC as a hard drive. I've seen similar floppy-only projects that allowed the user to select a floppy image on a USB stick with a pair of next image / previous image buttons, but never something on as grand a scale as described above, where the goal is to serve all of an old PC's storage interfaces with images stored on a single modern drive. Original message From: Michael Brutman Date: 10/2/2020 21:38 (GMT-06:00) To: "Discussion and general questions about FreeDOS." Subject: Re: [Freedos-user] Modern add-ons for ancient PC The retrocomputing crowd has a lot of these projects now, and they generally work. Most are based on open source designs so the quality will vary from vendor to vendor. The 8 bit IDE cards for example are based on a project called XT-IDE that I was part of back in 2008/2009. (See the genesis of the project at http://www.vcfed.org/forum/showthread.php?12359-8-Bit-IDE-Controller . The original version of the card had the traces optimized on my work laptop while it was idling.) If I were buying an XT-IDE I would be getting it from https://www.glitchwrks.com/xt-ide. I haven't purchased any of the recent variants; all mine are gen 1 from the first production run. And I've not tried out memory boards but they are generally known to work; they are not particularly complicated. Mike On Thu, Oct 1, 2020 at 4:34 AM Eric Auer wrote: Hi! Mentioned in a video mentioned by Rugxulo on BTTR, I noticed that there is a shop where you can get some circuit boards to do-it-yourself 8-bit ISA extension cards for your ancient computers for features such as more RAM, IDE or Compact Flash interfaces or even USB interfaces which are bootable. Interesting technical detail: They use EEPROMS which you can program without using a programmer, just with magic write sequences. Has anybody tried any of those products? Are they okay for the task at hand? Note that the shop usually has only the PCB, not the pre-built devices, so you have to get the components elsewhere and solder yourself in most cases. They also have a few ready to use products. https://www.lo-tech.co.uk/product-category/retro-ibm-pc/ Cheers, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
> Not that convincing rationale considering rather modest overhead necessary. Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS for modern machines (where you're really better off just using Linux and DOSBox), or for your early-90s 486 retrogaming machine, it's also meant to be an alternative to MS-DOS for the very oldest PC hardware, all the way back to the original IBM 5150. The core software might therefore be expected to work in very little RAM. As I recall, the minimum configuration for the 5150 had only 16k of RAM. A decent laptop these days will have more 16k blocks of RAM than a minimal 5150 had *bits* of RAM. So for FreeDOS to work on such machines, it has to treat kilobytes like young whippersnappers like me treat gigabytes. 500 or 800 bytes starts looking pretty expensive at that rate. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] 4DOS - license issue, not included in FreeDOS 1.3?
On 3/27/20 5:34 PM, Jim Hall wrote: As I said, I think 4DOS can fix it by removing term 2 from the license (and possibly term 3) since that's what makes the 4DOS license "not open source." Rex would need to agree to it, since both terms have Rex's name on them. An interesting idea would be to propose that JPSoft crowdfund an open-source release of 4NT. They name a price, if there's enough interest in the community to raise that money, they release it as open source. Once 4NT is open, the FreeDOS-only clause of the 4DOS license is no longer necessary. Of course, they might not be interested in such a thing, but it would probably go over better than a straight pitch of "could you please remove this license term?" with nothing offered. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Game sound
Bryan, Unfortunately, this is a difficult problem to solve. DOS didn't have a sound API: programs just twiddled with the sound hardware directly. The PC speaker was guaranteed to be present, and there was a good bet that any given PC used for games would have one of the big name sound cards such as Sound Blaster or Ad Lib present, so these provided a quasi-standard, but as Windows became more prevalent and more and more games were written with the expectation of running in a multitasking environment, they started using the Windows sound API instead, which would work with any sound hardware that there was a Windows driver for. So the standardization on sound-blaster et al. for sound hardware went away, and none of the hardware that old DOS games had used was available on newer systems, except the PC speaker. And the new hardware was so varied that people that were still writing DOS software (such as the FreeDOS project) couldn't really pick any one sound device that would work on more than a small fraction of new machines, except for the PC speaker. So for any machine more recent than 2000-ish, you won't get more than PC speaker sound. To change that, you'd need to design a sound driver API for DOS, and then you'd need to write a program that could intercept attempts to communicate with Sound Blaster hardware (or some other DOS-era sound card) and pretend to be a Sound Blaster card, and then call the sound API you'd designed to play the necessary sounds, and then you'd need to write a *huge* bunch of drivers that would accept calls to that sound API. More realistically, you probably wouldn't be able to write all the sound drivers you'd need for decent coverage of all the sound hardware ever used in a PC in the past 20 years, so you'd need to use existing drivers for some other operating system (likely Linux). The shim layer would need to, at a minimum, supply all the internal kernel functions used by all the sound drivers for whatever OS you were using as a driver source, and would also likely have to translate between your sound API and the sound API for that OS, unless you decided to just use that API as your DOS sound API. It's not impossible, but it would take a huge amount of work to get working. Jon Brase Original message From: Bryan Kilgallin Date: 1/19/2020 01:15 (GMT-06:00) To: freedos-user@lists.sourceforge.net Subject: [Freedos-user] Game sound I've installed FreeDOS in a 2003 Dell OptiPlex GX270 32-bit PC. The only sound is from the built-in speaker. So when I play hangman, the beeps, buzzes and tunes seem faintly distant. I'd like to cable the motherboard's AC'97 sound, into an external amplifier and so to speakers on my desk! I've skimmed the source file HANGMAN.BAS. But I didn't recognise anywhere to tweak sound output. AUTOEXEC.BAT is in C\ and C\FDOS\. I've edited both as follows. SET BLASTER=A220 I5 D1 T3 H6 -- members.iinet.net.au/~kilgallin/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Freedos 1.2 move, copy & xcopy
To expand on why CHKDSK itself can't deal with FAT32, Freedos tries to retain compatibility with quite a broad range of hardware, including both any 8086 machines that anybody still has lying around, and modern hardware. So CHKDSK has to be able to be able to work on 8086s. This means that it can't depend on the availability of anything more than 640k of conventional RAM, which makes it difficult to deal with FAT32, and such machines are unlikely to have disks big enough to need FAT32 anyway. Thus there is a separate tool, ported from Linux, to deal with FAT32 on beefier machines (i.e, most hardware released since 1990 or so). Microsoft didn't have this constraint when they released FAT32 with Win95, as they'd already determined that Win95 would not run on machines that old, so MS CHKDSK has been able to deal with FAT32 since it was released.___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Freedos 1.2 move, copy & xcopy
copy on MS-DOS wasn't really meant for copying more than one file at a time (which is why xcopy exists), and FreeDOS uses the same command line syntax. Copy only accepts one destination file and treats all other filenames on the command line as sources. Also, the form new\*.* will expand to all the filenames *already in new*, if any, so even if copy did take multiple destinations, throwing in new\*.* for the destination would give you the results you expect (it would overwrite existing files in new with copies of the source files). Long story short, Microsoft meant for you to use xcopy for what you're trying to do back in the day, and FreeDOS is no different. Original message From: Dale E Sterner Date: 11/12/2019 10:38 (GMT-06:00) To: freedos-user@lists.sourceforge.net Subject: Re: [Freedos-user] Freedos 1.2 move, copy & xcopy I tried to move post.mp4 - a 3.5.meg file. - got insufficient memory error with move, copy & xcopy. The copy command sometimes has trouble with wildcard "*". I tried copy *.* new\*.* It copied only one file then stopped,. xcopy worked. The edit command has limits on size; had to use Wordperfect on one file. In 2015 Dennis talked about using vedit but can't find a dos version. In the new world large files are common. cheers DS ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS and Samba
SMB1 has known vulnerabilities, so Windows has had the option to disable SMB 1 entirely for a while and on the Linux side, upstream SAMBA recently changed to disabling it by default. It is possible that various distros may already have disabled it in their default SAMBA configurations. Original message From: David Griffith Date: 10/13/2019 08:23 (GMT-06:00) To: freedos-user@lists.sourceforge.net Subject: [Freedos-user] FreeDOS and Samba What am I doing wrong with FreeDOS and mounting a Samba file share? I have a Virtualbox image I found at https://www.lazybrowndog.net/freedos/virtualbox/?page_id=33 which seems to have everything ready for networking. I have Samba installed on the host Linux machine. From the host I can mount the share, but not entirely on FreeDOS. The best I can manage is read-only access if the "valid users" parameter (below) is removed. I managed to get this to work a few years ago and recall that the solution has something to do with using SMB protocol 1. None of the guides I find now for mounting a share from FreeDOS mention this and Samba now seems unwilling to admit it knows anything about SMB1. Here's what I have for the share in /etc/smb.conf: [Dave] comment = Dave's stuff path = /home/dave/foobar read only = no guest ok = yes browsable = yes writable = yes valid users = dave -- David Griffith d...@661.org A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Source code to Windows 9x and ME...
I'm not aware that Microsoft has put Windows 1 or 2 on Github yet. They have put DOS 1 and 2 on Github. As for Windows components, they have Winfile on Github, as well as the old Windows console and the new terminal they just released. All of these are made available under the MIT license, so obviously Microsoft thinks it's in their interest to open source at least some parts of some versions of Windows, or they wouldn't have already done so. Original message From: Ralf Quint Date: 9/26/2019 17:39 (GMT-06:00) To: freedos-user@lists.sourceforge.net Subject: Re: [Freedos-user] Source code to Windows 9x and ME... On 9/26/2019 6:35 AM, Michael C Robinson wrote: > Is it possible to get the source code to Windows 9x and ME since > Microsoft isn't supporting it anymore? No. > One would want to get the source code and then open source it of > course. Even Windows 3.1 and Windows 3.11 is closed source. Surely, > Microsoft could release pre 9x Windows? It wouldn't hurt Microsoft at > all since Windows > is squarely NT based now where many modern systems won't even support > DOS let alone DOS based Windows. I realize it would probably be very > expensive to get Microsoft to cough up the source code, but has anyone > even looked into this? Sounds rather idealistic and void of any facts. Microsoft has not interest to open source ANY part of ANY windows. Even Windows 1.x and 2.x, which are on GitHub now, are still copyrighted. So it all comes down to "you can look but you can't touch", which as far as FreeDOS is concerned (for which any Windows source code be irrelevant to begin with) would be of no interest... Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Source code to Windows 9x and ME...
As far as DOS being out of the loop, I was young and not yet interested in the technical details when Win9x (including ME) was still a going concern, but my understanding in more recent years as to why Win9x was so unstable has been that whether or not DOS proper was in control of the system, there was still data and code down in conventional memory that would cause windows to crash if it was scribbled over, and that data was mapped in the lower megabyte of every process, even Win32 processes, so that a buggy application could nuke the whole system. From what I understand, Win9x was basically a Win16 implementation (including a DPMI server) and Win32 was basically implemented as a DPMI client TSR that provided the Win32 API to applications, and then called the Win16 API as the actual backend to draw stuff on screen (thus the GDI heap exhaustion problem). Is that more or less correct? As for the worth of having Win16 vs Win9x as a whole open sourced, I agree. Win16 was quite a pile of crap itself, but there aren't a lot of options available for running applications that were only released for that platform available today. Both NTVDM and Wine have so-so implementations of it, and it would be good to have a source release of original Microsoft code that dedicated retrocomputing projects could use to create their own modern implementations. But there are implementations of Win32 under active development today that are of much higher quality than what Win9x provided, both proprietary (Win10), and open source (Wine), so open sourcing Win9x in its entirety is a very low priority. Open sourcing the Win16 implementation in Win9x might be worthwhile just to have a broad spectrum of Win16 implementations (Win3, Win9x, NTVDM) for retrocomputing projects to use as example code, but FreeDOS provides a better DOS implementation than Win9x does, and Win10 and Wine provide better Win32 implementations. Original message From: dmccunney Date: 9/26/2019 11:14 (GMT-06:00) To: "Discussion and general questions about FreeDOS." Subject: Re: [Freedos-user] Source code to Windows 9x and ME... On Thu, Sep 26, 2019 at 11:22 AM Michael C Robinson wrote: > > I don't have a few million, but a group able to cobble together a few > million is more realistic to put together. Where "realistic" is "extremely unlikely" instead of "totally impossible" > Question is, how much would membership cost in a group whose goal is > to GPL Windows 16 and 32 bit be? Say such a group came into existence > and a million people joined for $20/month. Can you get $DEITY to work a miracle to get those million folks to sign up? That's about what would be required. > The first target, Windows > 16 bit land. Then, the 32 bit version of Windows including 9x and ME. > Eventually, the group would be able to open source the MS-DOS based > versions of Windows completely and membership fees could be reduced or > even dropped. Maybe the source code isn't needed, maybe just the > interfaces and the design are needed. Win3.X->Win9X were multitasking shells running on top of DOS. But the need for DOS decreased as development continued. By the time Win98 hit the streets, DOS was a real mode loader for Win98, and once Win98 was running, DOS was out of the loop. Win98 was the OS, and it handled things like accessing the file system DOS was previously used for. Speaking as someone who had to support Win9X in the workplace, and spent *way* too much time beating it into submission, I was *delighted* when Win2k arrived and I could run an N T version of Windows with NTFS as the file system. My Win2K machine was up 24/7 and Just Ran. I only rebooted if I was fiddling with hardware or installing something that required it. My last Win98SE installation reached the point where I was rebooting four or five times a day, and this is *with* me doing my best to keep a clean uncluttered installation. The problem was resources. Microsoft allocated them as part of the GDI heap, and they held stuff like what was displayed on your screen. But the amount allocated was fixed - in Win3.X is was two 64K heaps. In Win9X it was one 128K heap, This was true no matter how much RAM you had installed. Programs would allocate resources when they ran but not always free them whrn they exited. (Microsoff Excel was a Worst Offender about this.) When Windows thought resources were exhausted, a reboot was required. I wouldn't mind an environment that supported old 16bit stuff from in3.X. There really isn't anything I can think of from Win9X I care about. I'm afraid I wouldn't join the crowdfunding effort. My response to Win9X these days is "Run Away! Run Away!" __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list
Re: [Freedos-user] Source code to Windows 9x and ME...
If I were to ask Microsoft nicely about open sourcing their code, I'd suggest that they calculate what it will likely cost them (buying rights for externally licensed code, erasing embarrassing comments, trying to find copies of missing code, etc.) and then crowdfund that. It wouldn't so much be a matter of setting up a group in which people would purchase membership as of Microsoft naming a price and setting up a Kickstarter campaign (or similar), and then people giving what they were willing, with there hopefully being enough people willing to give a high enough average amount to meet the named price. But as someone said upthread, finding someone properly placed to advocate for such a thing internally would likely be very helpful in such an effort. Original message From: Michael C Robinson Date: 9/26/2019 10:20 (GMT-06:00) To: "Discussion and general questions about FreeDOS." Subject: Re: [Freedos-user] Source code to Windows 9x and ME... I don't have a few million, but a group able to cobble together a few million is more realistic to put together. Question is, how much would membership cost in a group whose goal is to GPL Windows 16 and 32 bit be? Say such a group came into existence and a million people joined for $20/month. The first target, Windows 16 bit land. Then, the 32 bit version of Windows including 9x and ME. Eventually, the group would be able to open source the MS-DOS based versions of Windows completely and membership fees could be reduced or even dropped. Maybe the source code isn't needed, maybe just the interfaces and the design are needed. Quoting Jon Brase : > If you can cut a check for a few million, Microsoft might sell you > the rights (to the components that they created themselves, of > course, not anything they licensed from others), give you whatever > source code they still have archived, and let you license it to the > public as you choose. > If you can't cut a check, but ask nicely, they have been open > sourcing things that nobody ever thought they'd open source, so > maybe they will eventually open-source Win9x. Frankly, though, I'd > rather concentrate on getting them to just release all their old > Win16 code (Win3, the Win16 components of Win9x, and NTVDM): that's > the part of the PC ecosystem where vintage applications are in most > danger of being lost because nobody has an environment to run them > on anymore: DOS is fairly well covered by DOSBox, FreeDOS, etc, and > Win32 is still an environment that Microsoft maintains, that people > actively write applications for, and that the Wine project is > putting a fair bit of effort into implementing well. Win16, on the > other hand, is somewhat neglected by both MS and Wine, and it would > be good if the old MS source code could be released, or, failing > that, the binaries could at least be put under an open-source > license that explicitly allowed reverse engineering. > > Original message > From: Michael C Robinson > Date: 9/26/2019 08:35 (GMT-06:00) > To: p...@lists.pdxlinux.org > Cc: freedos-user@lists.sourceforge.net > Subject: [Freedos-user] Source code to Windows 9x and ME... > > Is it possible to get the source code to Windows 9x and ME since > Microsoft isn't supporting it anymore? > One would want to get the source code and then open source it of > course. Even Windows 3.1 and Windows 3.11 is closed source. Surely, > Microsoft could release pre 9x Windows? It wouldn't hurt Microsoft at > all since Windows > is squarely NT based now where many modern systems won't even support > DOS let alone DOS based Windows. I realize it would probably be very > expensive to get Microsoft to cough up the source code, but has anyone > even looked into this? > > > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Source code to Windows 9x and ME...
From their recent behavior, I think it's quite likely that there is at least a faction within the company that thinks the hassle is worth it, and that is quite possibly the settled internal doctrine of the company. From what I've heard about Microsoft's revenue from Windows, they are mostly making money off of enterprise support contracts, much like Red Hat does with THE (though unlike Red Hat, I think that they arrived in that position more or less accidentally), so given the bad reputation they acquired in their early years, I think they're finding it advantageous to move towards an open-source business model to shore up their reputation. That doesn't mean they're going to just up and open source all the things tomorrow, of course, but I think in the future we can expect to see more releases of old code, and I think it's quite likely that at some point in the medium term they may very well do one or more of the following: 1) Open source the NT kernel2) Open source their Win32 implementation3) Transition Windows to using the Linux kernel by one of the following methods (compare the way that Novell transitioned away from the Netware kernel):3a) Making significant donations of code to the Wine project, then announcing a version of Windows with the option to either use NT/WSL or Linux/Wine to provide a combined Win32/Unix API.3b) Developing a proprietary implementation of Win32 that runs on top of Linux and announcing a version of Windows that presents the option to either use NT/WSL or Linux/"LSW". Before you laugh too hard at option 3, bear in mind that MS is really the only holdout in the industry using their own kernel API rather than a Unix implementation. Every other OS in common use, even if its middleware is proprietary (MacOS, Android/Google Play), uses some sort of *nix kernel. Furthermore, Win32 was designed with portability across radically different kernels in mind (DOS vs NT), so the transition to running on top of Linux would not be an especially difficult one (and has already been implemented in Wine) . So even if MS's overtures toward open source are just fig leaves for PR rather than an actual change in philosophy, I think the chance of a transition to an open *nix kernel is fairly significant. In 10 or 15 years, it may well be that the standard application environment will be Win32/Linux rather than Win32/NT or Gnu/X/Linux. Original message From: R Moog Date: 9/26/2019 09:23 (GMT-06:00) To: "Discussion and general questions about FreeDOS." Subject: Re: [Freedos-user] Source code to Windows 9x and ME... There is another way but it's still a hassle for MS. Ask them nicely. If they decide to follow up on the request then the ball is in their court to make it happen. czw., 26 wrz 2019, 16:15 użytkownik R Moog napisał: Rather* grim. I hate autocorrect. czw., 26 wrz 2019, 16:15 użytkownik R Moog napisał: I agree but here's a reality check. The outlook is father grim and we won't live until the copyright expires. From copyright.gov, works created after 1978 have their copyright expired 70 years after the death of its author. In case of Windows ME, we're looking at all the devs croaking, Microsoft dissolving and then 70 years of waiting unless we're in for a near future apocalypse scenario. Amiga scene pretty much showcases the nightmarish hellscape of copyright law. There is always someone somewhere out there that owns a piece of the whole thing and will sue for lulz. czw., 26 wrz 2019, 16:04 użytkownik Michael C Robinson napisał: Quoting andrew fabbro : > On Thu, Sep 26, 2019 at 6:36 AM Michael C Robinson < > mich...@robinson-west.com> wrote: > >> Is it possible to get the source code to Windows 9x and ME since >> Microsoft isn't supporting it anymore? >> One would want to get the source code and then open source it of >> course. Even Windows 3.1 and Windows 3.11 is closed source. Surely, >> Microsoft could release pre 9x Windows? It wouldn't hurt Microsoft at >> all since Windows >> is squarely NT based now where many modern systems won't even support >> DOS let alone DOS based Windows. I realize it would probably be very >> expensive to get Microsoft to cough up the source code, but has anyone >> even looked into this? >> > > "It wouldn't hurt Microsoft" is not exactly a true statement. > > Major reasons MSFT won't be releasing source code like that: > > (1) Some components are still in use. Microsoft does not rewrite their OS > from scratch with each new version and while Windows 10 is very different > than Windows Me, it's still an x86 OS. > > (2) There may be pieces they licensed or are under others' copyrights. > Sorting that out is non-trivial. This is true especially of things like > drivers. > > (3) Source code often reveals the inner workings of companies and > products. It's not unusual to see things like "we put this in because our > other product has a bug and we have to
Re: [Freedos-user] Source code to Windows 9x and ME...
If you can cut a check for a few million, Microsoft might sell you the rights (to the components that they created themselves, of course, not anything they licensed from others), give you whatever source code they still have archived, and let you license it to the public as you choose. If you can't cut a check, but ask nicely, they have been open sourcing things that nobody ever thought they'd open source, so maybe they will eventually open-source Win9x. Frankly, though, I'd rather concentrate on getting them to just release all their old Win16 code (Win3, the Win16 components of Win9x, and NTVDM): that's the part of the PC ecosystem where vintage applications are in most danger of being lost because nobody has an environment to run them on anymore: DOS is fairly well covered by DOSBox, FreeDOS, etc, and Win32 is still an environment that Microsoft maintains, that people actively write applications for, and that the Wine project is putting a fair bit of effort into implementing well. Win16, on the other hand, is somewhat neglected by both MS and Wine, and it would be good if the old MS source code could be released, or, failing that, the binaries could at least be put under an open-source license that explicitly allowed reverse engineering. Original message From: Michael C Robinson Date: 9/26/2019 08:35 (GMT-06:00) To: p...@lists.pdxlinux.org Cc: freedos-user@lists.sourceforge.net Subject: [Freedos-user] Source code to Windows 9x and ME... Is it possible to get the source code to Windows 9x and ME since Microsoft isn't supporting it anymore? One would want to get the source code and then open source it of course. Even Windows 3.1 and Windows 3.11 is closed source. Surely, Microsoft could release pre 9x Windows? It wouldn't hurt Microsoft at all since Windows is squarely NT based now where many modern systems won't even support DOS let alone DOS based Windows. I realize it would probably be very expensive to get Microsoft to cough up the source code, but has anyone even looked into this? ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Source code to Windows 9x and ME...
Microsoft *has* released the entirety of early versions of DOS under (IIRC) the MIT license, as well as (IIRC) the old Win3 file manager, and has in recent years been much friendlier to Open Source than in the past. As to where the money is in open sourcing old code, I think part of it is the advantages that a good reputation creates with regards to, for example, hiring good talent. With regards to your item (1), old components may still be in use, but are unlikely to be the "secret sauce" that makes Windows a better buy than its competitors at this stage. (2), I think is probably the biggest thing blocking the release of old code. Original message From: andrew fabbro Date: 9/26/2019 08:52 (GMT-06:00) To: "Discussion and general questions about FreeDOS." Cc: p...@lists.pdxlinux.org Subject: Re: [Freedos-user] Source code to Windows 9x and ME... On Thu, Sep 26, 2019 at 6:36 AM Michael C Robinson wrote: Is it possible to get the source code to Windows 9x and ME since Microsoft isn't supporting it anymore? One would want to get the source code and then open source it of course. Even Windows 3.1 and Windows 3.11 is closed source. Surely, Microsoft could release pre 9x Windows? It wouldn't hurt Microsoft at all since Windows is squarely NT based now where many modern systems won't even support DOS let alone DOS based Windows. I realize it would probably be very expensive to get Microsoft to cough up the source code, but has anyone even looked into this? "It wouldn't hurt Microsoft" is not exactly a true statement. Major reasons MSFT won't be releasing source code like that: (1) Some components are still in use. Microsoft does not rewrite their OS from scratch with each new version and while Windows 10 is very different than Windows Me, it's still an x86 OS. (2) There may be pieces they licensed or are under others' copyrights. Sorting that out is non-trivial. This is true especially of things like drivers. (3) Source code often reveals the inner workings of companies and products. It's not unusual to see things like "we put this in because our other product has a bug and we have to compensate" and comments like that. Not to mention profanity :-) (4) Many times old source code hides other embarrassing (or semi-embarrassing) secrets. There was a leak of Windows 2000 many years ago and I read that it had comments such as "(some app) breaks here so we put in this workaround to maintain compatibility with previous versions". This would inevitably lead to all kinds of press about favoring different vendors, etc. (5) And the big one...where's the money in releasing old source code? It takes lawyers, tech people, etc. and likely would cost a fair amount of money just to package it up. BTW, Microsoft has (or at least at one time had) various programs where universities had access to the source code, but that was under NDA. -- andrew fabbroand...@fabbro.org ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3
I take it that your Ubuntu box is an x86 PC? If that is the case, the issue is very likely with QEMU's x86 emulation. On an x86, QEMU is able to use the host CPU to execute x86 instructions, so the emulation layer is only needed for a few instructions that do things that might allow the guest OS to inadvertently or deliberately mess with the host OS's data. On ARM, or any other non-x86 architecture, QEMU has to emulate the full instruction set. This is likely why you're seeing a difference between your Ubuntu box and your Pi. As such, it might be good to file a bug with QEMU. Original message From: shift83...@gmail.com Date: 9/25/2019 18:15 (GMT-06:00) To: "'Discussion and general questions about FreeDOS.'" Subject: Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 The work-around I have found is to set the image up on my Linux Ubunto 18.04 box then transfer the image file over to the raspberry pi. I even tried using the FreeDOS 1.3 RC1 installer with the same results on the Raspberry Pi 3. Both installer ISO’s worked with no issue on the Ubuntu. Next I will be trying a different SD card. From: Jon Brase Sent: Wednesday, September 25, 2019 12:29 AM To: Discussion and general questions about FreeDOS. Subject: Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 I managed to get the installer to pull packages off the CD, but one thing you may be running into is that QEMU de-assigns ISO images from the emulated CD drive when the OS sends a disk eject command. On a physical machine, if the CD drive ejects a disk you're still using, you notice it and just push the tray back in, but in a VM it's a rather annoying behavior for the ISO to be completely unassigned, as you don't see that happen, and on reboot it causes the disk to no longer be in the drive. When you start the VM fresh with the CD image and freshly formatted HDD image specified, do you get the same error? Original message ---- From: Jon Brase Date: 9/25/2019 00:02 (GMT-06:00) To: "Discussion and general questions about FreeDOS." Subject: Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 Interesting, I did have a similar issue on real hardware recently, though the situation was enough different that I'm not sure whether they match up, and I didn't so much resolve it as work around it. I generally use virt-manager rather than the command line to set up QEMU VMs. I'm not sure what QEMU defaults to on the command line for things that aren't specified (details of how the emulated hardware is presented to the guest OS and such). I may try installing FreeDOS in a VM on my machine to see if I can duplicate the issue there. Original message From: shift83...@gmail.com Date: 9/24/2019 23:21 (GMT-06:00) To: "'Discussion and general questions about FreeDOS.'" Subject: Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 Sorry for the confusion. I’m new to QEMU. So… I created the image with the below command: qemu-img create dos.img 200M This is my command line to execute QEMU and mount the drives and emulate devices is below: qemu-system-i386 -m 16 -k en-us -rtc base=localtime -device cirrus-vga -fda FLOPPY.img -hda freedos.img -cdrom FD12CD.iso -boot order=d I have also tried to minimize the command to just: qemu-system-i386 -fda FLOPPY.img -had freedos.img -cdrom FD12CD.iso -boot order=d I believe the issue is that after it reboots from partitioning and formatting the C drive it no longer sees the CDROM when trying to access the source packages. I issues trying to list the directory on the D drive when I exit from the installer. From: Jon Brase Sent: Tuesday, September 24, 2019 11:09 PM To: Discussion and general questions about FreeDOS. Subject: Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 FreeDOS (x86 software) won't boot (natively) on the Raspberry Pi 3 (ARM hardware), so if you got as far as to be able to select "install to hard disk", you must be using an x86 emulator, and, indeed, your screenshot shows that you're using QEMU. To minimize confusion, you should lead with the information that you're using QEMU, and follow it up with the fact that you're on a non x86 platform, as there are differences in how QEMU handles guest code for the same architecture that it's running on and how it handles code for other architectures. I myself haven't run FreeDOS on any platform other than x86 PCs, so I'm not sure how much help I can be, but can you say what emulated peripherals you set up for your FreeDOS VM in QEMU? Original message From: shift83...@gmail.com Date: 9/24/2019 22:15 (GMT-06:00) To: freedos-user@lists.sourceforge.net Subject: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 I have tried multiple times to install FreeDOS on Raspberry Pi3. I have created a 100M and 200M raw disk im
Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3
I managed to get the installer to pull packages off the CD, but one thing you may be running into is that QEMU de-assigns ISO images from the emulated CD drive when the OS sends a disk eject command. On a physical machine, if the CD drive ejects a disk you're still using, you notice it and just push the tray back in, but in a VM it's a rather annoying behavior for the ISO to be completely unassigned, as you don't see that happen, and on reboot it causes the disk to no longer be in the drive. When you start the VM fresh with the CD image and freshly formatted HDD image specified, do you get the same error? Original message From: Jon Brase Date: 9/25/2019 00:02 (GMT-06:00) To: "Discussion and general questions about FreeDOS." Subject: Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 Interesting, I did have a similar issue on real hardware recently, though the situation was enough different that I'm not sure whether they match up, and I didn't so much resolve it as work around it. I generally use virt-manager rather than the command line to set up QEMU VMs. I'm not sure what QEMU defaults to on the command line for things that aren't specified (details of how the emulated hardware is presented to the guest OS and such). I may try installing FreeDOS in a VM on my machine to see if I can duplicate the issue there. Original message From: shift83...@gmail.com Date: 9/24/2019 23:21 (GMT-06:00) To: "'Discussion and general questions about FreeDOS.'" Subject: Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 Sorry for the confusion. I’m new to QEMU. So… I created the image with the below command: qemu-img create dos.img 200M This is my command line to execute QEMU and mount the drives and emulate devices is below: qemu-system-i386 -m 16 -k en-us -rtc base=localtime -device cirrus-vga -fda FLOPPY.img -hda freedos.img -cdrom FD12CD.iso -boot order=d I have also tried to minimize the command to just: qemu-system-i386 -fda FLOPPY.img -had freedos.img -cdrom FD12CD.iso -boot order=d I believe the issue is that after it reboots from partitioning and formatting the C drive it no longer sees the CDROM when trying to access the source packages. I issues trying to list the directory on the D drive when I exit from the installer. From: Jon Brase Sent: Tuesday, September 24, 2019 11:09 PM To: Discussion and general questions about FreeDOS. Subject: Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 FreeDOS (x86 software) won't boot (natively) on the Raspberry Pi 3 (ARM hardware), so if you got as far as to be able to select "install to hard disk", you must be using an x86 emulator, and, indeed, your screenshot shows that you're using QEMU. To minimize confusion, you should lead with the information that you're using QEMU, and follow it up with the fact that you're on a non x86 platform, as there are differences in how QEMU handles guest code for the same architecture that it's running on and how it handles code for other architectures. I myself haven't run FreeDOS on any platform other than x86 PCs, so I'm not sure how much help I can be, but can you say what emulated peripherals you set up for your FreeDOS VM in QEMU? Original message From: shift83...@gmail.com Date: 9/24/2019 22:15 (GMT-06:00) To: freedos-user@lists.sourceforge.net Subject: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 I have tried multiple times to install FreeDOS on Raspberry Pi3. I have created a 100M and 200M raw disk image. Mounted the Standard and then tried with the Legacy ISO. Both will boot the ISO, partition and format the hard disk. But when I reboot and select the Install to Harddisk after it goes to gathering settings a couple of minutes go by and I get: I have also tried to mount the floppy.img as well as the ISO and boot from floppy with the same results. Has anyone seen this and been able to resolve it? Thank you, Chris ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3
Interesting, I did have a similar issue on real hardware recently, though the situation was enough different that I'm not sure whether they match up, and I didn't so much resolve it as work around it. I generally use virt-manager rather than the command line to set up QEMU VMs. I'm not sure what QEMU defaults to on the command line for things that aren't specified (details of how the emulated hardware is presented to the guest OS and such). I may try installing FreeDOS in a VM on my machine to see if I can duplicate the issue there. Original message From: shift83...@gmail.com Date: 9/24/2019 23:21 (GMT-06:00) To: "'Discussion and general questions about FreeDOS.'" Subject: Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 Sorry for the confusion. I’m new to QEMU. So… I created the image with the below command: qemu-img create dos.img 200M This is my command line to execute QEMU and mount the drives and emulate devices is below: qemu-system-i386 -m 16 -k en-us -rtc base=localtime -device cirrus-vga -fda FLOPPY.img -hda freedos.img -cdrom FD12CD.iso -boot order=d I have also tried to minimize the command to just: qemu-system-i386 -fda FLOPPY.img -had freedos.img -cdrom FD12CD.iso -boot order=d I believe the issue is that after it reboots from partitioning and formatting the C drive it no longer sees the CDROM when trying to access the source packages. I issues trying to list the directory on the D drive when I exit from the installer. From: Jon Brase Sent: Tuesday, September 24, 2019 11:09 PM To: Discussion and general questions about FreeDOS. Subject: Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 FreeDOS (x86 software) won't boot (natively) on the Raspberry Pi 3 (ARM hardware), so if you got as far as to be able to select "install to hard disk", you must be using an x86 emulator, and, indeed, your screenshot shows that you're using QEMU. To minimize confusion, you should lead with the information that you're using QEMU, and follow it up with the fact that you're on a non x86 platform, as there are differences in how QEMU handles guest code for the same architecture that it's running on and how it handles code for other architectures. I myself haven't run FreeDOS on any platform other than x86 PCs, so I'm not sure how much help I can be, but can you say what emulated peripherals you set up for your FreeDOS VM in QEMU? Original message From: shift83...@gmail.com Date: 9/24/2019 22:15 (GMT-06:00) To: freedos-user@lists.sourceforge.net Subject: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 I have tried multiple times to install FreeDOS on Raspberry Pi3. I have created a 100M and 200M raw disk image. Mounted the Standard and then tried with the Legacy ISO. Both will boot the ISO, partition and format the hard disk. But when I reboot and select the Install to Harddisk after it goes to gathering settings a couple of minutes go by and I get: I have also tried to mount the floppy.img as well as the ISO and boot from floppy with the same results. Has anyone seen this and been able to resolve it? Thank you, Chris ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3
FreeDOS (x86 software) won't boot (natively) on the Raspberry Pi 3 (ARM hardware), so if you got as far as to be able to select "install to hard disk", you must be using an x86 emulator, and, indeed, your screenshot shows that you're using QEMU. To minimize confusion, you should lead with the information that you're using QEMU, and follow it up with the fact that you're on a non x86 platform, as there are differences in how QEMU handles guest code for the same architecture that it's running on and how it handles code for other architectures. I myself haven't run FreeDOS on any platform other than x86 PCs, so I'm not sure how much help I can be, but can you say what emulated peripherals you set up for your FreeDOS VM in QEMU? Original message From: shift83...@gmail.com Date: 9/24/2019 22:15 (GMT-06:00) To: freedos-user@lists.sourceforge.net Subject: [Freedos-user] Issue installing FreeDOS on Raspberry Pi 3 I have tried multiple times to install FreeDOS on Raspberry Pi3. I have created a 100M and 200M raw disk image. Mounted the Standard and then tried with the Legacy ISO. Both will boot the ISO, partition and format the hard disk. But when I reboot and select the Install to Harddisk after it goes to gathering settings a couple of minutes go by and I get: I have also tried to mount the floppy.img as well as the ISO and boot from floppy with the same results. Has anyone seen this and been able to resolve it? Thank you, Chris ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] can FreeDOS do anything to make up for Virtualbox and VMWare's lack of decent support for DOS sound?
Its github page says it's a hypervisor, and in the context of your question as to whether it supports booting an arbitrary OS it doesn't make much of a difference, but, from what I can see it's more of an emulator than a hypervisor. However, for the typical FreeDOS use case, an emulator is indeed a better fit than a hypervisor. The difference is that an emulator simulates the operation of the whole machine in software, whereas "hypervisor" or "virtual machine" usually implies that as much as possible of the code of the guest OS and its applications is run directly by the CPU of the host system as possible, with emulation only happening where necessary to prevent the guest OS from inadvertently or deliberately interfering with the host OS. For the user, the difference is that hypervisors generally have the goal of using spare resources on the host machine to create a new computer similar to the host out of thin air without having to buy a new computer, while emulators generally have the goal of running software that won't generally run well, or at all, on the host, often in cases where the guest architecture is obsolete and working hardware is difficult or impossible to find. This isn't a hard and fast distinction, though: platforms like QEMU will make use of a hypervisor when running code for the host processor, but when running code for a different architecture will run it under full emulation. Some processor architectures (quite a few in the past, not so many now) don't allow every instruction that could interfere with the host OS to be trapped, in which case a hypervisor in the strict sense is impossible and emulation is required even for use cases that would generally use a hypervisor. Also, the term "virtual machine", usually reserved for cases where the guest system is running on top of a hypervisor, is also quite frequently used for emulators that emulate a computer architecture for which no hardware implementations exist or ever intended to exist (such as that used by the Java language), which is a significant use of the term in a context fairly far from that in which it is usually employed. Original message From: st...@vwebr.net Date: 9/19/2019 22:39 (GMT-06:00) To: "Discussion and general questions about FreeDOS." Subject: Re: [Freedos-user] can FreeDOS do anything to make up for Virtualbox and VMWare's lack of decent support for DOS sound? Please ignore my last. I see that it's a hypervisor, which should do what I need. I almost thought it was too much like DOSBox which is its own OS and I was trying to stay away from that. Nothing against DOSBox, it has its place and is best in what it does. On 2019-09-19 21:22, st...@vwebr.net wrote: Not making any assumptions at all, and frankly it sounds interesting. Merely trying to understand what it is in comparison to Virtualbox and VMWare, or DOSBox. If it's a virtual machine app meant to install an OS into like the first two, then of course I'm very interested. On 2019-09-19 09:30, geneb wrote: On Thu, 19 Sep 2019, st...@vwebr.net wrote: Asking the question a different way. Is there another virtual app (alternatives to Virtualbox or VMWare) that does a much better job supporting DOS hardware which I can install FreeDOS onto? That's what 86Box does - it supports a huge range of hardware. You need to actually use it before assuming it won't meet your needs. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_! ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Installing FreeDOS alongside MS-DOS on old system
On Tue, 17 Sep 2019 09:48:04 +0200 Mateusz Viste wrote: > On 17/09/2019 01:00, Jon Brase wrote: > > My question isn't actually what packages are in base. My question is, given > > the presence of an existing MS-DOS install, what is the minimal set of > > packages that would need to be unpacked onto the MS-DOS partition *in order > > to get the package manager running*. > > FDNPKG is a stand-alone application. It can run on any DOS, not only > FreeDOS. > > > Do I just need to install the package manager itself, or does it have other > > dependencie? For instance, does it use batch scripts that require FreeCOM? > > Does it, in general, require the presence of any FreeDOS components other > > than itself? > > No dependencies. Just download FDNPKG, configure a set of repositories > (either from FreeDOS, Svarog386, or anything compatible), and that's it. > Good to know. Have it running under MS-DOS using the CD as a repository, haven't tried setting up networking yet. Under FreeDOS itself, I'm having a bit of trouble getting my CD drive set up. Specifically, having just installed components through FDNPKG, I'm having to write up my own FDCONFIG.SYS / FDAUTO.BAT, and I'm having trouble figuring out which components are current and what their usage is from the documentation. There's a "XCDROM32" (or something like that, I'm not currently at that computer) in the BIN directory, but "help xcdrom32" takes me to a help page for xcdrom, which says its deprecated and UIDE.SYS should be used instead. There's a help page for UIDE.SYS, but I can't actually find UIDE.SYS itself anywhere. Can anyone provide an example FDCONFIG / FDAUTO set that is current for FreeDOS 1.2 and contains sane defaults for a machine from circa 1995? ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] can FreeDOS do anything to make up for Virtualbox and VMWare's lack of decent support for DOS sound?
On Mon, 16 Sep 2019 17:18:18 -0600 st...@vwebr.net wrote: > This is kind of a sore point when using Windows-based virtualization > apps. > > Virtualbox (and I believe VMWare) support SoundBlaster 16, but only to a > certain extent (as in later versions of Windows). > > They don't support DOS sound, period. > > One of the things I noticed with DOS games is that I/O ports are not > supported (e.g. A220 and P330) by Virtualbox or VMWare's implementation. > > > Because I remembered that BIOS extensions are something that were used > many years ago to adapt machines BIOS that (for instance) didn't support > larger sized HDDs, I'm wondering if the same sort of thing can be done > to implement a much more accurate version of a SoundBlaster ISA card > which > allows DOS games to fully recognize an improved virtualized ISA sound > card and make use of it. > > I know that DOSBox is able to achieve sound for DOS games, so it seems > like something not too difficult unless the virtual app would block it > from working. Well, the thing is, DOSBox isn't just a DOS implementation, like FreeDOS is. It's a DOS implementation plus a layer similar to VMWare or VirtualBox that emulates the hardware. It also has a narrower focus for the kinds of applications it tries to run well: It's focused on games, which made significant use of sound hardware. Since DOSBox is not just a DOS implementation, but also a hardware emulator, it knows that it's running on top of another OS, so it can just use the OS's sound API as a back end and let the OS and drivers take care of turning that into actual sound coming out of the speakers. FreeDOS either isn't running on top of another OS (on bare metal) or doesn't know that it is (under emulation or virtualization), so it, or a driver that it loads, has to talk directly to the hardware. For FreeDOS to emulate SoundBlaster sound, it would have to trap all accesses to the soundblaster hardware (probably easy enough for an EMM to do, if you have a 386 or better), and then it would have to translate the attempted soundblaster accesses into some standardized representation of the sound to be produced, and hand that off to a driver written for the sound hardware actually installed on the machine. Windows and Linux have huge collections of drivers already in existence, and MacOS runs on only one manufacturer's hardware, but FreeDOS would have to start from scratch. > I figured the easiest path would be something like what DOSBox uses, > except implemented in FreeDOS but a BIOS 'extension' is another avenue. > > I guess a BIOS extension would depend on having access to the code for > SeaBIOS or whatever Oracle or VMWare uses to virtualize hardware. A BIOS extension wouldn't help, because BIOS had no sound API. The PC architecture had no standardized on-motherboard sound beyond the PC speaker in the DOS era: everything was through expansion cards, and DOS didn't have a standardized sound API either. The closest thing to a standardized sound API was the fact that SoundBlaster had a fairly dominant market share, so if your software could talk to a SoundBlaster card, it would work on a good chunk of PCs. But it's the fact that applications had to talk to the hardware directly, without using the BIOS or DOS, that makes audio back-compatibility with DOS so difficult. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Installing FreeDOS alongside MS-DOS on old system
On Mon, 16 Sep 2019 17:13:42 +0200 Eric Auer wrote: > Hi Jon, > > > To answer the question which packages are BASE, check > > > http://www.freedos.org/software/ > > The idea is that BASE has similar functionality to what > you get with a 3 floppy MS DOS installation or with the > DOS mode of Windows 95 or 98. Of course there are very > interesting packages in the other categories, but unless > you have plenty of space, you will not usually want to > install all from all categories! You probably will not > even need everything from BASE, depending on your taste. My question isn't actually what packages are in base. My question is, given the presence of an existing MS-DOS install, what is the minimal set of packages that would need to be unpacked onto the MS-DOS partition *in order to get the package manager running*. Once the package manager is running under MS-DOS, I can use it to pull in any other desired components of FreeDOS, then add a boot option for FreeDOS to GRUB. Do I just need to install the package manager itself, or does it have other dependencie? For instance, does it use batch scripts that require FreeCOM? Does it, in general, require the presence of any FreeDOS components other than itself? > We did have older installers which tried to automatically > insert FreeDOS at places where other MS operating systems > already are present, but there are too many possibilities > to smoothly handle them all and in particular new Windows > versions have too little DOS in them for our installers to > be able to properly edit multi boot related files. So this > is something to be better done by hand. As experienced DOS > user, you will understand how to do it and as human, you > will be able to adjust it to your system :-) Fair enough. > Regarding your user space installer, where would you want to > run it? Inside an existing DOS? Then it would have to leave > the SYS and config / autoexec edit steps to the user, as too > many variants are possible. It would basically just be some > way to run the package manager with user-specified source and > target locations and a wildcard list of packages to install. > > Maybe some experienced package manager user can give us the > syntax for doing exactly that with very little typing :-) > > You would neither want to FDISK nor FORMAT when doing those > steps from an already existing DOS, obviously, to keep that. The userspace installer is a separate idea from the "within DOS" installer, and would run from within a multitasking OS such as *nix or Windows (modern NT-kernel Windows, not DOS-kernel Windows). The primary component would be a *nix or Win32/64 implementation of the FreeDOS package manager, which would unpack FreeDOS packages selected by the user to the mountpoint of a specified FAT partition or disk image. Optional functions could include writing a boot sector and providing a default autoexec.bat / config.sys when there is not an existing DOS installation on the disk / image provided, and potentially even creating a new disk image or partitioning a disk. If the above optional features were included, it present the user with the following menu when run: "Welcome to the FreeDOS installer for Linux! Do you want to: 1) Manage FreeDOS packages on a FAT partition mounted on this machine? 2) Create a FreeDOS disk image for use in a virtual machine? 3) Install FreeDOS to an unused disk or partition on this machine?" ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Installing FreeDOS alongside MS-DOS on old system
On Mon, 16 Sep 2019 00:07:50 +0200 Eric Auer wrote: > Hi Jon, > > for your advanced multi boot project, you could boot FreeDOS > from floppy and use the SHSU... drivers to open the ISO file > of the install CD as if it were a CD drive, after using your > Windows or Debian to copy the ISO to your DOS/Win95 harddisk. Unfortunately, the ISO would very nearly fill up that partition. While I'm not using any such software now, I had at one point had at one point been playing with ancient software on the machine in question that choked on HDDs over 8 GiB, and the largest disk I had under that limit was 4 GiB, so all three systems on the disk have fairly limited storage available. I've got a fair number of old DOS games installed on the DOS partition, so space is even more limited. If I put the ISO on that partition, I wouldn't have any space left to unpack anything. Now, I could prune stuff off the partition or move it to one of the other partitions, or I could get a screwdriver, image the disk to a larger HDD and then expand all the partitions out, so it's not that I absolutely can't drop the ISO in and mount it, but given the time and effort involed in those courses of action I do want to be sure that freeing up disk space and dropping the ISO in is my best option before I commit to either variant of that action. > The ISO has plenty of ZIPs to use with the package manager, > but you will be unable to see most of the apps which do the > install process, as those are in a boot disk image inside a > separate area of the ISO ;-) As an alternative to booting from the FreeDOS installer floppy and mounting the ISO, can you comment on the feasibility of unpacking the package manager into the existing MS-DOS installation and working from the CD, given that MS-DOS is not having any trouble with the CD drive? What minimal package set would I need to unpack manually? I assume FDNPKG, anything else? Is there any configuration that I'd need to do to point it at the install CD? > You can manually use the package manager to install the FreeDOS > packages of your choice to some FreeDOS specific directory on > your harddisk and you can use special options of SYS to create > a FreeDOS boot sector file and then add that file to your boot > menu, such as GRUB, instead of using SYS the normal way which > would overwrite your MS DOS or Win95 boot sectors. > > I would NOT use the normal install script, as that does not have > specific precautions to behave well in a system such as your PC > which has already 2 MS "DOS" style operating systems installed. Good to know. I don't know how common paralell DOS installs like what I'm planning are, but but given the fdauto.bat/fdconfig.sys convention they don't seem to be entirely unanticipated, so it might be good for FreeDOS to have an installer, or at least a standardized, how-to-ized manual install procedure for that use case. Likewise, given that I've found a separate Linux partition to be a very nice administrative environment for a DOS install on bare hardware, and the fact that the VM/emulation use case seems to be one that's forseen for many FreeDOS installs, it might be good to have a userspace installer for *nix and/or Win32 that can install FreeDOS with a user-selected package set to an empty FAT filesystem, either in a parition or an image file (let's call the concept "supersys"). Jon Brase ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Installing FreeDOS alongside MS-DOS on old system
Hello everyone, I have an old 1995-vintage pentium system running a triple-boot of Debian, MS-DOS 6.22, and Windows 95. I would like to install FreeDOS along side MS-DOS on the DOS 6.22 partition, but have been running into some trouble. The machine has a CD drive, but cannot boot from CD, and I cannot get the FreeDOS 1.2 install floppy to simultaneously recognize the CD drive and the HDD. (Actually I can get a configuration where the CD drive seems to be recognized by the installer, which then complains that it can't find any fixed disks, but when I drop to a shell, I can browse the HDD but not the CD-drive). I have tried moving the floppy contents to a subdirectory on the target drive, but the install scripts seem to have too many lines that assume that the directory structure from the floppy is at the root of the drive in question, and I don't really want to drop the floppy contents directly into the root of my DOS partition because they contain an autoexec.bat (instead of fdauto.bat), so if I'm not careful I could end up blowing away the existing autoexec.bat on the drive. I suppose I could just drop components in one by one, but that sounds like a lot of work. So I have a few questions: 1) Can anybody think of anything that might resolve the drive detection issue? 2) Is there any alternative to or subset of the installer files on the floppy image such that I can boot into my existing DOS installation and pull everything off the CD, considering that preliminary steps like partitioning or formatting my HDD are neither needed nor desired? 3) Is there some Grand Unified Tarball that I can just unpack to the mountpoint of my DOS partition in Debian (rather than unpacking the zips for individual packages one by one)? 4) Failing that, what's the minimum set of packages from freedos.org/software that I'd have to unpack on the MS-DOS partition to pull down the rest from the net? I assume FDNPKG at least. Does it have any dependencies? Also, I see a package "FDIMPLES" that seems to imply that FDINST is an available package manager, which FDIMPLES uses, and I see a corresponding "FDI sources" package but I don't see any sign of a binaries package for FDI (or is it all scripts?). Pulling down packages from the net from within DOS isn't something I really want to do, though I can if all else fails. I have a network stack installed on my MS-DOS partition, but mostly use it on my LAN and try not to have anything but Linux talk to the outside internet. In my current configuration, autoexec.bat actually loads the driver briefly, syncs the system time with a local NTP server (the RTC battery died long ago), and then unloads the driver again, so I'm not actually even on the network under DOS most of the time. Jon Brase ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
