freedos-user — FreeDOS general questions and other non-technical discussion

Re: [Freedos-user] Moving towards FreeDOS 1.4

[<je...@sh...>]

Well, I have been preparing all of the changes for the upcoming T2411 build.

This is a very big change. Much more was involved with getting it ready than for T2410.

For example, there are packages like the FDINST package (a subset of the FDNPKG) which do not actually exist anywhere but on the install media. 

Such packages are created by the RBE when building the Release Media. Moving FDNPKG from the UTIL to the NET group required going over the RBE and adjusting some things. 

There are also other packages which the RBE needs to know where they are located as well. 

After making the required adjustments, some test release builds, reviewing the build reports and a couple OS test installs, I think everything is ready for T2411 now.

Here are a couple things to expect with T2411.

ROMOS and ROMDSK packages have been dropped from the Media. Both contain binaries without the appropriate sources. We also do not have sources for those binaries in other packages. So, the “Boot Tools” only contains one package (SYSLNX) which I moved to the BonusCD. We may just want remove the BOOT group and move that package into DEVEL.

Some packages have been that are required by the operating system either with BASE or when FULL is selected, have been moved into a new group called TOOLS. 

The disk related packages in the Utilities group has been moved into a Disk Utilities group. Both of those groups have also been moved to the BonusCD.

Some packages that have been moved to the BonusCD were previously made Live when booting the Live Environment. They will no longer be made Live. 

Some of the packages still on the LiveCD and were made Live have been removed from that process. They are present and will get installed with the OS. They just are not automatically made Live anymore. A user can “install” packages into the Live Environment. 

The Editors group remains on the LiveCD for now. As discussed before, it may be moved to the BonusCD in T2412.

The Sound Tools group remains on the LiveCD for now. I’m unsure if we should move it. It contains programs like SBPMIXER that can be used to adjust the sound card volume and other settings. That may be very useful for changing settings to run games. Further discussion is is needed.

The Unix-Like Tools group remains on the LiveCD for now. At present, the primary FreeDOS installer requires grep to perform some splicing of user language and keyboard settings into the installed configuration. Eventually, I will incorporate the functionality which is needed from grep into one of the V8Power Tools programs to remove that need. But, I’m lazy and have not got around to doing that yet. If we move the UNIX-LIKE group to the BonusCD, for now, grep will need moved to the new TOOLS group.

( Side note… If a program/package is made needed by the Installer or made Live on the LiveCD, the package for that program must be on the LiveCD and will appear in FDIMPLES. )

I think that covers most of the important changes coming on Friday. 

After T2411, most of the packages on the FreeDOS GitLab Archive will have their unstable branches merged into their master branch. 

:-)

Jerome

Re: [Freedos-user] Moving towards FreeDOS 1.4

[Balázs S. <us...@pm...>]

This is crazy that HP does this.

Ekkor: K, okt. 29, 2024 20:33, Jim Hall via Freedos-user <[fre...@li...](mailto:Ekkor: K, okt. 29, 2024 20:33, Jim Hall via Freedos-user <<a href=)> írta:

> Jim Hall wrote:
> [..]
>> > One workaround (used on some HP laptops) is to book a minimal Linux
>> > environment, then launch a virtual machine like QEMU to boot FreeDOS
> [..]
>
> Michał Dec wrote:
>>
>> You mean like on literally everything. Not just HP laptops.
>>
>
> Yes, but HP literally does this with their "FreeDOS" laptops, so that
> was the example I was referencing when I said "used on some HP
> laptops." The HP "FreeDOS" laptop doesn't boot FreeDOS directly
> because of UEFI; instead, it boots a minimal Linux, which then boots
> QEMU, which loads FreeDOS.
>
> But you are correct that you can use this same method on other systems too.
>
> _______________________________________________
> Freedos-user mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Moving towards FreeDOS 1.4

[Jim H. <jh...@fr...>]

Jim Hall wrote:
[..]
> > One workaround (used on some HP laptops) is to book a minimal Linux
> > environment, then launch a virtual machine like QEMU to boot FreeDOS
[..]

Michał Dec wrote:
>
> You mean like on literally everything. Not just HP laptops.
>

Yes, but HP literally does this with their "FreeDOS" laptops, so that
was the example I was referencing when I said "used on some HP
laptops." The HP "FreeDOS" laptop doesn't boot FreeDOS directly
because of UEFI; instead, it boots a minimal Linux, which then boots
QEMU, which loads FreeDOS.

But you are correct that you can use this same method on other systems too.

Re: [Freedos-user] Moving towards FreeDOS 1.4

[Michał D. <mo...@gm...>]

If you can make a Libreboot firmware for your motherboard with CSM 
support then yes.

