Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Eric Auer]

Hi Jerome, to answer some specific parts of your mail:

Yes, it is useful to have two different boot style CD
images and not only the more compatible variant plus
a boot floppy image. Because the latter would mean
that people which could boot CD only in the less
common style would need a floppy drive to boot some
special floppy which in turn boots the common style
CD "manually", but not everybody with an old CD boot
BIOS automatically has a floppy drive to boot this
workaround :-)

And no, to answer the other question, it does not
sound very useful to me that you can install floppy
edition style from the CD, even when it only is an
easter egg.

So: LiveCD yes, LegacyCD yes, additional boot floppy
images beyond those on the CD itself used by the BIOS
to boot no? And as you know, I suggest having a nice
BASE plus some extras set of things pre-installed on
the LiveCD, without first having to unpack them to a
RAMDISK. Most BASE apps do not need to be copied to
a writeable drive to work, so precious RAMDISK space
can be saved by running directly from the CD.

Also, regarding some earlier question on this list,
I think it would be nice to have the bootable USB
"live stick" pre-installed in similar ways. This
lets users start to enjoy DOS immediately without
needing this "use a partition manager to create a
second FAT partition on the stick in remaining space
and push the installer to install to D:" trick :-)

I agree that USB boot support may not always let
you write to the stick, but then again it helps
to have more pre-installed DOS apps on the stick,
so people have to install less into some RAMDISK.

We should expect DOS users to be able to realize
whether or not writing to USB fails on their PC.

There should be a warning about which drive is RAMDISK,
so people are not disappointed to lose data THERE.

Last but not least, some mails mentioned FDISK
problems which do not happen with 512 MB or larger
virtual computer drives, but with smaller ones,
such as 500 MB so I wonder whether this actually
some FDISK automatic LBA decision gone wrong?
The limits for various CHS schemes are in the
500 to 530 MB range and around 8 to 8.5 GB.

It would be nice to have a tool for popular OS
which extends the boot partition to the size of
the stick when using a DOS USB boot image, but
that takes effort, so I think a flat diskimage
which requires a stick of at least 150% of the
space actually filled with installer data will
be most universal: People can use any diskimage
writer of their choice to "install" it, which
avoids questions like whether RUFUS etc. would
understand contents well enough to tune them?

Regards, Eric

PS: I agree that CoreBoot or SeaBIOS as base of
a CSM (or whatever the acronym was) to get BIOS
style services on UEFI systems would be cool :-)
Regarding a pre-configured Linux which simply
boots into DOSEMU2 or similar, those exist. But
you could even use DOS in DOSBOX-X in HX in DOS.



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Jerome Shidel]

Hi, 

> On Jan 17, 2022, at 4:05 PM, Liam Proven  wrote:
> 
> On Mon, 17 Jan 2022 at 20:15, Robert Riebisch  wrote:
>> 
>> Hi Jim,
>> 
>>> I suspect the term is regional :-) It's the same thing as a USB thumb
>>> drive or USB flash drive.
>>> 
>>> USB flash drive is the more common term.
>> 
>> In Germany it's often called "USB stick".
> 
> Agreed. USB key/stick/thumb drive. I've just not seen "fob" before. I
> think it's easily possible to work out what it is.
> 
> To get slightly back on topic: has the list got any recommendations
> for the best way to make a DOS-bootable key from scratch, i.e. not
> from an ISO?
> 
> What I do is using a VM on Linux. VMware is easier for this, but
> VirtualBox can do it too.
> 
> I attach the key directly to VM as its hard disk. (In VirtualBox you
> need to create a special device, which is only accessible as root, and
> then use the `chmod` command to make it usable by an ordinary user.
> 
> Then I boot DOS from a floppy image, and use the normal DOS tools to
> partition the USB key, then make a single big primary partition, set
> it as active, format it, then `sys` it.
> 
> This will usually now boot the PC directly, but it's a little
> hit-or-miss on some PCs.
> 
> I blogged about how to do this on Linux years ago:
> https://liam-on-linux.livejournal.com/50416.html
> 
> 
> -- 
> Liam Proven ~ Profile: https://about.me/liamproven
> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
> Twitter/LinkedIn: lproven ~ Skype: liamproven
> UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
> 

Some do refer to them as a fob. 

I did not look any of this up. So, it could be completely wrong. :-)

