Re: [Freedos-devel] Status of NightDOS kernel?

[Mercury Thirteen via Freedos-devel]

"Officially" Night is in fact still an ongoing project. The problem is that I 
haven't had much time to devote to it for a while now, and I know Maarten and 
Antony have a lot going on as well. After completing a handful of other 
projects that have popped up, I will definitely be going back to Night.

As it stands, the Night kernel can actually multitask random chunks of code 
already in memory, but as of yet there's no protected memory, no API for 
loading actual COM or EXE applications, nor is there any implementation of the 
DOS API.

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

‐‐‐ Original Message ‐‐‐

On Sunday, January 16th, 2022 at 5:52 PM, Jim Hall jh...@freedos.org wrote:

> Does anyone know the current status of the NightDOS kernel effort?
>
> This is (was?) a project to create a 32-bit drop-in replacement for
>
> the FreeDOS kernel. Mercury was a key developer on this. But the
>
> "official dev thread" discussion on Google Groups seems to have
>
> stalled out in 2020, although there was some discussion about PDOS/386
>
> in 2021:
>
> https://groups.google.com/g/night-dos-kernel?fbclid=IwAR2Pg7wDqhKO8VsXrYCipKxgdEE1dvjVPmEPJyUI0oY2O5stpMPfBuZYooQ
>
> I was curious if NightDOS kernel was still ongoing.
>
> 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

[Freedos-devel] Status of NightDOS kernel?

[Jim Hall]

Does anyone know the current status of the NightDOS kernel effort?
This is (was?) a project to create a 32-bit drop-in replacement for
the FreeDOS kernel. Mercury was a key developer on this. But the
"official dev thread" discussion on Google Groups seems to have
stalled out in 2020, although there was some discussion about PDOS/386
in 2021:

https://groups.google.com/g/night-dos-kernel?fbclid=IwAR2Pg7wDqhKO8VsXrYCipKxgdEE1dvjVPmEPJyUI0oY2O5stpMPfBuZYooQ



I was curious if NightDOS kernel was still ongoing.


___
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] REMember a bug

[Steve Nickolas]

On Sun, 16 Jan 2022, Jim Hall wrote:


I have a paper copy of a few original MS-DOS manuals. My MS-DOS 4
manual says the only separators allowed in a comment are whitespace
but didn't mention redirection. But the MS-DOS 5 manual specifically
says *not* to use redirection in REM.

So this was a known issue in MS-DOS. It was later fixed in the Windows
CMD prompt, but the feature exists in MS-DOS COMMAND. And I think it's
important to meet the features of MS-DOS.

And it's a weird one, because one would think that REM would ignore
the *rest* of the line, like any comment. And that was probably the
intent, but that's not how it was implemented. Instead, you get MS-DOS
behavior like this:

REM > file.txt

..and then you get a zero-length FILE.TXT.

So I think the feature should stay as-is in FreeDOS. We implemented
this just like MS-DOS did. And that's good.


(I quoted a scanned manual from PC DOS 2.00, which was the first version 
that supported I/O redirection.  This behavior was documented there as 
well.)


-uso.


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

Re: [Freedos-devel] REMember a bug

[Jim Hall]

On Sun, Jan 9, 2022 at 1:19 PM tom ehlert  wrote:
>
>
> > As everyone knows and the docs clearly state, everything after a REM is 
> > ignored.
>
> > However, I recently noticed an issue with a batch file that had something 
> > like:
>
> > REM this thing [[x|4]] or later
>
> > in one of its remarks. Every time the batch was executed, it
> > displayed a “4]]” command not found error.
>
> > Out of curiosity, I checked under MS-DOS 6.22. It exhibited the
> > same behavior. I have a vague recollection of noticing this decades ago as 
> > well.
>
> > It is a bug. But, it’s a bug that MS-DOS has as well.
>
> > What’s you opinion? Should FreeCOM replicate this “feature” or  fix the bug?
>
>
> IMO that's a parsing problem.
>
> is it
> (1)REM WHATEVER
> or
> (2)command   |   command
>
> and even if *you* think this is a bug, by definition what MSDOS 6.22
> does is the definition of how to implement stuff (unless it's a really
> obvious bug which I don't see here).
>
> so it's more of a feature, then a bug.
>


I have a paper copy of a few original MS-DOS manuals. My MS-DOS 4
manual says the only separators allowed in a comment are whitespace
but didn't mention redirection. But the MS-DOS 5 manual specifically
says *not* to use redirection in REM.

So this was a known issue in MS-DOS. It was later fixed in the Windows
CMD prompt, but the feature exists in MS-DOS COMMAND. And I think it's
important to meet the features of MS-DOS.

And it's a weird one, because one would think that REM would ignore
the *rest* of the line, like any comment. And that was probably the
intent, but that's not how it was implemented. Instead, you get MS-DOS
behavior like this:

REM > file.txt

..and then you get a zero-length FILE.TXT.


So I think the feature should stay as-is in FreeDOS. We implemented
this just like MS-DOS did. And that's good.


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:

> [..]
> 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] FreeDOS virtual get-together on Sunday

[Jim Hall]

Thanks to everyone for joining today's FreeDOS virtual get-together! I
really appreciate getting to know everyone as more than just a name
behind an email.

Folks dropped in and out as they had time. I think we had a dozen
folks during the get-together.

We do these monthly, so if you weren't able to join today, you can
join us next time. We alternate topics for each video call; this month
was "social time," next month is "technical." See you then!


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

Re: [Freedos-devel] FreeDOS virtual get-together on Sunday

[Jim Hall]

On Sun, Jan 16, 2022 at 10:46 AM Ralf Quint  wrote:

> On 1/12/2022 12:58 PM, Jim Hall wrote:
> > I'll share the meeting info here in the hour leading up to the meeting.
>
> Did you oversleep? ;-)
>
>

No, but I completely forgot to share the invite an hour before the meeting.
:-)


Here's the invite:


Join Zoom Meeting
https://umn.zoom.us/j/95469585123?pwd=d1BsYUgxamdNRmFQTDUwWGg1M1Rtdz09

Meeting ID: 954 6958 5123
Passcode: 0Gycv1

Join by SIP
95469585...@zoomcrc.com

Join by H.323
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India Mumbai)
115.114.115.7 (India Hyderabad)
213.19.144.110 (Amsterdam Netherlands)
213.244.140.110 (Germany)
103.122.166.55 (Australia Sydney)
103.122.167.55 (Australia Melbourne)
209.9.211.110 (Hong Kong SAR)
149.137.40.110 (Singapore)
64.211.144.160 (Brazil)
69.174.57.160 (Canada Toronto)
65.39.152.160 (Canada Vancouver)
207.226.132.110 (Japan Tokyo)
149.137.24.110 (Japan Osaka)
Meeting ID: 954 6958 5123
Passcode: 560651
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] FreeDOS virtual get-together on Sunday

[Ralf Quint]

On 1/12/2022 12:58 PM, Jim Hall wrote:

I'll share the meeting info here in the hour leading up to the meeting.


Did you oversleep? ;-)

Ralf



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



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