W dniu 29.10.2024 o 20:08, Balázs Szulovszky via Freedos-user pisze:
> Would it be possible to use Libreboot as an UEFI replacement for FreeDOS?
>
>
>
> Ekkor: K, okt. 29, 2024 19:58, Jim Hall via Freedos-user 
> <fre...@li... <mailto:Ekkor: K, okt. 29, 2024 
> 19:58, Jim Hall via Freedos-user <<a href=>> írta:
>> Rover wrote:
>> > > Wish Intel would create a BIOS emulation layer for booting 
>> DOS/FreeDOS
>> > > via EFI/UEFI. Ridiculous EFI/UEFI has no emulation layer for booting
>> > > older operating systems!
>> [..]
>> > > However, all likely outside the whelm [realm?] of FreeDOS.
>>
>> Ralf Quint wrote:
>> > Indeed. It would technically not impossible to create a boot "OS", 
>> that
>> > boots on a UEFI system, and then provides a BIOS emulation layer to
>> > allow for DOS (or other disadvantaged OS) to boot. But it is 
>> technically
>> > rather challenging for any outsiders to create something like this, as
>> > it requires to support all the various low level hardware out there
>> > these days....
>>
>> +1
>>
>> This would require creating some kind of UEFI "shim" that boots the
>> PC, provides BIOS services, then loads FreeDOS within that context.
>> It's not impossible, but very very hard (requires a ton of effort)
>> because you need to replicate the environment services that were
>> provided by default through hardware on a classic PC using BIOS.
>>
>> UEFI actually provided this kind of emulation using "Legacy" mode. But
>> that support was dropped by Intel around 2020. It's UEFI-only since
>> then, no "Legacy" support to provide any kind of BIOS.
>>
>> One workaround (used on some HP laptops) is to book a minimal Linux
>> environment, then launch a virtual machine like QEMU to boot FreeDOS.
>> But this loads an operating system just to load another operating
>> system. I suppose if you need hardware that is dedicated to running
>> DOS, that's a solution.
>>
>>
>> _______________________________________________
>> Freedos-user mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>
> _______________________________________________
> Freedos-user mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Moving towards FreeDOS 1.4

[Michał D. <mo...@gm...>]

You mean like on literally everything. Not just HP laptops.

W dniu 29.10.2024 o 19:58, Jim Hall via Freedos-user pisze:
> One workaround (used on some HP laptops) is to book a minimal Linux
> environment, then launch a virtual machine like QEMU to boot FreeDOS

Re: [Freedos-user] Moving towards FreeDOS 1.4

[Balázs S. <us...@pm...>]

Would it be possible to use Libreboot as an UEFI replacement for FreeDOS?

Ekkor: K, okt. 29, 2024 19:58, Jim Hall via Freedos-user <[fre...@li...](mailto:Ekkor: K, okt. 29, 2024 19:58, Jim Hall via Freedos-user <<a href=)> írta:

> Rover wrote:
>> > Wish Intel would create a BIOS emulation layer for booting DOS/FreeDOS
>> > via EFI/UEFI. Ridiculous EFI/UEFI has no emulation layer for booting
>> > older operating systems!
> [..]
>> > However, all likely outside the whelm [realm?] of FreeDOS.
>
> Ralf Quint wrote:
>> Indeed. It would technically not impossible to create a boot "OS", that
>> boots on a UEFI system, and then provides a BIOS emulation layer to
>> allow for DOS (or other disadvantaged OS) to boot. But it is technically
>> rather challenging for any outsiders to create something like this, as
>> it requires to support all the various low level hardware out there
>> these days....
>
> +1
>
> This would require creating some kind of UEFI "shim" that boots the
> PC, provides BIOS services, then loads FreeDOS within that context.
> It's not impossible, but very very hard (requires a ton of effort)
> because you need to replicate the environment services that were
> provided by default through hardware on a classic PC using BIOS.
>
> UEFI actually provided this kind of emulation using "Legacy" mode. But
> that support was dropped by Intel around 2020. It's UEFI-only since
> then, no "Legacy" support to provide any kind of BIOS.
>
> One workaround (used on some HP laptops) is to book a minimal Linux
> environment, then launch a virtual machine like QEMU to boot FreeDOS.
> But this loads an operating system just to load another operating
> system. I suppose if you need hardware that is dedicated to running
> DOS, that's a solution.
>
> _______________________________________________
> Freedos-user mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Moving towards FreeDOS 1.4

[Jim H. <jh...@fr...>]

Rover wrote:
> > Wish Intel would create a BIOS emulation layer for booting DOS/FreeDOS
> > via EFI/UEFI.  Ridiculous EFI/UEFI has no emulation layer for booting
> > older operating systems!
[..]
> > However, all likely outside the whelm [realm?] of FreeDOS.

Ralf Quint wrote:
> Indeed. It would technically not impossible to create a boot "OS", that
> boots on a UEFI system, and then provides a BIOS emulation layer to
> allow for DOS (or other disadvantaged OS) to boot. But it is technically
> rather challenging for any outsiders to create something like this, as
> it requires to support all the various low level hardware out there
> these days....

+1

This would require creating some kind of UEFI "shim" that boots the
PC, provides BIOS services, then loads FreeDOS within that context.
It's not impossible, but very very hard (requires a ton of effort)
because you need to replicate the environment services that were
provided by default through hardware on a classic PC using BIOS.

UEFI actually provided this kind of emulation using "Legacy" mode. But
that support was dropped by Intel around 2020. It's UEFI-only since
then, no "Legacy" support to provide any kind of BIOS.

One workaround (used on some HP laptops) is to book a minimal Linux
environment, then launch a virtual machine like QEMU to boot FreeDOS.
But this loads an operating system just to load another operating
system. I suppose if you need hardware that is dedicated to running
DOS, that's a solution.

Re: [Freedos-user] Moving towards FreeDOS 1.4

[Ralf Q. <fre...@gm...>]