Basically, I think it has something to do with semi-modern car remotes (Like 
alarm, start, locks). They were usually kept on the key ring. However, many 
were not part of the automobile key.

These devices were often referred to as Key Fobs or just Fobs for short. The 
name has seemed to migrate to any type of electronic device that could be 
placed on a ring or clip.



> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Liam Proven]

On Mon, 17 Jan 2022 at 20:15, Robert Riebisch  wrote:
>
> Hi Jim,
>
> > I suspect the term is regional :-) It's the same thing as a USB thumb
> > drive or USB flash drive.
> >
> > USB flash drive is the more common term.
>
> In Germany it's often called "USB stick".

Agreed. USB key/stick/thumb drive. I've just not seen "fob" before. I
think it's easily possible to work out what it is.

To get slightly back on topic: has the list got any recommendations
for the best way to make a DOS-bootable key from scratch, i.e. not
from an ISO?

What I do is using a VM on Linux. VMware is easier for this, but
VirtualBox can do it too.

I attach the key directly to VM as its hard disk. (In VirtualBox you
need to create a special device, which is only accessible as root, and
then use the `chmod` command to make it usable by an ordinary user.

Then I boot DOS from a floppy image, and use the normal DOS tools to
partition the USB key, then make a single big primary partition, set
it as active, format it, then `sys` it.

This will usually now boot the PC directly, but it's a little
hit-or-miss on some PCs.

I blogged about how to do this on Linux years ago:
https://liam-on-linux.livejournal.com/50416.html


-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Robert Riebisch]

Hi Jim,

> I suspect the term is regional :-) It's the same thing as a USB thumb
> drive or USB flash drive.
> 
> USB flash drive is the more common term.

In Germany it's often called "USB stick".

Cheers,
Robert
-- 
  +++ BTTR Software +++
 Home page: https://www.bttr-software.de/
DOS ain't dead: https://www.bttr-software.de/forum/


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Jerome Shidel]

Hi, 

> On Jan 16, 2022, at 3:07 PM, Jim Hall  wrote:


> I think it's better not to hide features - so yes, the FloppyEdition 
> installer should get its own entry in the CD boot menu. But from your 
> description, maybe it needs a different name.

Hi, 

> On Jan 16, 2022, at 3:07 PM, Jim Hall  wrote:

> I think it's better not to hide features - so yes, the FloppyEdition 
> installer should get its own entry in the CD boot menu. But from your 
> description, maybe it needs a different name.

At present the LiveCD boot menu says:

Use FreeDOS 1.3 in Live Environment mode
Install to harddisk
Boot from system harddisk
Boot from diskette
FreeDOS is a trademark of Jim Hall, 2001-2021

I don’t actually think we need the Boot from diskette option at all. Maybe we 
should git rid of it?

We would need two install choices. In part, we could change the description 
text to help users decide which to run. When install to harddisk is currently 
selected. The description reads as “Install the FreeDOS 1.3 operating system 
from CD-ROM to the harddisk. For more information, visit the FreeDOS project 
website at http://www.freedos.org ”

I think is is difficult to describe the differences between the two installers 
quickly, accurately and in a way users can easily understand. There have been a 
lot of improvements to the Floppy Edition since RC5. Including, at boot 
language selection to run the installer in several languages. And a number of 
bug fixes. But, generally the Floppy Edition doesn’t look much different than 
in RC5. 

The biggest noticeable difference between FDI (the primary installer) and 
FDI-x86 (The Floppy Edition installer) is on the LiveCD the Floppy Edition 
boots into advanced mode. But, there a lot of other differences. Some little 
some huge. 

You should try the Floppy Edition.Hopefully you can think of how to word the 
menu entry and descriptive text.

> On the second one, about the LegacyCD vs boot floppy to use the LiveCD: I can 
> see benefits to either solution. I'm approaching this from a "what's easiest 
> for the user" perspective, and I think keeping a LegacyCD is still a good 
> option rather than pushing those folks to a LiveCD + boot floppy. We still 
> have the floppy there for the even narrower use case where folks have a CD in 
> their system but cannot boot from CD - they'll need the boot floppy to access 
> the CD installer anyway. So I wouldn't change this, at least not for 1.3 
> "Final." Might change that for "2.0" or whatever version comes after "1.3.”

Agreed. It’s not like it is extra work to create it. Nowadays, it is really 
just a setting in the RBE.