On 10/28/2024 5:03 PM, Roger via Freedos-user wrote:
> Wish Intel would create a BIOS emulation layer for booting DOS/FreeDOS
> via EFI/UEFI.  Ridiculous EFI/UEFI has no emulation layer for booting
> older operating systems!
They don't care. Nor do any other (major!) players in the hardware field.
You need to realize that DOS is EOL for 30 years now, Apple already 
switched to ARM based computers and support only their own thing anyway. 
And older versions of Linux have the same problem, you can't boot them 
off a EFI/UEFI based system either.
>
> Also wishing for better comprehensible EFI/UEFI documenation.  (Could be
> just me getting older, but documentation seems lacking in some sense.)
It is certainly not "lacking", it is just much more (by magnitudes!) 
more complex than the BIOS approach ever was....
>
> However, all likely outside the whelm of FreeDOS.

Indeed. It would technically not impossible to create a boot "OS", that 
boots on a UEFI system, and then provides a BIOS emulation layer to 
allow for DOS (or other disadvantaged OS) to boot. But it is technically 
rather challenging for any outsiders to create something like this, as 
it requires to support all the various low level hardware out there 
these days....


Ralf

Re: [Freedos-user] Moving towards FreeDOS 1.4

[Roger <rog...@gm...>]

Wish Intel would create a BIOS emulation layer for booting DOS/FreeDOS
via EFI/UEFI.  Ridiculous EFI/UEFI has no emulation layer for booting
older operating systems!

Also wishing for better comprehensible EFI/UEFI documenation.  (Could be
just me getting older, but documentation seems lacking in some sense.)

However, all likely outside the whelm of FreeDOS.

As of now, think other non-bootable operating systems via EFI/UEFI will
likely become significantly less known, due to the forced submission of
EFI/UEFI.

Well, those are my thoughts about moving forward.


> On Sun, Oct 27, 2024 at 04:47:57PM -0500, Jim Hall via Freedos-user wrote:
>There have been enough changes during the FreeDOS monthly test
>releases that I think we should be moving towards FreeDOS 1.4.
>
> ...
>
>Thoughts?

Re: [Freedos-user] Moving towards FreeDOS 1.4

[EdzUp <edz...@gm...>]

Hi,
  personally I would like to see 'quarterly' updates instead of 1.3 >>> 1.4
you could have 1.3a, 1.3b etc every quarter this would mean people would
have more access to fixes at a quicker pace. On the whole as the updated
and fixes hit it would be nice to have some documentation somewhere where
we know its been fixed somewhere so we can download the fixed software as
well.

-Ed

On Sun, Oct 27, 2024 at 9:50 PM Jim Hall via Freedos-user <
fre...@li...> wrote:

> There have been enough changes during the FreeDOS monthly test
> releases that I think we should be moving towards FreeDOS 1.4.
>
> As discussed in the "Demo video on Youtube" thread (and elsewhere)
> we're seeing more folks who discover FreeDOS and complain about things
> that we've already fixed, like FDISK or HTML Help (or added new
> packages, like SBEMU and VSBHDA .. or removed some others, like oZone
> and Seal) in the monthly test releases. And other packages have had
> updates to add features, translations, etc. It's time to get an
> updated FreeDOS distribution out there.
>
>
> ** "1.4" or "2.0"?
>
> I think this distribution is "1.4" instead of "2.0" because we haven't
> seen the updated kernel for testing. If Jeremy sees this, maybe he can
> share the current status and point to test builds we can try. An
> updated kernel would justify going to "2.0" .. but if it's just
> package updates, it's "1.4"
>
>
> ** What I think is "on the table":
>
> This version is a "refresh" from FreeDOS 1.3, and will focus on newer
> versions of packages, and a "cleanup" of how the packages are put on
> each CD image. We have major improvements to FDISK, HTML Help, and
> other programs. Jerome's efforts to move packages around also helps to
> make the distribution smaller, possibly freeing up space for future
> inclusion of DJGPP.
>
> Questions/Answers:
>
> *HTML Help or AMB Help?
> I really like AMB Help. It's small, it looks great, and it's easy to
> use. But AMB Help requires converting documentation to "AMB" format.
> And while "AMB" is pretty straightforward, it requires a conversion
> tool. But HTML Help can read HTML files "on the fly" and there have
> been several good improvements to HTML Help that make it more
> reliable. So I have more reasons to prefer HTML Help than AMB Help.
>
> *DJGPP?
> I consider this an open question. We haven't included DJGPP in a test
> release until now. After T2411 (later this week) I think we can
> discuss if DJGPP should be added. But I don't want to "get ahead" of
> that conversation.
>
>
> ** What I think is not "on the table":
>
> (x) updated kernel - any new version will need a lot of testing. Once
> there's a new kernel available for testing, and we've tested it, we
> can plan "FreeDOS 2.0" at that time.
>
> (x) PC/GEOS - this hasn't been included in any test release until now.
> I understand the developers still say it's "not ready yet." If any
> PC/GEOS developers think otherwise, I encourage them to join the
> freedos-devel list to share the news. But even if PC/GEOS were ready
> today, this would also need a lot of testing. We can wait for "1.5" or
> "2.0" (whichever comes next) when PC/GEOS may have a release that they
> feel comfortable with other folks using, and that we are comfortable
> in including. That discussion (whether or not to include) would come
> later, after there's something to test.
>
>
> ** Schedule
>
> Let's use the monthly test releases to move this forward. That's how
> we planned to use the monthly test releases, anyway.
>
> T2411 will come out later this week, with more package changes. This
> also has changes to "package groups" to move things around, and better
> organize things. Jerome can share details, but we've discussed here
> about splitting up "Util" into "Tools" (like V8 Power Tools, etc) and
> "Disk Utils" (like dosfsck, etc) and "Util" (everything else). Let's
> take this a step at a time; after T2411, we can decide if we need to
> split up "Util" further (such as a new package group that includes
> "alternatives" like 'xdel' ['deltree' alternative] .. but I think this
> will be an easier decision after we see T2411.
>
> I think we'll need at least 2 more test releases before we have a "1.4
> candidate." The next 2 versions are T2411 and T2412, so T2501 might be
> a "1.4 candidate." After T2502 (the "final candidate") I think we
> could decide about turning T2402 into "FreeDOS 1.4." (In other words,
> that suggests "February 2025" to release FreeDOS 1.4.)
>
>
> ** Package freeze
>
> In the meantime, I'd like to limit adding new programs into the
> FreeDOS monthly test releases. That means no new kernel version, no
> PC/GEOS, etc. (but I'm open to discussing DJGPP after T2411, as
> mentioned above). Any updates to programs currently in the FreeDOS
> test release are okay. Any exceptions should be *carefully* managed.
>
>
> Thoughts?
>
>
>
>
> On Wed, Oct 23, 2024 at 11:56 AM Jim Hall <jh...@fr...> wrote in
> "Demo video on Youtube":
> >
> > I think this demonstrates that FreeDOS 1.3 is getting a bit old (2022)
> > and the monthly test releases have far outpaced it. For example, we
> > already dropped Seal and oZone in the monthly test releases; the test
> > releases have only had OpenGEM for some time.[1] We haven't added
> > PCGEOS yet, but I'd like to see how things go with shifting packages
> > between the LiveCD and BonusCD before we look at adding something
> > large like PCGEOS. Earlier test releases[2] added other critical
> > updates to packages. The package changes in T2410 were quite good, I'm
> > interested in testing the package changes in T2411. Basically, the
> > test release is *really good* and I think we should consider pushing
> > forward to turn a future monthly test release into a "FreeDOS 1.4."
> >
> >
> >
> > [1]The report from the monthly test release:
> >
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/report.html
> >
> > [2]The change log from the monthly test release:
> >
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/changes.log
> >
> >
> > On Wed, Oct 23, 2024 at 10:29 AM Liam Proven via Freedos-user
> > <fre...@li...> wrote:
> > >
> > > "Installing FreeDOS with OpenGEM, SEAL and Ozone GUI"
> > >
> > > https://www.youtube.com/watch?v=bS6iTNccgi4
> > >
> > > I am not a fan of videos and I only skimmed a few min of this.
> > >
> > > He demonstrates that Seal and Ozone are fairly broken and don't do
> > > much useful, which is my own opinion too. I nominate both for removal.
> > >
> > > He demonstrates that OpenGEM as shipped is broken. I've pointed this
> > > out here too. It's configured to run in the root directory of a drive.
> > >
> > > swsubst g: c:\opengem
> > >
> > > and then running it from G: works, as far as I can recall.
> > >
> > > He does find a fix, but I don't know how.
> > >
> > > He also demonstrates PGME -- but, as I have reported here again
> > > recently, his mouse does not work correctly.
> > >
> > > I suggest trying to get GEOS working and replacing GEM, Ozone and Seal.
>
>
> _______________________________________________
> Freedos-user mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>

[Freedos-user] Dual boot

[the <mrm...@gm...>]

Hi all,

 I have set up a dual boot menu with freedos and XP and a strange thing
happens all is fine if the boot is just set to freedos but when I try using
a multi boot the game graphics in freedos get scrambled (just a screen full
of multi coloured numbers)
My boot ini is as follows

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP
Professional" /fastdetect
C:\="FreeDOS"

Any clues on what could be happing?
Thanks

[Freedos-user] Moving towards FreeDOS 1.4

[Jim H. <jh...@fr...>]

There have been enough changes during the FreeDOS monthly test
releases that I think we should be moving towards FreeDOS 1.4.

As discussed in the "Demo video on Youtube" thread (and elsewhere)
we're seeing more folks who discover FreeDOS and complain about things
that we've already fixed, like FDISK or HTML Help (or added new
packages, like SBEMU and VSBHDA .. or removed some others, like oZone
and Seal) in the monthly test releases. And other packages have had
updates to add features, translations, etc. It's time to get an
updated FreeDOS distribution out there.


** "1.4" or "2.0"?

I think this distribution is "1.4" instead of "2.0" because we haven't
seen the updated kernel for testing. If Jeremy sees this, maybe he can
share the current status and point to test builds we can try. An
updated kernel would justify going to "2.0" .. but if it's just
package updates, it's "1.4"


** What I think is "on the table":

This version is a "refresh" from FreeDOS 1.3, and will focus on newer
versions of packages, and a "cleanup" of how the packages are put on
each CD image. We have major improvements to FDISK, HTML Help, and
other programs. Jerome's efforts to move packages around also helps to
make the distribution smaller, possibly freeing up space for future
inclusion of DJGPP.

Questions/Answers:

*HTML Help or AMB Help?
I really like AMB Help. It's small, it looks great, and it's easy to
use. But AMB Help requires converting documentation to "AMB" format.
And while "AMB" is pretty straightforward, it requires a conversion
tool. But HTML Help can read HTML files "on the fly" and there have
been several good improvements to HTML Help that make it more
reliable. So I have more reasons to prefer HTML Help than AMB Help.

*DJGPP?
I consider this an open question. We haven't included DJGPP in a test
release until now. After T2411 (later this week) I think we can
discuss if DJGPP should be added. But I don't want to "get ahead" of
that conversation.


** What I think is not "on the table":

(x) updated kernel - any new version will need a lot of testing. Once
there's a new kernel available for testing, and we've tested it, we
can plan "FreeDOS 2.0" at that time.

(x) PC/GEOS - this hasn't been included in any test release until now.
I understand the developers still say it's "not ready yet." If any
PC/GEOS developers think otherwise, I encourage them to join the
freedos-devel list to share the news. But even if PC/GEOS were ready
today, this would also need a lot of testing. We can wait for "1.5" or
"2.0" (whichever comes next) when PC/GEOS may have a release that they
feel comfortable with other folks using, and that we are comfortable
in including. That discussion (whether or not to include) would come
later, after there's something to test.


** Schedule

Let's use the monthly test releases to move this forward. That's how
we planned to use the monthly test releases, anyway.