You left out your thoughts on providing an additional Live Boot Floppy image 
along with or instead of the CD Boot Floppy image. So, let me tell you a little 
story on the roots of the Live Environment.

I still have this Pentium Pro I bought new back in late 1995 (or maybe early 
1996). It’s CMOS battery finally died a couple years back. It lasted about 20 
years so I’m not complaining. But on most machines, you can just swap out a 
coin battery. Not on this machine. The battery is integrated inside the real 
time clock IC. Which was soldiered to the motherboard. The machine would 
complain about a dead battery at boot. But otherwise worked fine. Except for 
one tiny problem. At power on or reboot all BIOS settings changes reverted to 
default. This meant that hard drives were set to “Not Present”. So for a ll 
intents and purposes, the machine was diskless. Then I found myself in need of 
converting a pile of 5.25 disks to image files. This was the only machine I had 
with a floppy controller. But everything I needed would not fit on a single 3.5 
diskette. The machine is also very picky on what kind of CD it will boot. 

To make a long story shorter, I came up with a system to have a lite-weight 
startup process that then brought up all the additional stuff I needed from CD 
into a RAM disk (Pentium Pro has 96MB of RAM, it used to maxed out at 128 but a 
RAM module died a decade or so ago). This allowed me to image the 5.25 
diskettes then compress them and write them to 1.44mb. 

As you can see, there is a use case for a floppy image to boot the Live 
Environment. But, think it is an edge case. How useful it would it really be to 
most users?

:-)

Jerome



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Jim Hall]

> On Sun, 16 Jan 2022 at 21:35, Jim Hall  wrote:
>
> >  I write the ISO image to a USB fob drive

On Mon, Jan 17, 2022 at 5:11 AM Liam Proven  wrote:
>
> I don't think I've ever heard them called that before! :-)
>[..]


I suspect the term is regional :-) It's the same thing as a USB thumb
drive or USB flash drive.

USB flash drive is the more common term.


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Liam Proven]

On Sun, 16 Jan 2022 at 21:35, Jim Hall  wrote:

>  I write the ISO image to a USB fob drive

I don't think I've ever heard them called that before! :-)

>  I think you can do the same with Rufus. It writes the image and makes the 
> USB fob drive bootable.

I would think so. I have not tried.

Rufus is good (it's small, it's free, and you don't need to install
it) but it's *very* slow. I only used it when I needed to make Windows
bootable keys.

(Not a lot of people seem to realise this, but you can freely download
Windows 7/8/10/11 ISO files from microsoft.com. I think that for 7 & 8
the site wants a licence key, but it doesn't ask for 10 or 11

These days I just use Ventoy, which lets you copy as many ISO files as
will fit onto a single FAT32 USB key and generates a boot menu on the
fly when you boot a computer from that key. It's very convenient and
it's far faster and easier than writing images.

On Windows & macOS I occasionally use Balena Etcher, which is FOSS &
much faster than Rufus – but sometimes Windows keys written this way
aren't bootable. The snag with Etcher is that it's an Electron app, so
it's relatively speaking *huge* and slow to download if you're on a
slow connection. (Electron apps are written in Javascript and so the
app must include an embedded web browser and Javascript interpreter.
So while the app might be a couple of hundred lines of code, the
Javascript frameworks it needs are hundreds of thousands of lines, and
the Javascript runtime is tens of meg, and that needs hundreds of meg
of web browser to support the runtime. This is considered normal in
FOSS these days.)

Result: the tool to write a minimal or small FreeDOS ISO to USB is
bigger than the ISO itself. Insane but true.

> So my question is really: what about using Rufus to write the FreeDOS 1.3 CD 
> ISO image to a USB fob drive - instead of providing a 32MB "Lite" USB image 
> and a 512MB "Full" USB image.

There are dozens of FOSS ISO-writers and most will probably be faster
than Rufus. In the old days, with optical media, I used ImgBurn or
CDBurnerXP. Some are tiny, as in under 1MB.

> That would seem to be the easiest option, in my mind. It seems like it would 
> be simpler to provide the LiveCD ISO image and people can write that to a USB 
> fob drive with a tool like Rufus.

Agreed. Just saying that both "small" and "fast" are good priorities,
and Ventoy may be easier for many people.

-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Jerome Shidel]

Hi,