T2411 will come out later this week, with more package changes. This
also has changes to "package groups" to move things around, and better
organize things. Jerome can share details, but we've discussed here
about splitting up "Util" into "Tools" (like V8 Power Tools, etc) and
"Disk Utils" (like dosfsck, etc) and "Util" (everything else). Let's
take this a step at a time; after T2411, we can decide if we need to
split up "Util" further (such as a new package group that includes
"alternatives" like 'xdel' ['deltree' alternative] .. but I think this
will be an easier decision after we see T2411.

I think we'll need at least 2 more test releases before we have a "1.4
candidate." The next 2 versions are T2411 and T2412, so T2501 might be
a "1.4 candidate." After T2502 (the "final candidate") I think we
could decide about turning T2402 into "FreeDOS 1.4." (In other words,
that suggests "February 2025" to release FreeDOS 1.4.)


** Package freeze

In the meantime, I'd like to limit adding new programs into the
FreeDOS monthly test releases. That means no new kernel version, no
PC/GEOS, etc. (but I'm open to discussing DJGPP after T2411, as
mentioned above). Any updates to programs currently in the FreeDOS
test release are okay. Any exceptions should be *carefully* managed.


Thoughts?




On Wed, Oct 23, 2024 at 11:56 AM Jim Hall <jh...@fr...> wrote in
"Demo video on Youtube":
>
> I think this demonstrates that FreeDOS 1.3 is getting a bit old (2022)
> and the monthly test releases have far outpaced it. For example, we
> already dropped Seal and oZone in the monthly test releases; the test
> releases have only had OpenGEM for some time.[1] We haven't added
> PCGEOS yet, but I'd like to see how things go with shifting packages
> between the LiveCD and BonusCD before we look at adding something
> large like PCGEOS. Earlier test releases[2] added other critical
> updates to packages. The package changes in T2410 were quite good, I'm
> interested in testing the package changes in T2411. Basically, the
> test release is *really good* and I think we should consider pushing
> forward to turn a future monthly test release into a "FreeDOS 1.4."
>
>
>
> [1]The report from the monthly test release:
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/report.html
>
> [2]The change log from the monthly test release:
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/changes.log
>
>
> On Wed, Oct 23, 2024 at 10:29 AM Liam Proven via Freedos-user
> <fre...@li...> wrote:
> >
> > "Installing FreeDOS with OpenGEM, SEAL and Ozone GUI"
> >
> > https://www.youtube.com/watch?v=bS6iTNccgi4
> >
> > I am not a fan of videos and I only skimmed a few min of this.
> >
> > He demonstrates that Seal and Ozone are fairly broken and don't do
> > much useful, which is my own opinion too. I nominate both for removal.
> >
> > He demonstrates that OpenGEM as shipped is broken. I've pointed this
> > out here too. It's configured to run in the root directory of a drive.
> >
> > swsubst g: c:\opengem
> >
> > and then running it from G: works, as far as I can recall.
> >
> > He does find a fix, but I don't know how.
> >
> > He also demonstrates PGME -- but, as I have reported here again
> > recently, his mouse does not work correctly.
> >
> > I suggest trying to get GEOS working and replacing GEM, Ozone and Seal.

Re: [Freedos-user] Demo video on Youtube

[tom e. <te...@dr...>]

Other things missing from anext major release: GPT support. Essentially done, but blcoker by our beloved chief maintainer.


Tom

[Freedos-user] FreeDOS > 1.3

[tom e. <te...@dr...>]

autodetetion of network cards.

When a packet driver is available, load it.

When not, load it via MS LANMANAGER

   NDIS
   NDISPKT

available in the public since 2001 (!), but apparently not sexy enough for anybody to pick up.

and saves so much of "Try this, try that"



it would also be cool to have as many packer drivers *ON ONE SITE* as possible
without trying 20  different ones.


Tom

Re: [Freedos-user] Demo video on Youtube

[tom e. <te...@dr...>]

Hallo Herr Eric Auer via Freedos-user,

am Mittwoch, 23. Oktober 2024 um 22:02 schrieben Sie:


> Hi!

> I agree that the monthly releases have many good updates.
> For FreeDOS 1.4, we should finally add WfW 3.11 compatible
> kernel and related tools (maybe share exe etc.?) as well.

DEFINITIVELY NOT!

It seems that since some time there exists a kernel hanging around with
rumored capabilities "WfW 3.11 compatible kernel and related tools" but nowhere to be seen in the wild.

I have no idea why not everybody else is able to look at the source  changes, and test the binary, as this kernel 
(and this kernel alone + possibly some config.sys changes) can easily be broadcast to millions of testers
without any problem.

Where are all these testers and their expreriences?

Are there known problems and workarounds?

etc. etc.

The probability that our beloved coder (for some reason known as Perdition) gets everything right in all contexts
on HIMEM/EMM386/HXDOS/..., in the context of DOS LAN-MANAGER, divers package drivers, sound card emulators, and what not
is exactly 0%, unless he did little but test this kernel the last 5 years.

Putting this new kernel as a first of light into a new FreeDOS package is exactly kernel 1.37(unstable) reloaded.


After thsi kernel is **STABLE**  put it into a freedos package and call it 1.4


or call it 1.4 because Fritz Mueller fixed a spelling bug in the turkish helpfile for EDLIN, I don't care

Tom

Re: [Freedos-user] A new mTCP is available ...

[Michael B. <mbb...@br...>]

I'm not sure if you checked, but the source code for HTTPServ is also not
included.  Both of those exceptions are noted in the documentation.

If you are going to remove HTTPSERV and NetDrive due to a lack of source
code (and that is fair), please include an extra README file in their place
that explains why they are not present.  It should explicitly mention that
they do not meet FreeDOS requirements for having source code available.


-Mike

Re: [Freedos-user] A new mTCP is available ...

[<ts...@so...>]

Why not just include a txt version of the documentation, then mention 
the url for a full featured version of the manual in pdf format.  That 
would help those that can't get to the pdf, but allow those wanting the 
formatting/colorization/so on to grab the documentation in pdf format.  
The text documentation won't be nearly as large as the pdf, so it won't 
take up 3MB in the archive.


On 10/26/2024 4:55 AM, Jerome Shidel via Freedos-user wrote:
> Hi Mike,
>
>> On Oct 24, 2024, at 6:36 PM, je...@sh... wrote:
>>
>>
>>
>>> On Oct 23, 2024, at 9:08 PM, Michael Brutman via Freedos-user 
>>> <fre...@li...> wrote:
>>>
>>> I'd like to ensure that you get it for the next test releases, but 
>>> yes, I'd like to have some way to gauge interest too ...
>>>
>>> Another potential discussion point is the PDF documentation - it's 
>>> large.  Would shipping a text file that says "find the full 
>>> documentation at this location" be a problem?  I feel bad shipping a 
>>> 3MB PDF file on FreeDOS knowing that most people are not going to 
>>> open it under FreeDOS.  (If they are so bold I can even include the 
>>> command line for the HTGET program to fetch the PDF.)
>>
>> Well, I guess since there is not a good way to view it under DOS, it 
>> won’t matter if the PDF is not included.
>>
>> I have not looked at the latest release yet. But, it would be nice if 
>> there was at least some subset or partial manual included that 
>> covered the more common things. Which could point to the online PDF 
>> for more detailed or additional information. But, it is probably 
>> simpler and safer to just include a note that says “go here” to read 
>> the manual.
>>
>> :-)
>
> I was working on updating the mTCP package for the next FreeDOS 
> Interim Test Build (T2411) and I noticed a small issue.
>
> While it includes the NetDrive binaries, there are no NetDrive sources 
> in the sources zip file. I could not find a separate sources file for 
> NetDrive on your site.
>
> I know in previous discussions you mentioned that eventually you would 
> make the sources for NetDrive available. But at that time, you were 
> not ready to do that.
>
> Since we need to include sources in the package for FreeDOS, I can 
> simple remove NetDrive from our package until you are ready to provide 
> the sources for it.
>
> Since the previous package for mTCP include the PDF documentation, 
> I’ve will included it for now in the new package. But, I think it is 
> of limited use under DOS. Plus as you mentioned, it is large and a 
> note with the URL or a batch to download it may be a far better choice.
>
> :-)
>
> Jerome
>
>
>
> _______________________________________________
> Freedos-user mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] A new mTCP is available ...

[<je...@sh...>]

Hi Mike,

> On Oct 24, 2024, at 6:36 PM, je...@sh... wrote:
> 
> 
> 
>> On Oct 23, 2024, at 9:08 PM, Michael Brutman via Freedos-user <fre...@li... <mailto:fre...@li...>> wrote:
>> 
>> I'd like to ensure that you get it for the next test releases, but yes, I'd like to have some way to gauge interest too ...
>> 
>> Another potential discussion point is the PDF documentation - it's large.  Would shipping a text file that says "find the full documentation at this location" be a problem?  I feel bad shipping a 3MB PDF file on FreeDOS knowing that most people are not going to open it under FreeDOS.  (If they are so bold I can even include the command line for the HTGET program to fetch the PDF.)
> 
> Well, I guess since there is not a good way to view it under DOS, it won’t matter if the PDF is not included. 
> 
> I have not looked at the latest release yet. But, it would be nice if there was at least some subset or partial manual included that covered the more common things. Which could point to the online PDF for more detailed or additional information. But, it is probably simpler and safer to just include a note that says “go here” to read the manual. 
> 
> :-)

I was working on updating the mTCP package for the next FreeDOS Interim Test Build (T2411) and I noticed a small issue.

While it includes the NetDrive binaries, there are no NetDrive sources in the sources zip file. I could not find a separate sources file for NetDrive on your site. 

I know in previous discussions you mentioned that eventually you would make the sources for NetDrive available. But at that time, you were not ready to do that. 

Since we need to include sources in the package for FreeDOS, I can simple remove NetDrive from our package until you are ready to provide the sources for it. 

Since the previous package for mTCP include the PDF documentation, I’ve will included it for now in the new package. But, I think it is of limited use under DOS. Plus as you mentioned, it is large and a note with the URL or a batch to download it may be a far better choice.

:-)

Jerome

Re: [Freedos-user] A new mTCP is available ...

[Magnus W. <ma...@ka...>]

On Wed, Oct 23, 2024 at 03:20:13PM -0700, Michael Brutman via Freedos-user wrote:
> Version 2024-10-20 is available.  It has a few bug fixes.  It also allows
> mTCP programs to operate at the same time NetDrive is active.  (If you know
> how packet drivers work, that is no small track.)
> 
> Download links are here: https://www.brutman.com/mTCP/mTCP.html
> 
> That page is currently redirecting to a 40 year old PCjr with no hard drive
> that has been running over 700 hours.  Because that's what good testing
> looks like. :-)  The link above is the real, long term link though as
> sometimes the PCjr has to do other things.
> 
> 
> -Mike


> _______________________________________________
> Freedos-user mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-user

Hello Michael!

I hadn't heard of NetDrive before, so I gave this a spin in a virtual machine
running FreeDOS. It worked very well! I connected to your demo service and played
around with it.

I have some hardware in my office that I will try this on during the weekend (a 486 and
a Pentium running various versions of DOS). It looks like a great way to share files
between them. I can also see how it would be useful to share and test floppy-images
that I have dumped throughout the years. Way easier than putting them all on the Gotek.

Thanks a lot for sharing, and for your work on this!

/Magnus

Re: [Freedos-user] PDF documentation

[Karen L. <kle...@sh...>]

I personally use a service via email, its called robobraille.

www.robobraille.org
Do not let the name fool you, braille is the least of what they do.

convert to rtf or html, or audio for example, and yes plain text.
Convert to quite a few languages as well.
so I convert files to rtf or html or more often text, download them and 
use Wordperfect to read them.
on very rare occasion's I use the pdf to text tool included with 
shellworld's hosted Ubuntu shell service.  they have one for word, 
antiword, rtf, unrtf, and docx docx2txt.
Karen



On Fri, 25 Oct 2024, tsiegel--- via Freedos-user wrote:

> Me personally, I turn most pdf files into html or plain text before viewing, 
> since it loads my browser to view the stupid thing, I figure it may as well 
> be in a native format.  The only problem is, the pdftohtml program puts each 
> page in it's own file, which is fine for some things, not so much for 
> others.  I do use a lot of text, but unfortunately, there's absolutely no 
> attempt made to maintain formatting when it converts to text, so we get lines 
> that are typically too long for most editors.
>
> I use it anyway, because it works with things liek grep, more and other text 
> manipulation tools, which pdf does not. *grumble*
>
>
> On 10/24/2024 10:56 PM, Ben Collver via Freedos-user wrote:
>> >  Date: Thu, 24 Oct 2024 16:58:30 +0200
>> >  From: Jose Senna <jas...@ma...>
>> > 
>> >     Michael Brutman said:
>> > >   I feel bad shipping a 3MB PDF file on FreeDOS knowing
>> > >  that  most people are not going to open it under FreeDOS.
>> > 
>> >     What are the present means to open a .PDF file
>> >    under FreeDOS (or any DOS, BTW) ?
>>  There are several options, but i prefer to convert a .PDF to
>>  72 DPI jpeg pages, then use an image viewer.
>>
>>  gs -r72x72 -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -sDEVICE=jpeg
>>       -dJPEGQ=90 -o page%03d.jpg file.pdf
>>
>>  The AlphaBits options cause ghostscript to use antialiasing.
>> 
>>
>>  _______________________________________________
>>  Freedos-user mailing list
>>  Fre...@li...
>>  https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>
> _______________________________________________
> Freedos-user mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>

Re: [Freedos-user] PDF documentation

[<ts...@so...>]

Me personally, I turn most pdf files into html or plain text before 
viewing, since it loads my browser to view the stupid thing, I figure it 
may as well be in a native format.  The only problem is, the pdftohtml 
program puts each page in it's own file, which is fine for some things, 
not so much for others.  I do use a lot of text, but unfortunately, 
there's absolutely no attempt made to maintain formatting when it 
converts to text, so we get lines that are typically too long for most 
editors.

I use it anyway, because it works with things liek grep, more and other 
text manipulation tools, which pdf does not. *grumble*


On 10/24/2024 10:56 PM, Ben Collver via Freedos-user wrote:
>> Date: Thu, 24 Oct 2024 16:58:30 +0200
>> From: Jose Senna <jas...@ma...>
>>
>>    Michael Brutman said:
>>   >  I feel bad shipping a 3MB PDF file on FreeDOS knowing
>>   > that  most people are not going to open it under FreeDOS.
>>
>>    What are the present means to open a .PDF file
>>   under FreeDOS (or any DOS, BTW) ?
> There are several options, but i prefer to convert a .PDF to
> 72 DPI jpeg pages, then use an image viewer.
>
> gs -r72x72 -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -sDEVICE=jpeg
>      -dJPEGQ=90 -o page%03d.jpg file.pdf
>
> The AlphaBits options cause ghostscript to use antialiasing.
>
>
> _______________________________________________
> Freedos-user mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] PDF documentation