> On Jan 16, 2022, at 3:34 PM, Jim Hall  wrote:
> 
> Something I've wondered is if we really need the USB installer at all. Not as 
> in "let's get rid of the USB installer for the sake of getting rid of it." I 
> know that some people do use the USB installer (comes up in questions on 
> Facebook and YouTube sometimes) but consider this:
> 
> I run Linux, and use Fedora on my PC. When I download a new version of Fedora 
> Workstation , it comes as a 
> DVD ISO image. But my PC doesn't have a DVD drive (my previous laptop didn't 
> have an optical drive either) so I write the ISO image to a USB fob drive 
> using Fedora Media Writer 
> .
>  I think you can do the same with Rufus . It writes the 
> image and makes the USB fob drive bootable.
> 
> So my question is really: what about using Rufus to write the FreeDOS 1.3 CD 
> ISO image to a USB fob drive - instead of providing a 32MB "Lite" USB image 
> and a 512MB "Full" USB image.
> 
> That would seem to be the easiest option, in my mind. It seems like it would 
> be simpler to provide the LiveCD ISO image and people can write that to a USB 
> fob drive with a tool like Rufus.
> 
> 
> Jim

Well, I’ve thought about dropping it as well. As far as I can tell, it seems 
like most users download the LiveCD and use programs like RUFUS to turn it into 
a USB stick. It also feels like we have a lot of download choices already and 
we don’t really need them all. 

Someone could argue, we should have a  many USB options. Like 16mb Base Only, 
32MB Base + Free Space, a 512MB Standard, 1gb Everything, 2gb Pre-installed 
version … and so on. But, all those would really do is make things more 
confusing.

Personally, I don’t really use Windows or Rufus. Mostly, I use macOS desktops 
and Linux servers.  So when it comes to making USB install media, I just use dd 
to write the image to the flash media. I also have 4 different real machines I 
run or test FreeDOS. Some will boot from CD, some won’t. The most interesting 
one is the Acer Netbook. I can boot and install from an attached USB Floppy 
and/or a USB Thumb Drive. However, prior to RC5 it would not install from CD. 
The fallback to the El Torito CD driver makes installation possible now. 
However, post install the drive is not supported. Generally to not waste discs 
and install faster, I use the 512mb USB stick version. 

But, I think I’m the exception not the rule. It’s also not like I cannot just 
make one myself. The same goes for anyone wanting a 2 or 4 Gb version. The RBE 
makes it easy to create such custom versions.

:-)

Jerome


 

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Mercury Thirteen via Freedos-devel]

On Sunday, January 16th, 2022 at 3:34 PM, Jim Hall  wrote:

> ...
> I run Linux, and use Fedora on my PC. When I download a new version of 
> [Fedora Workstation](https://getfedora.org/en/workstation/download/), it 
> comes as a DVD ISO image. But my PC doesn't have a DVD drive (my previous 
> laptop didn't have an optical drive either) so I write the ISO image to a USB 
> fob drive using [Fedora Media 
> Writer](https://developers.redhat.com/blog/2016/04/26/fedora-media-writer-the-fastest-way-to-create-live-usb-boot-media#how_does_it_work__).
>  I think you can do the same with [Rufus](https://rufus.ie/en/). It writes 
> the image and makes the USB fob drive bootable.
>
> So my question is really: what about using Rufus to write the FreeDOS 1.3 CD 
> ISO image to a USB fob drive - instead of providing a 32MB "Lite" USB image 
> and a 512MB "Full" USB image.
> ...

FWIW, when I need to boot FreeDOS on real hardware, I almost always do it this 
way using the built-in tools of Linux Mint. Works great for me, so I see no 
reason why the average FreeDOS user couldn't do something similar.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Jim Hall]

On Sat, Jan 15, 2022 at 6:33 AM Jerome Shidel  wrote:

> [..]
> We come to UEFI and modern hardware. With modern hardware vendors dropping
> support for Legacy BIOS and users wanting to run FreeDOS on modern
> machines, I only see three solutions.
>
> First… Oh well, they can run it in a virtual machine and we should no
> longer worry about native hardware support.
>
> Second… I really haven’t looked into this one at all. But, I think it
> would be possible to use Core Boot, SeaBios or something else to provide
> Legacy BIOS support ourselves on UEFI only systems. This would be a good
> deal of work. It also still leaves the problem of sound drivers and other
> hardware support. This might also require some thin hardware emulation
> layer. But, it should be doable.
>
> Third… Create a custom extremely slim Linux distro to boot the system and
> provide basic hardware support. That OS would boot directly into a VM
> platform like QEMU or DOSBox and run FreeDOS. Overall, I think this might
> be the best option for UEFI only systems and modern hardware.
>
> It would provide support for sound and networking through Linux drivers.
> It could be easily slowed down for older games. It could even be used to
> run FreeDOS on non-x86 based hardware. Some of the disadvantages of doing
> this would be the need to technically maintain two operating systems. Since
> even the lite weight Linux distros are more bloat than we would want or
> need, we would have to do our own. It would also require creating some
> Linux programs to easily manage things on the host OS.
>
> Perhaps this should be done as a completely separate project from FreeDOS.
> Something like a RetroPC project. However, their may already be such a
> project in existence we could use. We could then either release a version
> or just point people at it for modern hardware.
>
>

This is an interesting idea, but I think it's best to do this outside the
FreeDOS Project. A project like this would be useful to more things than
just FreeDOS, so a separate project seems best. And that way we're not
confusing "FreeDOS development" with "Linux development" or "UEFI
development" or "VM development."

Jim
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Jim Hall]

On Sat, Jan 15, 2022 at 6:33 AM Jerome Shidel  wrote:

> [..]
> A lot of users want to run FreeDOS from USB. As I see it, there are
> several issues with that.
>
> First, you cannot guarantee that when booted from USB that drive will be
> writable. Personally, I’ve never seen when it was write protected. But,
> during the early days of developing the installer for 1.2, I learned that
> it was sometimes the case and attempts to use it for temp storage resulted
> in the users machine screaming very loud beeps and throwing write errors.
> So, the installer was modified and always assumes it’s boot media is
> write-protected.
>
> Next, I don’t think users want a temporary Live Environment for USB usage.
> They probably want the programs they install and the changes they make to
> remain for next time. They also probably want the full capacity of the USB
> drive.
>
> That is problematic. Without spending the time to write our own custom
> “Write to USB” program, most will be stuck writing the standard USB images
> directly too the USB media. I don’t see us making our own custom image
> burner to stretch the filesystem for all the major OS platforms. So, that’s
> out for the foreseeable future.
>
> Probably most systems will only do USB HD emulation when booted from that
> USB drive (although I have some machines here that do it even when booted
> from the HD as long as the USB stick is inserted), the best solution I’ve
> come up with has been around for a while. More or less I refer to it as an
> OEM style install. I demonstrated it in a YouTube video with FreeDOS 1.2.
> Basically, you just write the USB install image to the drive. Then boot it
> and exit the installer. Use FDISK to create a separate partition on the USB
> drive and reboot. Because who knows what all drives are in the machine and
> how they will be ordered, use FDISK to verify the drive letter. If its
> drive D:, just run the installer again. If it is not drive D:, run the
> installer in advanced mode and tell it the appropriate drive. Once install
> completes, just reboot. It will boot into the installed partition. This
> leaves the original installer boot partition as a “OEM” style recovery
> partition. It also lets FDIMPLES use that recovery partition as a package
> source to add and remove addition programs. Not a perfect solution. But one
> I’ve used many times on internal hard drives and even USB sticks.
> [..]



Something I've wondered is if we really need the USB installer at all. Not
as in "let's get rid of the USB installer for the sake of getting rid of
it." I know that some people *do* use the USB installer (comes up in
questions on Facebook and YouTube sometimes) but consider this:

I run Linux, and use Fedora on my PC. When I download a new version of Fedora
Workstation , it comes as a
DVD ISO image. But my PC doesn't have a DVD drive (my previous laptop
didn't have an optical drive either) so I write the ISO image to a USB fob
drive using Fedora Media Writer
.
I think you can do the same with Rufus . It writes
the image and makes the USB fob drive bootable.

So my question is really: what about using Rufus to write the FreeDOS 1.3
CD ISO image to a USB fob drive - instead of providing a 32MB "Lite" USB
image and a 512MB "Full" USB image.

That would seem to be the easiest option, in my mind. It seems like it
would be simpler to provide the LiveCD ISO image and people can write that
to a USB fob drive with a tool like Rufus.


Jim
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Jim Hall]

On Sat, Jan 15, 2022 at 6:33 AM Jerome Shidel  wrote:

> Hello all,
>
> I’ve got a couple thoughts regarding the OS release media I wanted to
> throw out to you all. These are just things I was pondering and by no means
> I’m I saying any of these are going to happen. They are just some ideas I’d
> like to share with you and get feedback on…
>
> As you know, the LiveCD uses multiple boot images. A floppy one that
> starts the Live Environment. A second floppy one that launches directly
> into the installer. Finally, a third small hard disk image to run the
> FloppyEdition installer without need for OS level CD support.
>
> Do you think the FloppyEdition installer should be given it’s own entry in
> the CD boot menu? Or, leave it as an “EasterEgg” boot by selecting the
> copyright notice on the menu?
>
> Personally, I don’t see either as a perfect solution. If it is left as an
> EasterEgg, many people will never know it is there. Don’t forget, that
> installer does not need any OS level CD support. If a machine can boot it,
> it can pretty much install FreeDOS on anything. On the other hand, I think
> moving it to it’s own menu item will just confuse users by having 2
> different “Install FreeDOS options”.
>
> Another possibility is drop the current “Install” option. Replacing it
> with the Floppy Edition. Maybe call it something like “Install FreeDOS BASE
> only.” After all, there is no problem running the primary installer from
> the Live Environment. But again, I think users will pick the wrong thing.
>
> This now brings me to the Legacy CD.
>
> It boots using a different process than the LiveCD (See numerous previous
> posts on those differences). This provides CD booting on a narrow range of
> hardware that can boot from CD but not use the method employed by the
> LiveCD. There is a CD Boot Floppy included in the LiveCD download zip
> archive. So, do we really need to keep the LegacyCD around?
>
> The emulated Floppy the LegacyCD boots is the same as the current LiveCD’s
> boot to install menu option. If the LegacyCD sticks around, the image it
> boot’s could be switched to the one used by the LiveCD’s boot to Live
> Environment. This would provide a Live Environment on that legacy hardware.
> But, then what would we call things. They’d both be LiveCDs.
>
> Finally (at least for now), along with the LiveCD and LegacyCD a CD boot
> floppy image is included. We could include a second floppy image to boot
> the Live Environment when direct booting from a CD is not possible. But, it
> could also cause confusion on what to use or burn to CD or Floppy. So, IDK.
> [..]



On the first one:

> "Do you think the FloppyEdition installer should be given it’s own entry
> in the CD boot menu?"


I think it's better not to hide features - so yes, the FloppyEdition
installer should get its own entry in the CD boot menu. But from your
description, maybe it needs a different name.


On the second one, about the LegacyCD vs boot floppy to use the LiveCD: I
can see benefits to either solution. I'm approaching this from a "what's
easiest for the user" perspective, and I think keeping a LegacyCD is still
a good option rather than pushing those folks to a LiveCD + boot floppy. We
still have the floppy there for the even narrower use case where folks have
a CD in their system but cannot boot from CD - they'll need the boot floppy
to access the CD installer anyway. So I wouldn't change this, at least not
for 1.3 "Final." Might change that for "2.0" or whatever version comes
after "1.3."


Jim
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[TK Chia]

Hello Jerome,


Second… I really haven’t looked into this one at all. But, I think it would be 
possible to use Core Boot, SeaBios or something else to provide Legacy BIOS 
support ourselves on UEFI only systems. This would be a good deal of work. It 
also still leaves the problem of sound drivers and other hardware support. This 
might also require some thin hardware emulation layer. But, it should be doable.


About this particular direction:

(1)
One problem with SeaBIOS --- as it now stands --- is that it uses a very
specific memory layout, and the precise addresses of all the base memory
areas that it needs to are all fixed at build time.

I have been tinkering with the SeaBIOS code and trying to see if I can
get it to load in RAM rather than ROM, and possibly get parts of it to
go into extended memory (https://github.com/tkchia/seabiosify), but this
is definitely non-trivial.  (And, it is possible that I am doing it all
wrong...)

One attractive thing about the SeaBIOS code is that it seems to include
support for USB, including USB keyboards.

(2)
I have had some success meanwhile in getting a UEFI program to look for
legacy option ROMs (e.g. for VGA) in the system firmware, and bring them
up --- see https://github.com/tkchia/biefircate .  Admittedly, this only
really works on systems that still have some degree of support for
legacy APIs.

(3)
So I guess yes, this general direction will almost certainly be a good
deal of work, and we will probably need all the help we can get.

Thank you!

--
https://gitlab.com/tkchia :: https://github.com/tkchia


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Contemplations, Considerations and some Conclusions

[Aitor Santamaría]

Hi,

For me the last option (use Linux as VMM) would be the most sensible,
needing the least support effort for hardware and drivers: the Linux guys
will do it :)
Hardware-based DOS distributions will never get outdated because Linux
never will.

I think we talked about this option some time in one of the sunday
meetings: in my opinion, the nicest option would be if there was a
sufficiently small Linux distro that could be stripped down up to just
running DOSEMU (or xDOSEMU), maybe just one console, or maybe several (if
that old Ctrl+Alt+Fx is an option).

Just a thought and opinion, I wish I had some spare time myself to get into
such endeavour.

Aitor




On Sat, 15 Jan 2022 at 13:33, Jerome Shidel  wrote:

> Hello all,
>
> I’ve got a couple thoughts regarding the OS release media I wanted to
> throw out to you all. These are just things I was pondering and by no means
> I’m I saying any of these are going to happen. They are just some ideas I’d
> like to share with you and get feedback on…
>
> As you know, the LiveCD uses multiple boot images. A floppy one that
> starts the Live Environment. A second floppy one that launches directly
> into the installer. Finally, a third small hard disk image to run the
> FloppyEdition installer without need for OS level CD support.
>
> Do you think the FloppyEdition installer should be given it’s own entry in
> the CD boot menu? Or, leave it as an “EasterEgg” boot by selecting the
> copyright notice on the menu?
>
> Personally, I don’t see either as a perfect solution. If it is left as an
> EasterEgg, many people will never know it is there. Don’t forget, that
> installer does not need any OS level CD support. If a machine can boot it,
> it can pretty much install FreeDOS on anything. On the other hand, I think
> moving it to it’s own menu item will just confuse users by having 2
> different “Install FreeDOS options”.
>
> Another possibility is drop the current “Install” option. Replacing it
> with the Floppy Edition. Maybe call it something like “Install FreeDOS BASE
> only.” After all, there is no problem running the primary installer from
> the Live Environment. But again, I think users will pick the wrong thing.
>
> This now brings me to the Legacy CD.
>
> It boots using a different process than the LiveCD (See numerous previous
> posts on those differences). This provides CD booting on a narrow range of
> hardware that can boot from CD but not use the method employed by the
> LiveCD. There is a CD Boot Floppy included in the LiveCD download zip
> archive. So, do we really need to keep the LegacyCD around?
>
> The emulated Floppy the LegacyCD boots is the same as the current LiveCD’s
> boot to install menu option. If the LegacyCD sticks around, the image it
> boot’s could be switched to the one used by the LiveCD’s boot to Live
> Environment. This would provide a Live Environment on that legacy hardware.
> But, then what would we call things. They’d both be LiveCDs.
>
> Finally (at least for now), along with the LiveCD and LegacyCD a CD boot
> floppy image is included. We could include a second floppy image to boot
> the Live Environment when direct booting from a CD is not possible. But, it
> could also cause confusion on what to use or burn to CD or Floppy. So, IDK.
>
> I changed my mind. Thats not all just yet.
>
> A lot of users want to run FreeDOS from USB. As I see it, there are
> several issues with that.
>
> First, you cannot guarantee that when booted from USB that drive will be
> writable. Personally, I’ve never seen when it was write protected. But,
> during the early days of developing the installer for 1.2, I learned that
> it was sometimes the case and attempts to use it for temp storage resulted
> in the users machine screaming very loud beeps and throwing write errors.
> So, the installer was modified and always assumes it’s boot media is
> write-protected.
>
> Next, I don’t think users want a temporary Live Environment for USB usage.
> They probably want the programs they install and the changes they make to
> remain for next time. They also probably want the full capacity of the USB
> drive.
>
> That is problematic. Without spending the time to write our own custom
> “Write to USB” program, most will be stuck writing the standard USB images
> directly too the USB media. I don’t see us making our own custom image
> burner to stretch the filesystem for all the major OS platforms. So, that’s
> out for the foreseeable future.
>
> Probably most systems will only do USB HD emulation when booted from that
> USB drive (although I have some machines here that do it even when booted
> from the HD as long as the USB stick is inserted), the best solution I’ve
> come up with has been around for a while. More or less I refer to it as an
> OEM style install. I demonstrated it in a YouTube video with FreeDOS 1.2.
> Basically, you just write the USB install image to the drive. Then boot it
> and exit the installer. Use FDISK to create a separate partition on the 