[Ben C. <ben...@ri...>]

> Date: Thu, 24 Oct 2024 16:58:30 +0200
> From: Jose Senna <jas...@ma...>
> 
>   Michael Brutman said:
>  >  I feel bad shipping a 3MB PDF file on FreeDOS knowing
>  > that  most people are not going to open it under FreeDOS.
> 
>   What are the present means to open a .PDF file
>  under FreeDOS (or any DOS, BTW) ?

There are several options, but i prefer to convert a .PDF to
72 DPI jpeg pages, then use an image viewer.

gs -r72x72 -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -sDEVICE=jpeg
    -dJPEGQ=90 -o page%03d.jpg file.pdf

The AlphaBits options cause ghostscript to use antialiasing.

Re: [Freedos-user] A new mTCP is available ...

[Michael B. <mbb...@br...>]

Thanks,

The web server is a nice way to test the TCP/IP library.  It needs to
handle multiple connections concurrently, fetch real files from disk, and
deal with the random noise/garbage that comes in on port 80.  So far the
machine has been up for 770 hours straight. It's gone over 5,000 hours in
the past.  For this test I removed the hard drive and it's using NetDrive
(remote attached storage) for the mTCP code and the files that are being
served.  I think the code is probably stable. ;-0

The machine itself is a 4.77Mhz PCjr running PC DOS 5.02.  (One day I might
get around to fixing FreeDOS so that it will boot and run natively on the
machine.)  It has a floppy drive to boot from and an Ethernet adapter
hanging off of the parallel port because the machine doesn't have ISA
slots.  It would be so much faster with a real Ethernet adapter, but I need
some electrical engineering help to make that happen.


-Mike

Re: [Freedos-user] A new mTCP is available ...

[<je...@sh...>]

> On Oct 23, 2024, at 9:08 PM, Michael Brutman via Freedos-user <fre...@li...> wrote:
> 
> I'd like to ensure that you get it for the next test releases, but yes, I'd like to have some way to gauge interest too ...
> 
> Another potential discussion point is the PDF documentation - it's large.  Would shipping a text file that says "find the full documentation at this location" be a problem?  I feel bad shipping a 3MB PDF file on FreeDOS knowing that most people are not going to open it under FreeDOS.  (If they are so bold I can even include the command line for the HTGET program to fetch the PDF.)

Well, I guess since there is not a good way to view it under DOS, it won’t matter if the PDF is not included. 

I have not looked at the latest release yet. But, it would be nice if there was at least some subset or partial manual included that covered the more common things. Which could point to the online PDF for more detailed or additional information. But, it is probably simpler and safer to just include a note that says “go here” to read the manual. 

:-)

> 
> 
> -Mike
> 
> 
> On Wed, Oct 23, 2024 at 5:59 PM Jerome Shidel via Freedos-user <fre...@li... <mailto:fre...@li...>> wrote:
> Hi,
> 
>> On Oct 23, 2024, at 6:20 PM, Michael Brutman via Freedos-user <fre...@li... <mailto:fre...@li...>> wrote:
>> 
>> Version 2024-10-20 is available.  It has a few bug fixes.  It also allows mTCP programs to operate at the same time NetDrive is active.  (If you know how packet drivers work, that is no small track.)
> 
> :-) :-) 
> 
>> 
>> Download links are here: https://www.brutman.com/mTCP/mTCP.html <https://www.brutman.com/mTCP/mTCP.html>
>> 
>> That page is currently redirecting to a 40 year old PCjr with no hard drive that has been running over 700 hours.  Because that's what good testing looks like. :-)  The link above is the real, long term link though as sometimes the PCjr has to do other things.
>> 
>> 
>> -Mike
> 
> Like with previous releases, I assume you want us to hold off a bit before updating the FreeDOS packages. 
> 
> :-)
> 
> Jerome
> _______________________________________________
> Freedos-user mailing list
> Fre...@li... <mailto:Fre...@li...>
> https://lists.sourceforge.net/lists/listinfo/freedos-user <https://lists.sourceforge.net/lists/listinfo/freedos-user>
> _______________________________________________
> Freedos-user mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] A new mTCP is available ...

[Jim H. <jh...@fr...>]

On Wed, Oct 23, 2024 at 5:21 PM Michael Brutman via Freedos-user
<fre...@li...> wrote:
>
> Version 2024-10-20 is available.  It has a few bug fixes.  It also
> allows mTCP programs to operate at the same time NetDrive is active.
> (If you know how packet drivers work, that is no small track.)
>
> Download links are here: https://www.brutman.com/mTCP/mTCP.html
>
> That page is currently redirecting to a 40 year old PCjr with no hard
> drive that has been running over 700 hours.  Because that's what good
> testing looks like. :-)  The link above is the real, long term link
> though as sometimes the PCjr has to do other things.
>
> -Mike

Thanks! I'll make an announcement on the website so others see it too.


(Also: very cool that you're running your website from a DOS machine!)


Jim