[Freedos-devel] Contemplations, Considerations and some Conclusions

[Jerome Shidel]

Hello all,

I’ve got a couple thoughts regarding the OS release media I wanted to throw out 
to you all. These are just things I was pondering and by no means I’m I saying 
any of these are going to happen. They are just some ideas I’d like to share 
with you and get feedback on…

As you know, the LiveCD uses multiple boot images. A floppy one that starts the 
Live Environment. A second floppy one that launches directly into the 
installer. Finally, a third small hard disk image to run the FloppyEdition 
installer without need for OS level CD support. 

Do you think the FloppyEdition installer should be given it’s own entry in the 
CD boot menu? Or, leave it as an “EasterEgg” boot by selecting the copyright 
notice on the menu? 

Personally, I don’t see either as a perfect solution. If it is left as an 
EasterEgg, many people will never know it is there. Don’t forget, that 
installer does not need any OS level CD support. If a machine can boot it, it 
can pretty much install FreeDOS on anything. On the other hand, I think moving 
it to it’s own menu item will just confuse users by having 2 different “Install 
FreeDOS options”. 

Another possibility is drop the current “Install” option. Replacing it with the 
Floppy Edition. Maybe call it something like “Install FreeDOS BASE only.” After 
all, there is no problem running the primary installer from the Live 
Environment. But again, I think users will pick the wrong thing. 

This now brings me to the Legacy CD. 

It boots using a different process than the LiveCD (See numerous previous posts 
on those differences). This provides CD booting on a narrow range of hardware 
that can boot from CD but not use the method employed by the LiveCD. There is a 
CD Boot Floppy included in the LiveCD download zip archive. So, do we really 
need to keep the LegacyCD around? 

The emulated Floppy the LegacyCD boots is the same as the current LiveCD’s boot 
to install menu option. If the LegacyCD sticks around, the image it boot’s 
could be switched to the one used by the LiveCD’s boot to Live Environment. 
This would provide a Live Environment on that legacy hardware. But, then what 
would we call things. They’d both be LiveCDs. 

Finally (at least for now), along with the LiveCD and LegacyCD a CD boot floppy 
image is included. We could include a second floppy image to boot the Live 
Environment when direct booting from a CD is not possible. But, it could also 
cause confusion on what to use or burn to CD or Floppy. So, IDK.

I changed my mind. Thats not all just yet.

A lot of users want to run FreeDOS from USB. As I see it, there are several 
issues with that. 

First, you cannot guarantee that when booted from USB that drive will be 
writable. Personally, I’ve never seen when it was write protected. But, during 
the early days of developing the installer for 1.2, I learned that it was 
sometimes the case and attempts to use it for temp storage resulted in the 
users machine screaming very loud beeps and throwing write errors. So, the 
installer was modified and always assumes it’s boot media is write-protected. 

Next, I don’t think users want a temporary Live Environment for USB usage. They 
probably want the programs they install and the changes they make to remain for 
next time. They also probably want the full capacity of the USB drive. 

That is problematic. Without spending the time to write our own custom “Write 
to USB” program, most will be stuck writing the standard USB images directly 
too the USB media. I don’t see us making our own custom image burner to stretch 
the filesystem for all the major OS platforms. So, that’s out for the 
foreseeable future.

Probably most systems will only do USB HD emulation when booted from that USB 
drive (although I have some machines here that do it even when booted from the 
HD as long as the USB stick is inserted), the best solution I’ve come up with 
has been around for a while. More or less I refer to it as an OEM style 
install. I demonstrated it in a YouTube video with FreeDOS 1.2. Basically, you 
just write the USB install image to the drive. Then boot it and exit the 
installer. Use FDISK to create a separate partition on the USB drive and 
reboot. Because who knows what all drives are in the machine and how they will 
be ordered, use FDISK to verify the drive letter. If its drive D:, just run the 
installer again. If it is not drive D:, run the installer in advanced mode and 
tell it the appropriate drive. Once install completes, just reboot. It will 
boot into the installed partition. This leaves the original installer boot 
partition as a “OEM” style recovery partition. It also lets FDIMPLES use that 
recovery partition as a package source to add and remove addition programs. Not 
a perfect solution. But one I’ve used many times on internal hard drives and 
even USB sticks. 

Ok, finally for now (this time I mean it). 

We come to UEFI and modern hardware. With modern hardware vendors dropping 
support for