Re: [Freedos-devel] FreeDOS T2209

[Jerome Shidel]

Hi,

> On Sep 1, 2022, at 11:08 PM, Jim Hall  wrote:
> 
> 
> 
> 
>> On Thu, Sep 1, 2022, 6:59 AM Jerome Shidel  wrote:
>> (...)
>> Since we have not made a final decision on how many or where to keep 
>> previous test builds, I simply placed the old T2208 under 
>> 
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/previous/T2208/
>> 
>> (...)
> 
> 
> 
> Didn't we decide to keep one older version: the current year build at test 
> and the previous test build at test.old?

I wasn’t sure if it was a decision or something we were still considering. 

No problem.

Tomorrow I’ll move T2208 from test/previous/T2208/ to simply test.old/.

:-)

Jerome

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

Re: [Freedos-devel] Ré : FreeDOS T2209

[Jerome Shidel]

> On Sep 1, 2022, at 9:46 AM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> the report.htm seems up to date... but the title is still about T2208, and it 
> says it was built: 
> Monday August  1, 2022 at 05:56:27 AM EDT

You probably need to refresh your browser or dump it’s cache.



> 
> 
> 
> ___
> 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] FreeDOS T2209

[Jerome Shidel]

Hello all,

The FreeDOS interim test build T2209 is now available for download at

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


Primary changes since T2208:

2022-08-21 15:03:44 curl (shidel): updated to v7.84.0
2022-08-21 13:53:47 edlin (shidel): update to v2.21
2022-08-21 09:17:22 pgme (shidel): Improved mouse compatibility
2022-08-09 15:23:58 project_FD-NLS (shidel): report update
2022-08-09 10:43:04 sort (shidel): NLS: Update FR and TR for SORT
2022-08-09 10:12:14 project_FD-NLS (shidel): Merge pull request #141 from 
cardpuncher/master
2022-08-09 16:38:46 project_FD-NLS (cardpuncher): Add files via upload
2022-08-04 17:23:31 himemx (shidel): updated to v3.37
2022-08-03 21:19:16 keyb (Aitor Santamaría): XT class fixes by Davide Bresolin
2022-08-03 07:40:26 fbc (shidel): updated to version 1.09.0
2022-08-03 07:27:29 fbc_help (shidel): updated to version 1.09.0
2022-08-03 00:48:14 keyb (Aitor Santamaría): Fix codepage issues
2022-08-03 00:21:08 keyb (Aitor Santamaría): More control over allocation 
strategy (/NOUMB)

Since we have not made a final decision on how many or where to keep previous 
test builds, I simply placed the old T2208 under 

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/previous/T2208/
 


Going forward, I think we have a couple practical ways to handle it.

1) Always place all interim builds under there version under test. For example, 
test/T2208, test/T2209 and when next moth comes out test/T2210. And so on.

2) Place the latest build under test (current location) and retire them to 
directories life test/T2208. 

3) Just keep the current placements of test for current build and directories 
like test/previous/T2208 for retired builds. However, if we only keep one or 
two previous builds around, this seems like an unnecessary extra directory 
layer. 

And obviously, we will need to decide how many old test builds to keep around. 

:-)

Jerome


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

Re: [Freedos-devel] Editing LSM files under Linux (code page considerations)

[Jerome Shidel]

Hi,

> On Aug 31, 2022, at 2:36 PM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> 
> I am trying to do a 12.2.0 packagte for GCC.
> I am editing LSM files on Linux... and beginning to ask myself how much bad 
> it is.
> I means... I am probably transforming them to UTF-8 unicode... so the 
> codepage indicated in the file would be wrong now.
> And if  I would edit them in DOS... I would have to change code page before 
> editing any of them... I would guess.
> So... can I edit them in UTF-8 unicode... is there a tool that check that and 
> add the modified-date?
> 

First, you don’t need to worry about the modified-date field. If the field is 
not present, the repository management utilities will add it automatically when 
the package is added to a repository. 

As for the basic LSM meta-data file, that needs to be in DOS codepage 437. 

The language specific files in that directory must be in the appropriate DOS 
codepage for that language. The fields in those language specific files work 
like overrides to the standard English version (LSM). 

For example, the English contains a version field. But, that field is excluded 
from the language specific version. So, when the version is updated, all 
languages show the new version. However, each language has its own description 
and summary field. So, those are shown for that language instead of the default 
English when using programs like FDIMPLES. 

For packages that are kept on the official repository and/or provided on the 
various release media, there is some additional things to be consider.

The master English meta-data always lives in the packages. However, the 
translations for the package metadata lives over at the FD-NLS project[1] in a 
couple big language specific CSV files. 

That data gets staged in the GitLab FreeDOS Archive[2]. Which is used to 
assemble packages for the releases and for the update repository on ibiblio[3].

The easiest way to edit those massive CSV files for the language specific 
metadata is through the FD-NLS Desktop App[4] that I created. There are 
Windows, Linux and macOS versions. 

The app is pretty code at editing those and does all the UTF/Codepage 
conversion stuff automatically. It has a live simulation/preview of what the 
metadata will look like in DOS using FDIMPLES and some other features.

Eventually, it will support working on actual translations for the individual 
programs as well as their metadata. But unfortunately, I just don’t have the 
time to work on it at present.

:)

Jerome

[1] https://github.com/shidel/fd-nls
[2] https://gitlab.com/FreeDOS
[3] 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/indexes.html
[4] https://up.lod.bz/FDNLS_LNX




> ___
> 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] No simple cpu identification program returning an error code as an answer?

[Jerome Shidel]

Hi all,

When it comes to releasing something as public domain, I think “The Unlicense” 
(aka CC0) is a great choice and maintains the spirit of public domain.

Basically it says, do whatever you want with it. But, don’t blame me if it 
doesn’t work or breaks something.

https://opensource.org/licenses/Unlicense

It is also a recognized open source license.

:-)

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

Re: [Freedos-devel] Why there is no two versions of FreeDOS: 16 bits and 32 bits?

[Jerome Shidel]

> On Aug 25, 2022, at 4:10 AM, Eric Auer  wrote:
> [..]
>> It seems there is a lot of programs that cannot run on 8086...
> 
> Those should be excluded in 8086 installs, but as far as
> I remember, at least one of the installers already pays
> attention to that. Mateusz and Jerome might know more :-)

Since a user is most likely not going to have either a CD or USB drive in a 
system that is not at least a 386, the CD and USB media will install programs 
that require s 386. Those also boot the 32bit kernel.

The Floppy Edition boots the 16bit kernel. It installs based on hardware 
capabilities. At present, you must tell it to limit its install to only 8086, 
186 or 286 machines. Otherwise, it will assume at least a 386 level of support. 
Eventually when I have the time (and feel like it), I will get around to 
updating the CPU detection and auto detection of sub-386 machines.




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

Re: [Freedos-devel] GitLab - problem with codepages

[Jerome Shidel]

Hi, 

> On Aug 2, 2022, at 7:15 PM, Andrew Bird via Freedos-devel 
>  wrote:
> 
> Hi Aitor,
> 
> On Wed, 3 Aug 2022 00:37:29 +0200
> Aitor Santamaría mailto:aitor...@gmail.com>> wrote:
> 
>> Hi,
>> 
>> I am trying to adapt to work with GIT from the GitLab repository, and am
>> committing a couple of changes on FD-KEYB that I had ready.
>> 
>> However, I have noticed a problem with the codepages. I try to avoid
>> non-ASCII characters, but seldomly use those that are common to most
>> codepages.
>> What I see is that neither the character stored (that the web omits) or the
>> character committed (strange character) are correct, which obviously didn't
>> happen when I simply committed a ZIP file with everything:
>> 
>> [image: image.png]
>> 
>> I can live with them and try and take all characters from ASCII, but I am
>> just worried if the sources at GIT would all be affected by this apparent
>> codepage problem.
>> 
>> Maybe someone more expert on GIT than myself can add something on this.
>> 
>> Aitor
> 
> The thing is that git stores text files internally as UTF-8, so unless
> any uploaded text file has a match in the .gitattributes file it's assumed to 
> be that (or
> binary if can't be interpreted as UTF-8). Consequently any diff shown
> is anybody's guess as to what codepage it might be encoded in. You
> could set .gitattributes to match each codepage which might make sense
> for nls files etc, like I have done for some projects like find (you'll see 
> that the diff is rendered properly)
> https://github.com/FDOS/find/commit/f763ce94f837e15c2e865e8fc333f8ca8396d427 
> 
>  . Though ideally we'd keep all master translation files in UTF-8 format and 
> translate to specific codepages at build time.
> If the problematic file is a source code file, then I'd tend to encode it in 
> UTF-8 format as any special chars are likely to be in comment sections and so 
> have no bearing upon output.
> 
> Hope it helps, Andrew

There some things I’ve noticed while doing the FD-NLS project on GitHub and the 
Archive on GitLab regarding DOS Codepage files.

Basically, some of the code page translation files, when viewed through the web 
interface, show incorrect characters. However, checking out the project (or 
cloning) it back to a local machine shows the files were not changed and the 
codepage was preserved. 

The biggest problem I’ve found is modern editors mangling codepages or 
incorrect codepages being used for a given language. In part that is why I 
started the FD-NLS Desktop App. 

Overall, It is probably a good idea to include a UTF-8 version of any 
translated text along with the codepage versions.

Jerome

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

Re: [Freedos-devel] Interim FreeDOS Build T2208

[Jerome Shidel]

Hi Eric,

> On Aug 1, 2022, at 2:18 PM, Eric Auer  wrote:
> 
> 
> Hi! Trying to sort through the log on
> 
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/changes.log
> 
> it seems that most changes are NLS updates, build infrastructure,
> documentation and similar. Actual app changes seem to be those:
> 
> - Sayswho (Senso) game now with Adlib sound
> - WDE update to 0.99? 0.30b? 3.0c??

Well, several years back, when we were fixing License information and other 
meta data, WDe had its version changed from 3.0b to 3.0c to not confuse package 
installation, management software and whatnot. However, doing that confused a 
lot of people.

I recently noticed WDe had an update. However, it was v0.99. This caused me to 
examine the 3.0b package more closely. As it turned out, it was labeled 
incorrectly the whole time. It was not v3.0b. It was v0.30b. 

So, I fixed the version number for the existing package from v3.0c to v0.30b. 
Then updated it to v0.99.

> - MCTP update to 2022-07-01
> - JWASM update to 2.15
> - DOSLFN 0.41f "extending directory fixes"
> - VMSMOUNT 0.5c
> - LINKS 2.27
> - SBPMIXER added
> - XDEL 2.08
> - FASM 1.73.30
> - HIMEMSX 3.54
> - JEMM 5.81
> - DOJS 1.8.0
> - DOSZIP 2.63
> - UTF8TOCP 0.9.4 (also mostly infrastructural)
> - MEM 1.12
> - GOPHERUS 1.2.1
> - EUPHORIA 3.2.2
> 
> Maybe this list would be useful for an announcement, while the
> log is more for providing a chronological under-the-hood view
> of internal changes :-)
> 
> Regards, Eric
> 
> PS: Let me know if I overlooked additions or updates of apps/drivers!

I think that is all the updated packages. But, I’m not at my computer right now 
and cannot easily compare the log against the list.

:-)

Jerome

> 
> 
> 
> ___
> 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] Interim FreeDOS Build T2208

[Jerome Shidel]

Hi, 

> On Aug 1, 2022, at 10:51 AM, tom ehlert  wrote:
> 
> Hallo Herr Jim Hall,
> 
> am Montag, 1. August 2022 um 16:08 schrieben Sie:
> 
>>> Hi! I agree it would be good to have a changelog visible before
>>> downloading those 100s of megabytes
>> [..]
> 
 I think it's pretty rude behaviour wrt the testers to throw once per
 month 500 MB with a bazillion of subprojects at the testers, with only
 'please test this' without any mentioning of
>> [..]
> 
> 
>> I think folks may have missed that there's a changelog in the Interim
>> Test Build directory:
> 
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/changes.log
> 
>> From my reading of the changelog, almost all of the changes in this
>> Interim Test Build from FreeDOS 1.3 are NLS updates, plus some version
>> updates of other packages like dojs, jemm, gopherus, and a few others.
> 
> so we should test the version numbers?
> 
> 2022-02-25 06:46:13 gopherus (Shidel): v1.2.1
> 2022-03-02 13:54:44 utf8tocp (Shidel): v0.9.4
> 
> is not a changelog. a changelog explains the what and why of the
> change. not that the change resulted in a new version number.
> 
> version numbers of the packages contained should be possible to obtain 
> somewhere
> else, even if the package didn't change.
> 
> Tom

You are correct that it is not a change log for the programs themselves (like 
gopherus and utf8tcp). 

It is however a changeling for the Release itself. Using your example, the 
Release was updated to v1.2.1 and v0.9.4 for those packages. (I  should 
probably commit with messages like “updated to v1.2.1” instead of just 
“v1.2.1”. I do need to work on improving my commit messages.) 

Anyone who would be interested in what changed when updated to v1.2.1 would 
need to examine the change.log for that specific package.

In part, that is because few packages have their development repository in the 
FreeDOS Archive on GitLab and are maintained elsewhere. In part, it is because 
the different developers maintain their change.logs in different ways with 
different formats. In part, it is because highly active projects would pollute 
the release change log and possibly the log mostly worthless. But perhaps for 
convenience, it would be better to include those when possible.

An example of such pollution is all those “NLS: Package and Description update” 
entries. After Wilhelm and Berki updated the package descriptions at FD-NLS for 
DE, FR & TR, I ran an automation tool. It checked each packages LSM metadata 
and updated it when needed. It also imported any new translations for those 
packages. Once that was done, if there were any changes, it pushed the updates 
to the FreeDOS Archive. There were a lot of minor changes spread across nearly 
all packages. In the future, I may have the RBE filter out such things.

The exception to all that is a couple packages that live in the Archive. Like 
the FDHELPER package. Also projects used directly by the RBE to build the 
release are included. Like the RBE itself, FD-NLS, FDI and FDI-x86 get all of 
their messages (with some filtering) included. 

This is the first interim build and automated change log creation for the 
release. 

No doubt there will be changes. (which I’ll need to remember to log)

:-)

Jerome

> 
> 
> 
> 
> ___
> 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] Interim FreeDOS Build T2208

[Jerome Shidel]

Hi Jim,

> On Aug 1, 2022, at 7:32 AM, Jim Hall  wrote:
> 
> 
> Do you want me to post this as a news item on the website?

Probably a good idea. Also, maybe Facebook and Twitter. The more testers the 
better. 

I figured I’d just mention it here. Then leave all the other “public” 
announcement stuff to you. :-)

> 
> My first thought is Yes, because this is a good way to engage folks who want 
> to test FreeDOS. And I think it's good to let folks know about the Interim 
> Test Builds. At the same time, I'd want to be clear in that news post that 
> this is a test build, so things may be broken, or incomplete, etc, because 
> it's meant for testing and is not meant to be a new version of the official 
> distribution.
> 
> I don't think we'd want to post news items about every test build, though. I 
> think that would be too much.

Those were my thoughts as well. 

Probably be good to mention that it is planned for a new one to be created 
monthly. Probably, the 1st of the month. Unless we feel it’s better to do it on 
a different schedule.

The build will include all changes to date. May be very little. May be a lot. 
In the event there are no changes, then one won’t be released. But, I assume 
that will be rare. 

> 
> But I wanted to ask what you preferred.

When T2209 is release, I think I will move T2208 into a sub-directory under 
test. Basically….

…/test/- current test build
…/test/T2208/   - old test build

Then we can keep as many old ones around as we want. 

> 
> 
>> On Mon, Aug 1, 2022, 5:19 AM Jerome Shidel  wrote:
>> Hi Jim and All,
>> 
>> The 1st FreeDOS interim test build is up and available for download at:
>> 
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/
>> 
>> :-)
>> 
>> Jerome
> ___
> 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] Interim FreeDOS Build T2208

[Jerome Shidel]

Hi Jim and All,

The 1st FreeDOS interim test build is up and available for download at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ 


:-)

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

Re: [Freedos-devel] MS-DOS compatibility issue

[Jerome Shidel]

Hi,

> On Jul 31, 2022, at 5:46 AM, tom ehlert  wrote:
> 
> 
>> interesting find. did you try any of the alternatives DRVLOAD, DEVLOD,
>> DDL ...
> 
> a compilation of devload, drvload, loadsys
> http://toogam.com/software/archive/drivers/dosstart/dosstart.zip
> 
> Tom

Ok, this is interesting….

I tried a couple loaders in the zip (reboot between tries).

DEVLOAD, either version, failed.
DRVLOAD, failed.
LOADSYS, failed.

CTLOAD, passed and ANSI detected. 

So, the issue is most likely with DEVLOAD. 
Possibly, something it is doing or neglecting to do. 

:-)

Jerome

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

Re: [Freedos-devel] MS-DOS compatibility issue

[Jerome Shidel]

Hi,

> On Jul 31, 2022, at 3:49 AM, TK Chia  wrote:
> 
> Hello Jerome,
> 
>>> Generally, I would not include an attachment. However, this is a
>>> tiny zip and includes the test source, build scripts and the compiled 
>>> version.
> 
> Well... I found that your ansitest.com still works with the FreeDOS 1.3
> kernel + nansi.sys 4.0d.  (I.e. there was no regression between FreeDOS
> 1.0 and 1.3.)
> 
> I took a FreeDOS 1.3 "floppy edition" boot disk image, and doctored it
> so that it loads nansi.sys on startup and does not start the installer,
> then ran it under QEMU.  ansitest.com says "ANSI supported".
> 
> (I will try to enclose a floppy disk image once I manage to pare it down
> to a small enough size...)
> 
> Are you using devload.com to load the nansi.sys driver?  If so, this
> might explain the failure.  I found that if I use devload.com --- rather
> than load the driver through fdconfig.sys --- then for some reason
> nansi.sys's input handling routines are not triggered, and there is no
> ESC [ y ; x R response.  This would mean there is an issue in devload.com.

I did not see your message until now. However, it did not take long to narrow 
down.

I did some testing under VirtualBox and it didn’t take long to when the issue 
occurs.

I saw almost immediately that when booting with NANSI.SYS in the config 
file the test passes successfully. However, post boot loading using DEVLOAD 
(high or low) would cause the test to fail detection.

This is occurs even when nothing other than the SHELL= is in the config with an 
empty 
autoexec. 

So, my test results match yours and it is easy to replicate.

Finding the actually issue may be a little more complicated.

I’m suspecting the issue may not be NANSI itself. 

:-)

Jerome



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

Re: [Freedos-devel] MS-DOS compatibility issue

[Jerome Shidel]

Hi again,

> On Jul 30, 2022, at 4:51 PM, Jerome Shidel  wrote:
> 
> Hi,
> 
>> On Jul 30, 2022, at 3:03 PM, TK Chia  wrote:

I just created a boot floppy with 1.3’s Kernel, Command, NANSI and the Test 
program. 

Loaded Command and NANSI to low memory with nothing else in the CONFIG.SYS and 
nothing in an AUTOEXEC.BAT.

Booted the Pentium Pro and ran the test.

Result: Ansi supported.

So, this will take some CONFIG testing to find out what is breaking MS-DOS 
compatibility. 

:-)

Jerome

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

Re: [Freedos-devel] MS-DOS compatibility issue

[Jerome Shidel]

Hi,

> On Jul 30, 2022, at 3:03 PM, TK Chia  wrote:
> 
> Hello Jerome,
> 
>> The test works correctly under at least the most recent versions of MS-DOS 
>> (6.x), PC-DOS and DR-DOS.
> 
> Thanks.  Well, I could not reproduce whatever failure you were getting
> with your routine under FreeDOS.  Without more information, it seems
> there is no good way to tell what exactly went wrong.
> 
> What I tried was to write a small wrapper program around your ANSI
> detection code (https://gitlab.com/-/snippets/2379985), assemble and
> link it with wasm and owcc, and run it under FreeDOS 1.0 + Eric Auer's
> nansi.sys 4.0d.
> 
> The program should return errorlevel 1 if it detects ansi.sys, and
> indeed it did return errorlevel 1.
> 
> So again, I guess more information is needed on what failed on your end.
> 
> Thank you!

Well to simplify matters, I ported the test to a simple NASM  program. It 
displays Supported or Not and returns errorlevel 1 if not found. 

I did a quick check on the PentiumPro under MS-DOS 6.22 + ANSI.SYS, it says 
supported.
Rebooted the PentiumPro under FreeDOS 1.3 + NANSI.SYS, it says NOT supported. 

Generally, I would not include an attachment. However, this is a tiny zip and 
includes the test source, build scripts and the compiled version. 



ANSITEST.7z
Description: Binary data


The problem could possibly be one of the other drivers and may not be NANSI 
itself. Further testing will be needed starting with a KERNEL + COMMAND + NANSI 
only boot. 

:-)

Jerome

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

Re: [Freedos-devel] MS-DOS compatibility issue

[Jerome Shidel]

HI,

> On Jul 30, 2022, at 2:15 AM, TK Chia  wrote:
> 
> Hello Ralf Quint,
> 
>> Well, not having comments to understand what you are doing is pretty
>> tough when you don't have the time to analyze the code line by line. But
>> IIRC, the common way to check for the presence of an ANSI device driver
>> was to check via an INT 2Fh (multiplexer) call (don't recall the exact
>> call value (AX/AH)).
>> 
>> Will take a closer look at this later this evening when I am back, I am
>> heading out to this year's SCaLE conference... ;-)
> 
> What Jerome's code does is to send an `ESC [ 6 n' sequence and try to
> check (in a particular way) if the console responds with a "keyboard
> input" sequence of the form `ESC [' ... `R CR'.
> 
> About these sequences, the Linux console_codes(4) man page says,
> 
> "ESC [ 6 n
> 
> "Cursor position report (CPR): Answer is ESC [ y ; x R, where x,y
> is the cursor location.
> "
> 
> Thank you!
> 
> --
> https://gitlab.com/tkchia
> 

Correct.

The test works correctly under at least the most recent versions of MS-DOS 
(6.x), PC-DOS and DR-DOS. 

As Tom said, it would most likely fail (and return FALSE) if the display was 
over a network connection. However, adding a simple WAIT and TIMEOUT would 
probably solve that. Usage over a remote VT100 terminal connection was probably 
something I was thinking about at the time. That is also most likely one of the 
reasons it completely avoids the BIOS for the probe.

:-)

Jerome

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

[Freedos-devel] MS-DOS compatibility issue

[Jerome Shidel]

Hi All, 

While recently performing a re-install of everything (System Commander Multiple 
DOS, Windows, Linux booting) on my Pentium Pro, I discovered a minor 
compatibility issue regarding ANSI.SYS support. Without digging into it more, I 
cannot say if the issue is NANSI.SYS or elsewhere in FreeDOS.

Basically, one of the versions of my ancient (written back in the early 90’s) 
Turbo Pascal directory listing programs used ANSI escape sequences to provide 
color. Instead of blindly assuming ANSI support is present, it first probes DOS 
to verify the functionality. It performs the probe through standard DOS I/O 
function calls and works on other DOS platforms (such as MS-DOS, PC-DOS and 
DR-DOS). However, the test fails under FreeDOS.

  function DetectAnsi : boolean; assembler;
asm
  MOV  DI, OFFSET @AnsiTestStr
@2:
  MOV  DL, CS:[DI]
  INC  DI
  CMP  DL, 0
  JE   @3
  MOV  AH, $02
  INT  $21
  JMP  @2
@3:
  MOV  AH, $06
  MOV  DL, $FF
  INT  $21
  JZ   @5
  CMP  AL, 27
  JNE  @5
  MOV  AH, $06
  MOV  DL, $FF
  INT  $21
  JZ   @5
  CMP  AL, '['
  JNE  @5
@4:
  MOV  AH, $06
  MOV  DL, $FF
  INT  $21
  JZ   @5
  CMP  AL,'R'
  JNE  @4
@5:
  MOV  AH, $06
  MOV  DL, $FF
  INT  $21
  JZ   @6
  CMP  AL,13
  JNE  @5
  MOV  AL, True
  JMP  @Done
@6: { Not Found }
  MOV  DI, OFFSET @AnsiTestStr
@7:
  MOV  DL, CS:[DI]
  INC  DI
  CMP  DL, 0
  JE   @8
  MOV  AH, $02
  MOV  DL, 8
  INT  $21
  MOV  AH, $02
  MOV  DL, 32
  INT  $21
  MOV  AH, $02
  MOV  DL, 8
  INT  $21
  JMP  @7
@8:
  MOV  AL, False
  JMP  @Done
@AnsiTestStr:
  DB 27,'[6n',0
@Done:
  MOV  AnsiFound, AL
end;

Sorry, I was never one for doing a lot of code comments. And yes, it is far 
from efficient, elegant or pretty. But, the snippet of code is roughly 30 years 
old.

:-)

As you can see, it sends an escape sequence to request information. If it 
receives the data, the test passes. Otherwise, it cleans up the displayed 
garbage and moves along without ANSI support. 

I wouldn’t call it a serious compatibility issue. Even this ancient directory 
lister provides support to bypass the probe and force ANSI support OFF or ON. 
dir l:

Interestingly, this same program reveals a couple other cross DOS compatibility 
issues as well. For example, under MSDOS using MSCDEX + OAKCDROM driver, the CD 
can be listed. It also likes NWCDEX + OAKCDROM under DR-DOS. However, not under 
FreeDOS using our supplied drivers (invalid drive reported) and crashes (divide 
by zero) when accessing the CD under PC-DOS with IBMIDECD + MSCDEX.

Anyhow, the program source is available on GitHub under 
https://github.com/shidel/DustyTP7/tree/master/D 
 and a precompiled binary at 
https://github.com/shidel/DustyTP7/blob/master/bin/D.EXE 
 

:-)

Jerome





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

Re: [Freedos-devel] FreeDOS Unstable - interim development builds

[Jerome Shidel]

Hi Mercury and Jim,

> On Jul 17, 2022, at 7:32 PM, Mercury Thirteen via Freedos-devel 
>  wrote:
> 
> In addition to "unstable", another practice commonly used by other software 
> projects for interim builds like those you're discussing here is to title 
> them based on their frequency, e.g. "nightly" or "weekly", etc. Perhaps this 
> would be the way to go?

That they do. Not a bad idea.

However, we are looking at once a month. 

To me, FreeDOS Monthly sounds like a magazine. LOL. :-)


>>> On Jun 22, 2022, at 1:05 PM, Jim Hall jh...@freedos.org wrote:
>>> 
>>> I like the idea of the interim development builds. This should be a
>>> great way to test new changes that everyone can experiment with!
>>> Thanks for doing this.
>>> 
>>> I'm thinking about how people will (mis)interpret the "FreeDOS
>>> Unstable" name. I wonder if "FreeDOS Test" might be a better name for
>>> this.
> 
> On Wed, Jun 22, 2022 at 1:22 PM Jerome Shidel jer...@shidel.net wrote:
> 
>> I don’t think “Unstable" would cause much confusion. I think it
>> is a well understood and established term for such releases. Many
>> users are familiar with it from the Linux world. However, it is not
>> a big deal to switch it from using the “Unstable” to “Test”
>> or “Devel”. Maybe it’s a good question to put to your usability
>> class.
> 
> 
> The usability course is in the Spring semester, so that's a long time. :-)

Yeah, i don’t think we want to wait that long. :-)

> But in my experience, I think "test" or "devel" is a better label than
> "unstable." While "unstable" may be a term well known by other
> developers, remember that ordinary users will find it, and will get
> confused by "unstable.”

I think to normal users those terms would leave the following impressions…

TEST - Hey, this is not a release. It is something we are trying out. If it 
works out and we like it, we will probably continue doing something like it for 
future releases. 

DEVEL - This is mostly for developers, But, you can check out what we are 
working on. But, It’s not quite finished. So, expect it to get better.

UNSTABLE - This is what we are working on. It’s not ready for general use and 
expect to have some issues. But if you like the cutting edge and don’t mind 
having some hiccups, give it a whirl. 

Although each implies something a little different, they each leave a fairly 
similar impression to me.

I don’t think using TEST will cause any user confusion. So lets go with that. 
:-)

> 
>>> The benefit of "Test" is that it is short enough to combine with
>>> the "year+month" label and stay conveniently within an "8.3" filename,
>>> so you have "TEST2207" and "TEST2208" and so on. (I know "8.3" names
>>> aren't necessary for the web server, but it's a nice symmetry for
>>> FreeDOS.)
>> 
>> Actually, not quite… For example, each of the media get’s it’s
>> own volume label to help differentiate them. For example, with 1.3 the
>> CD boot floppy was “FD13-BOOT” but the image to boot directly from
>> the LegacyCD is “FD13-LBFI”. So for all of those, they get labeled
>> things like U2206-BOOT and U2206-LBFI.
> 
> 
> I guess the 8.3 filename doesn't matter as much to me, that was just a
> suggestion because "test" was conveniently short. But I'll add that we
> probably don't need to worry about 8.3 filenames for the download zip
> file. "FD13-LiveCD.zip" and "FD13-BonusCD.zip" from FreeDOS 1.3 didn't
> use 8.3 filenames for the download. So the interim build download
> files could have longer names that are more descriptive.
> 
> I'm not sure what "LBFI" stands for, though. I'm bad at remembering
> acronyms. (I live by the old 1990s joke, "PCMCIA stands for People
> Can't Memorize Computer Industry Acronyms.”)

During a release build by the RBE, all media gets a unique disk label. Mostly, 
this is to allow manually verification that the correct image is being used for 
different things. For example, although the installer is the same across all 
standard media (excluding the Floppy Edition), the media may boot with 
different configurations or settings in FDCONFIG and FDAUTO. 

A great example is the FreeDOS 1.3 LiveCD. If you boot the Live Environment, 
the CD boots one Floppy Image (FD13-HYDRA). However, booting that CD to Install 
to Hard Disk uses a different floppy image (FD13-CDBI). 

As for the meaning behind all the labels…

FD13-BOOT   - Boot diskette (Separate boot floppy image for running 
installer, included in ZIP archives for LiveCD and LegacyCD)

FD13-LBFI   - 

[Freedos-devel] Online Get-Together

[Jerome Shidel]

It’s well past 11am CT. I guess there is not going to be an online get-together 
today.

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

Re: [Freedos-devel] Another implementation of GRAFTABL

[Jerome Shidel]

Hi,

> On Jul 12, 2022, at 6:19 AM, Steve Nickolas  wrote:
> [..]
> For some reason I don't understand (me am n00b) the footprint is 144 bytes 
> larger than the MS-DOS 5/6 version, but the binary is smaller.

I haven’t looked at the code for either. But, there are some things in general 
to consider with TSRs.

I would assume the memory footprint difference may be related to optimization 
of the executables layout and data storage. Basically, when you return to DOS, 
you release all the memory you don’t need. So, you store all the data you do 
need to keep in the beginning of the program. At start, jump past it and do all 
the initialization stuff. Then free everything you don’t need when you call the 
terminate-but-stay-resident interrupt. 

You could even use areas of the PSP (program segment prefix) to store some 
data. For example, once processed, you could move data into the PSP command 
line buffer. Another thing, is to free the env segment. Maybe even Shuffle your 
own data and code around at run-time. 

Lots of tricks like that. 

:-)

Jerome 


 


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

Re: [Freedos-devel] FreeDOS Edlin 2.21 is here!

[Jerome Shidel]

Hi Gregory, 

> On Jun 26, 2022, at 9:22 PM, Gregory Pietsch  wrote:
> 
> After I released FreeDOS Edlin 2.20 onto an unsuspecting world, I noticed a 
> couple of items I needed to address in the source code. In an effort to 
> produce a more perfect FreeDOS Edlin, I have addressed those issues and 
> released FreeDOS Edlin 2.21 to SourceForge! Please send me feedback….

Do you have any plans to push an update the GitLab Archive version 
https://gitlab.com/FreeDOS/base/edlin  ? 
It is still at version 2.19.

Or, are you waiting to see if there are any issues? If that is the case, we 
could push it to an “unstable” branch. Then it would get included in the 
interim development build. However until we got around to merging that into the 
master branch, it would not be included in the next OS Release.

:-)

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

Re: [Freedos-devel] FreeDOS interim development build

[Jerome Shidel]

Hi,

> On Jun 25, 2022, at 4:41 PM, Aitor Santamaría  wrote:
> 
> Hello,
> 
> Thanks for the answers!

Your Welcome.


> On Sat, 25 Jun 2022 at 22:32, Jerome Shidel  <mailto:jer...@shidel.net>> wrote:
> For example, if KEYB on the GitLab archive has a commit pushed with the 
> comment “Fixed double keypress bug”. That comment would appear in the 
> CHANGES.LOG as something like “2022-06-29 04:52:11 keyb (Aitor Santamaría): 
> Fixed double keypress bug”
> 
> Ok, commit logs are a good source too, but this advices to write good 
> (user-readable) commit logs.

Yep, absolutely. It’s something I need to work on myself as well. :-)

> 
> [..]
> Basically, yes. There is a separate software update repository for maintained 
> for each of OS release.
> 
> It would be for each major, or for every unstable too? (in the latter, it'd 
> require a lot of space, right?)

I think for each major release. Plus, just one “unstable” update repository 
should be good. I don’t think the interim builds should be looked at as a 
specific release. I think they should be viewed as a single ongoing process 
towards the development of the next release. 

Yes. Especially if we kept each interim build around, that would use quite a 
lot of space. I figure roughly 2GB for each interim build. Plus all the update 
files. Roughly 3gb total each month really adds up. 12 months later, 36gb added 
to the server. Ouch.

:-)

Jerome

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

Re: [Freedos-devel] FreeDOS interim development build

[Jerome Shidel]

Hi Aitor,

> On Jun 25, 2022, at 3:22 PM, Aitor Santamaría  wrote:
> [...]
> How do these logs build up? (I am assuming logs in an user-readable format). 
> Every time someone updates a tool, do we need to fill in somewhere?
> Ideally, the implemented bugs and enhancements from GitLab would go to the 
> list, but I guess the ticketing system is not being widely used. ANother 
> option would be that every time a new version comes, instead of logging 
> somewhere else, someone simply logs a new enhancement ticket in GitLab with 
> the changelog.

The packages are all sourced from the GitLab Archive. A couple other key 
components to the release (like FDI, FD-NLS, RBE, etc) are pulled from their 
own GitHub/GitLab projects. The CHANGES.LOG is created using the commit comment 
messages for each project. 

For example, if KEYB on the GitLab archive has a commit pushed with the comment 
“Fixed double keypress bug”. That comment would appear in the CHANGES.LOG as 
something like “2022-06-29 04:52:11 keyb (Aitor Santamaría): Fixed double 
keypress bug”

Also if for example that same commit was made to a branch (other than 
master/main) as a "test fix”, it would be identified as such in the LOG. By 
default, the interim builds check for an “unstable” branch and will use that 
instead of the master/main branch when creating a build. That would look like 
“2022-06-29 04:52:11 keyb [unstable] (Aitor Santamaría): Fixed double keypress 
bug”

For projects that are maintained elsewhere and just get copied and adjusted 
into the GitLab Archive, they usually just get a version number. However, we 
can include more information in the commit message. For example, I updated 
DOSLFN to v0.41f yesterday. It’s logged as "2022-06-24 08:54:13 doslfn 
(shidel): v0.41f - More extending directory fixes and basic version check”

It’s possible that we may include a compatible CHANGE.LOG for the maintained 
elsewhere projects in their GitLab Archive’s version. But, I’m not sure that is 
necessary or desirable. They get the version number comment and if someone is 
interested they could check that projects change.log. After all, it’s not 
actually changes that we would have made. IDK.

> 
> Finally, what path on ibiblio do you want to use to provide package updates? 
> This has nothing to do with creating the interim build. As you recall, the 
> current RBE uses the GitLab FreeDOS Archive (https://gitlab.com/FreeDOS 
> ) to create the packages on the release. It can 
> also automatically pull specific branches of those packages based on the 
> release, interim, development or other type of build it is creating. The 
> package update url only applies to where the release / interim build will 
> check for package updates. 
> 
> I think it makes sense to keep it along side the other OS update 
> repositories. There are already repositories for each Release
> 
>   1.1 - 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.1/ 
> 
>   1.2 - 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.2/ 
> 
>   1.3 - 
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/ 
> 
> I don't know if I am getting this well: this means that in the 1.2 folder you 
> find the packages updated over 1.2? 
> This means that if at this moment there appears a new updated package that 
> hasn't been updated earlier, it should go into ALL of the 1.1, 1.2 and 1.3 
> folders?

Basically, yes. There is a separate software update repository for maintained 
for each of OS release.

This supports the ability for packages under different OS versions to use 
different paths, settings, options, versions or other differences. However, 
generally there is no difference in the actual update packages for each 
release.  The repository management utility has no problem maintaining a bunch 
of separate repos. When an update is made to a package, we can just drop a zip 
in one of a couple directories on the server. The repo management stuff will 
grab it, stick it into the proper repository, generate file-system links, 
versioned webpages, etc. However, it will have at 1 copy of the update zip in 
each of the update repositories.

When I eventually get around to making the next version of the repo management 
utilities, it will be able eliminate multiple cross-repo duplicates and 
conserve wasted disk space. That along with desktop clients to more easily 
manage them, multi-repo comparison, syncing and numerous other improvements. 
But, I’m just one person and it keeps getting put off in favor of other more 
immediate needs. Someday hopefully, I will get to it. 

> 
> AItor

:-)

Jerome

___
Freedos-devel 

[Freedos-devel] FreeDOS interim development build

[Jerome Shidel]

Hi Jim and all,

Well, the work I wanted to do to the RBE and release media is finished. I’ve 
replaced the downloads on my server with the new versions. You can fetch them, 
or view the report information at https://fd.lod.bz/releases/unstable/ 
 

Mostly, the additional stuff I wanted to get in there came down to two more 
things mentioned earlier. The interim builds include a warning message 
displayed at boot (from install media and one the installed system). Also, the 
interim build uses a different theme for the installer. Basically the theme is 
the same as the normal mode except instead of a blue background, it is black.

In order for us to have the first interim build officially available on 7/1, 
there are a couple minor items that need a final decision…

First, how will we Label and refer to these builds? I went with “Unstable” with 
the short name would be “FreeDOS U2207” and long name as “FreeDOS 
2206-Unstable”. To me, it is a well established nomenclature. However to the 
general user base, that may not be the case. We could use “Unstable” for now 
and possible change it later. But, I think we should commit to a scheme and 
stick with it for the foreseeable future.

Should we stick with “Unstable” or use…

Test build; FreeDOS 2207; FreeDOS 2207-TEST
Development build; FreeDOS DEV2207; FreeDOS 2207-DEVEL

Or, some other specific terms or variation?

Second, do we want the changes log to go back as far as the previous interim 
build or back to the previous OS release? At present, it limits itself to the 
previous build. But since users / testers will probably not test every 
iteration, I think it may be best to always include everything back to the 
previous official release. At present that would be FreeDOS 1.3-Final. 

Third, what path do we wish to provide them on ibiblio under 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/ 
 ?

I prefer 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unstable 

 or 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unstable/2207
 

 

But, we could use dev, devel, or test. I don’t think unofficial/dev is 
the best choice and suggests it is not an official test version. But, that 
could just be me. As always, whichever you decide is best. 

Finally, what path on ibiblio do you want to use to provide package updates? 
This has nothing to do with creating the interim build. As you recall, the 
current RBE uses the GitLab FreeDOS Archive (https://gitlab.com/FreeDOS 
) to create the packages on the release. It can 
also automatically pull specific branches of those packages based on the 
release, interim, development or other type of build it is creating. The 
package update url only applies to where the release / interim build will check 
for package updates. 

I think it makes sense to keep it along side the other OS update repositories. 
There are already repositories for each Release

1.1 - 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.1/ 

1.2 - 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.2/ 

1.3 - 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/ 


I think using 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/ 

 makes sense. It also makes it easy for users running one of the Official 
Release versions (1.1, .1.2, 1.3) to find and try the latest versions of 
package updates. However if you think renaming it to something like “TEST” or 
“DEV” is a better choice, it is easy to adjust. The repository management 
utility is flexible with such things and at is also not a problem to put it in 
an entirely different directory not under “repositories”. 

Let me know what changes you want. None of theses changes are that difficult or 
time consuming. Hopefully, we will can make the first interim build available 
on  7/1. 

:-)

Jerome


 


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

[Freedos-devel] FreeDOS Unstable - CHANGES.LOG

[Jerome Shidel]

Hi,

> On Jun 22, 2022, at 6:26 PM, Eric Auer  wrote:
> 
> 
> Hi!
> 
>> Changes since FreeDOS 1.3 release
>> 2022-06-22 10:02:08 project_RBE (shidel): Adjust interim build file names
>> 2022-06-22 09:13:23 project_RBE (shidel): Automatic Unstable Build Versioning
>> 2022-06-21 09:21:37 project_FD-NLS (shidel): added FreeDOS release README to 
>> NLS project
>> 2022-06-19 20:43:04 project_FD-NLS (cardpuncher): Add files via upload
>> 2022-06-19 19:51:27 project_FD-NLS (shidel): from W.Spiegl
>> …
>> 2022-06-17 23:29:30 project_FD-NLS (Andrew Bird): Fixup incorrect UTF-8 file 
>> extension suffix
>> 2022-06-13 14:46:45 sbpmixer (Shidel): Initial commit
>> 2022-06-13 10:50:00 sbpmixer (shidel): v2.0
>> 2022-06-06 21:32:25 project_FD-NLS (cardpuncher): Add files via upload
>> 2022-06-03 06:53:06 project_FD-NLS (shidel): W.Spiegl
>> 2022-05-30 10:38:58 project_FD-NLS (shidel): Codepage corrections
>> 2022-05-26 10:42:04 xdel (shidel): v2.08
>> 2022-05-24 02:31:32 xdel (shidel): v2.07
>> 2022-05-17 07:40:47 fasm (shidel): v1.73.30
> 
> How about those kernel updates which allegedly make FreeDOS compatible with 
> Windows for Workgroups WfW 3.11 beyond safe mode, and with Windows 3.x 386enh 
> mode, which were both not supported by previous kernels?

I should go into a little more detail regarding the automatic CHANGES.LOG. 

First, the log is created from the git commit messages from where the the RBE 
pulls files to create a build (interim or release). 

project_RBE is the RBE itself. project_FD-NLS, project_FDI and project_FDI_x86 
are those respective projects. These are not FreeDOS packages. However, they 
are used directly by the RBE during release creation. The RBE also creates a 
SOURCES package based on the FDI project for inclusion on the install media. 

Other message entries (like sbpmixer, xdel, fasm, etc.) are generated from 
their commits to the appropriate project staged in the FreeDOS Archive 
(https://gitlab.com/FreeDOS ). While some programs 
are maintained there, most are not. 

For the ones maintained elsewhere, the Archive must be manually updated at 
present. That involves coping the files, possibly compiling, arranging them 
into package format, updating metadata and other adjustments. When they are 
committed to the archive, they generally just get a version update commit 
message. Like xdel v2.07 and v2.08. Since it is maintained over at 
https://github.com/FDOS/kernel , this would be 
the same for the kernel. For those, you would need to visit that specific 
project to view individual changes. Perhaps at some point, we could include 
such “SOURCE LOGS” in the Archive for those and they could be included by the 
RBE.

The RBE also filters out a bunch of commit messages. For example, to maintain 
correct file timestamps the package maintenance utility fdvcs.sh pushes an 
additional commit regarding timestamps gets filtered out. Also, simple 
individual package NLS updates are filtered. Consecutive commits with identical 
messages gets pruned and some additional filtering is performed. Without the 
filtering, just the commits since the last release was maybe a dozen or so 
pages long and bloated with useless and duplicate information. With the 
filtering, it is now about a page or two and much more relevant.  

However, the FD-NLS project gets a lot of updates and ends up with many entries 
in the LOG. But if those are of little interest, you could easily filter them 
out locally with grep.

Also, the CHANGES.LOG only includes changes since the prior build. For 
Releases, this will be all changes back to the prior Release (at present 
v1.3-Final) and for interim builds the previous interim build (generally one 
the last month). Although, it may be better for the interim build to include 
all changes back to the previous Release.

Finally, the CHANGES.LOG is all of those updates combined and sorted in reverse 
order. They are also included in the RBE build report. However, there they are 
broken down by project / package. For packages that have been modified, the 
entry in the main list includes an in-page link to the appropriate list of 
changes. You should check out the new report… 
https://fd.lod.bz/releases/unstable/report.html 
 

:-)

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

Re: [Freedos-devel] FreeDOS Unstable - interim development builds

[Jerome Shidel]

Hi, 

> On Jun 22, 2022, at 1:05 PM, Jim Hall  wrote:
> 
> I like the idea of the interim development builds. This should be a
> great way to test new changes that everyone can experiment with!
> Thanks for doing this.
> 
> I'm thinking about how people will (mis)interpret the "FreeDOS
> Unstable" name. I wonder if "FreeDOS Test" might be a better name for
> this.

I don’t think “Unstable" would cause much confusion. I think it is a well 
understood and established term for such releases. Many users are familiar with 
it from the Linux world. However, it is not a big deal to switch it from using 
the “Unstable” to “Test” or “Devel”. Maybe it’s a good question to put to your 
usability class. 

> The benefit of "Test" is that it is short enough to combine with
> the "year+month" label and stay conveniently within an "8.3" filename,
> so you have "TEST2207" and "TEST2208" and so on. (I know "8.3" names
> aren't necessary for the web server, but it's a nice symmetry for
> FreeDOS.)

Actually, not quite… For example, each of the media get’s it’s own volume label 
to help differentiate them. For example, with 1.3 the CD boot floppy was 
“FD13-BOOT” but the image to boot directly from the LegacyCD is “FD13-LBFI”. So 
for all of those, they get labeled things like U2206-BOOT and U2206-LBFI.

> 
> Also: I'd prefer to keep the repository for this separate from the
> FreeDOS official 1.3, 1.2, and and 1.1 distributions. If we put the
> interim development builds in the same "repositories" path as the
> official distributions, I think people could easily be confused about
> the status of the interim development builds. I think a better
> location is under the ".../distributions/unofficial" parent location:
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/
>  
> <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/>

I’m not sure about the “unofficial” label. It suggests it is not an official 
version of FreeDOS and is akin to a 3rd party fork of the OS. 

> 
> The path for the "FreeDOS Test" interim development builds would be:
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/test/
>  
> <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/test/>

I was thinking go just 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unstable 
<https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unstable>
 and only keeping the latest one around. 

> And the path to the interim development builds package repo (index
> page) would be:
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/test/pkg-html/index.html
>  
> <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/test/pkg-html/index.html>

Not a problem to move it. 

But when a user is not testing the interim build, it may make it more difficult 
for them to find and try the latest versions of packages.

> 
> If we want to create an ISO "snapshot" of a specific test build, we
> can use the "year+month" path to create a clearly labeled directory:
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/test/test2207/
>  
> <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/test/test2207/>

We could. But at roughly 2gb per build, they use a lot of disk space. That will 
add up quickly doing monthly builds. 

> Jim

I’ve uploaded the current interim test build version (U2206) to my server in a 
sub-directory of https://fd.lod.bz/releases/ <https://fd.lod.bz/releases/> 
I have not added a boot warning yet or implemented the black background in the 
installer. 
There are several aspects to look at and discuss before doing the official 
interim development releases. 
For example, the report includes in document links to change summaries.

Just let me know what we need to change.

:-)

Jerome

> 
> 
> On Wed, Jun 22, 2022 at 9:49 AM Jerome Shidel  wrote:
>> 
>> Hi Jim and the Dev group,
>> 
>> I’m in the process of wrapping up some minor improvements to the RBE
>> (Release Build Environment) that I wanted to make for creating the
>> interim development builds of FreeDOS.
>> 
>> For example:
>> 
>> * Automatic interim build versioning. That way we can easily verify
>> that any reported issues are for the current or a previous build. I
>> went with version numbers like U2207. The U (for Unstable) followed
>> by Year and Month. If for some reason additional interim builds are
>> created that month (major bug, etc), then

[Freedos-devel] FreeDOS Unstable - interim development builds

[Jerome Shidel]

Hi Jim and the Dev group,

I’m in the process of wrapping up some minor improvements to the RBE (Release 
Build Environment) that I wanted to make for creating the interim development 
builds of FreeDOS. 

For example:

* Automatic interim build versioning. That way we can easily verify 
that any reported issues are for the current or a previous build. I went with 
version numbers like U2207. The U (for Unstable) followed by Year and Month. If 
for some reason additional interim builds are created that month (major bug, 
etc), then a suffix of a-z is appended (like U2207, U2207a, U2207b, U2208, 
U2209, etc). 

* Automatic CHANGES.LOG. This will be included on the interim builds 
and actual release build media (LiveCD, LegacyCD and FullUSB) going forward. It 
is created by parsing the commit logs for changes since the last release (or 
interim build) in all of the various projects.  There is some automatic 
filtering of things like updated timestamp and unimportant commits. 
Unfortunately, this means I’ll need to start writing better commit comments. 
:-( Anyway, it looks like this…

Changes since FreeDOS 1.3 release

2022-06-22 10:02:08 project_RBE (shidel): Adjust interim build file names
2022-06-22 09:13:23 project_RBE (shidel): Automatic Unstable Build Versioning
2022-06-21 09:21:37 project_FD-NLS (shidel): added FreeDOS release README to 
NLS project
2022-06-19 20:43:04 project_FD-NLS (cardpuncher): Add files via upload
2022-06-19 19:51:27 project_FD-NLS (shidel): from W.Spiegl
…
2022-06-17 23:29:30 project_FD-NLS (Andrew Bird): Fixup incorrect UTF-8 file 
extension suffix
2022-06-13 14:46:45 sbpmixer (Shidel): Initial commit
2022-06-13 10:50:00 sbpmixer (shidel): v2.0
2022-06-06 21:32:25 project_FD-NLS (cardpuncher): Add files via upload
2022-06-03 06:53:06 project_FD-NLS (shidel): W.Spiegl
2022-05-30 10:38:58 project_FD-NLS (shidel): Codepage corrections
2022-05-26 10:42:04 xdel (shidel): v2.08
2022-05-24 02:31:32 xdel (shidel): v2.07
2022-05-17 07:40:47 fasm (shidel): v1.73.30
…

* Interim builds use slightly different file names so they are not 
confused with release builds.

* Interim build package update links now point to the Unstable software 
repo ( 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/index.html
 

 ) instead of a version specific repository. The Unstable repo contains the 
latest package versions. 

What is left to (probably) do…

* Maybe… Update installer theme when using interim build. I’m thinking 
black background to differentiate it a normal release (blue background). 

* Maybe… Add boot message noting/warning that it is not a release 
build. Maybe…

“Warning: This is a FreeDOS development build and is for 
testing purposes. It may exhibit behavior vary different from a release build 
and may not be suitable for regular use. For general use, please consider using 
the latest release build available at http://freedos.org ”

Anyhow, we should be ready for the first interim build on July 1st.

At some point, I will probably shove the RBE onto one of the machines I have 
laying around with a cron job to create an interim build each month. Then, 
automatically upload it if there are any changes. 

:-)

Jerome


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

Re: [Freedos-devel] Thinking about FreeDOS test releases

[Jerome Shidel]

Hi, 

> On May 16, 2022, at 7:24 PM, Louis Santillan  wrote:
> 
> Any thoughts about the ability to build (more than kernel, FreeCOM, ISO) from 
> source?
> 

The release build process does not compile individual programs. It pulls 
pre-compiled versions staged in package format from the Official FreeDOS 
Archive on GitLab ( https://gitlab.com/FreeDOS  ). 
When the RBE (Release Build Environment) creates the release media, it checks 
each project for a branch specific to the OS build skew it is creating. If it 
exists, it will use that branch for the release. Otherwise, it will just use 
the default (usually “master") branch. 

Doing a full OS release using the pre-compiled packages is still a long process 
taking nearly an hour. When the RBE is set to Verbose, it displays only the 
main actions performed to generate the release. Even so, many megabytes of text 
is displayed. And that is only an overview of what is being done. There is a 
good deal of processing performed on packages and their metadata during a 
release build. Compiling those packages during a release build, would add many 
hours to the OS release build process.

But, it has long been problematic building many packages from source. So, it 
isn’t actually possible at present.

However, I’ve often thought it would be nice to sort-of standardize building 
packages from source. Possibly by including a “BUILD.BAT” or “BUILD.SH” for 
each project. Such a script could then verify that all tools and versions are 
present to build the package. Then, it could perform all the actions needed to 
compile and put it in package format. For some, that would be easy. For others, 
not so much. Many things rely on difficult to find libraries or specific 
versions. While others may need commercial compilers. 

For example, there have been numerous times I have spent hours working on 
getting an “updated” program that is available in source only to compile. And 
then, not always successfully because some critical piece of information on 
compiling it is missing. Nowadays, for the most part, if the developer cannot 
be bothered to provide a compiled version (at least for comparison), I won’t 
bother with trying to compile and update that program. 

:-)

Jerome




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

Re: [Freedos-devel] Thinking about FreeDOS test releases

[Jerome Shidel]

Hi,

Based on the discussion during the online get-together and the tool-chain and 
release processes used to maintain packages and deploy release media, this is 
what I’m thinking…

The pipeline used to assemble all the different aspects into a release is very 
capable. It can handle multiple OS versions without issue. Including things 
like different names, package sets, specific skews of individual packages and 
much much more. 

So...

An automated "Testing build" of the OS release media (possibly all versions or 
just maybe the LiveCD) on a regular schedule. Possible the 1st of every month. 
This version would be called something like “FreeDOS 2022-06.” It would contain 
new features and packages, updates and any other changes. This version could 
easily boot with a message indicating it is a Test Build.

At some point, we could decide that there has been enough improvement to 
warrant a new OS release. When that occurs, we could branch the "Testing Build” 
into an “RC build”.  We would decide at that time if it would be a simple 
update (like FreeDOS 1.3U1-RC1) or major release (like FreeDOS 1.4, 2.0, etc.). 
Regardless of which type, the “RC build” would only get bug fixes from that 
point. 

During that time, the "Testing Build” could continue to receive general 
changes. However (excluding bug fixes), the Testing Build would most like sit 
idle during the testing of the RC Build.

When we are satisfied that the RC Build is ready, we just push out the new OS 
version.

 :-)

Jerome



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

Re: [Freedos-devel] Testing translations

[Jerome Shidel]

Hi,

> On May 11, 2022, at 11:44 AM, Daniel D.  wrote:
> 
> Hi, again!
> 
> Thank you very much for the swift reply!
> 

You welcome.

> [..]
> Thanks, I didn't know about this software.

No problem. It’s still very new and only works on the Package Description Lists 
at present. Support for individual programs translations, simplified 
interaction with Git and a bunch of other things are planned. 

> I haven't tried it yet, but
> do you prefer that I convert it and add the "non-UTF8" version as well
> to the pull request for future translations?

Yes. You should add the DOS compatible Codepage versions as well. That prevents 
the possibility of mangling the conversion later when they are incorporated 
into the packages.

> [..]
> Seems like there is some issues now
> where e.g. Yes/No/Overwrite/Skip does not seem to work properly. Most
> likely because of the keymap, I guess? 

Possibly. Keyboards and Codepages are vary different things. To which program 
are you referring? The program “could” have hard-coded keystrokes (always need 
Y/N…), maybe a setting in its NLS or use an environment variable. 

:-)

Jerome



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

Re: [Freedos-devel] Testing translations

[Jerome Shidel]

Hi,

> On May 11, 2022, at 3:56 AM, Daniel D.  wrote:
> 
> Hi!
> 
> I hope this is the correct mailing list to contact. 
> 
> Recently, I've done some Norwegian translations of the language files
> of FreeDOS, which have been merged into this repository
> https://github.com/shidel/fd-nls (is this an "official" repo?).

At present, the short answer is yes. FD-NLS [1] is more or less the “official” 
repo for translations. 

Although not all developers back-port the those translations to their 
individual sources. The translations there are used to update the packages that 
are included in the official software download repository [2] and the FreeDOS 
release media [3].

At some point, we may move (or just mirror) FD-NLS over to GitLab to be 
included with the package staging repository [4].

> 
> Now that I've added a few translations, I thought that I should
> probably also test them on a working system. However, I am not entirely
> sure how to do that. I also note that these translations require
> code page 857, because of the Nordic characters Æ, Ø and Å. 
> 
> Is it as easy as copying the translated files into C:\FreeDOS\NLS and
> then changing a config file somewhere to use the translated files? 

Mostly.

First, you need to configure the system for the proper codepage. Probably 
adding/replacing the portion regarding the displayed language settings in 
FDAUTO.BAT with these will do it…

set LANG=NO

LH DISPLAY CON=(EGA,,1)
MODE CON CP PREP=((857) %DOSDIR%\CPI\EGA.CPX)
MODE CON CP SEL=857
MODE CON CP REFRESH

Then you can just copy NLS files to C:\FreeDOS\NLS. If there are also 
translated help files, those go into C:\FreeDOS\HELP. However, there are a 
couple things to note. 

First, some programs (like CTMOUSE) will not use them. The translations 
actually get compiled in. At least when looking at FD-NLS, you can identify 
those fairly easily. Their translations are stored under a “source” not “nls” 
sub-directory.

Some other programs (like FreeCOM, IMGEDIT and a few others) do not use the 
“normal” NLS system. Many of those use various utilities to glue translations 
onto the executable. 

Second, for those that do use the normal method for NLS, they use CODEPAGE 
formatted files and most/all will not support UTF-8 directly. So, you will need 
to convert them from UTF-8 to CODEPAGE. Those converted files should also be 
added to the FD-NLS project. 

When I eventually finish working on the FD-NLS Desktop App (for Mac, Linux and 
Windows [5]), it will handle the conversions to/from CODEPAGE and UTF-8 formats 
for the individual program translations. At present, it only supports editing 
for the Package Descriptions. That is text seen in FDIMPLES and other programs 
which describes the individual packages.  

I don’t have an international keyboard. So, the current CODEPAGE map for 
Norwegian in the FD-NLS App needs edited. This is relatively easy to do in the 
application itself. Simply go to the language settings for Norwegian and click 
the edit button next to the CODEPAGE setting. This will bring up a dialog with 
the CP857 mapping. Just look the list and compare the DOS character to the UTF 
character. Nearly all such differences are above ASCII Value 126 When one does 
not match. Select it and simply type the correct character. When finished click 
OK. 

If you decide to update that CP map, be sure to submit it to the FD-NLS 
project. It is stored under (repo)/fd-nls/codepages. Eventually, the App will 
handle that kind of thing automatically. 

> 
> 
> Thanks!
> 
> Daniel
> 

:-)

Jerome

[1] FreeDOS Translation Project - https://github.com/shidel/fd-nls 
 
[2] Software Download Repository - 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/indexes.html
 

 
[3] FreeDOS Release Downloads - https://freedos.org/download/ 
 
[4] The FreeDOS Archive - https://gitlab.com/FreeDOS 

[5] FD-NLS Desktop App - https://up.lod.bz  

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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

Just a thought about the next version of FreeDOS…

It does not seem that it has yet been decided if the next version of FreeDOS 
should be 1.3.1, 1.3-SR1, 1.4 or 2.0. However, there is no technical reason it 
needs to be just one line. The current RBE (release build environment) and 
package maintenance workflow can handle the simultaneous development and 
deployment of multiple versions of the operating system and the related 
software. This includes different versions of packages in each. 

The capability for multiple OS versions was used during the later stages of 1.3 
development. At that time, I split off the pre-release 1.3 into a DEV0 
development line for some experimental testing of various things. That include 
changes to installation, packages and translations. Eventually, when everything 
was working as it was supposed to and looked good, I used the DEV0 line replace 
the previous line of development.

Keeping that in mind, we could continue to provide improvements and updates as 
1.3x or 1.4x. While at the same time, begin work on a completely different kind 
of FreeDOS. This could provide the users with ongoing improvements. While at 
the same time, provide an entirely new DOS experience. 

Eventually when the 2.0 version reaches a release state (possibly years away), 
we could discontinue improving the the 1.x line. Or, maybe keep it around. If 
we provide two separate lines of release, the 2.x series could be greatly 
simplified. Possibly even a single release media (CD, DVD or USB. No LegacyCD, 
etc.). 

:-)

Jerome



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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

Hi, 

> On Apr 2, 2022, at 10:20 PM, David Ormand  wrote:
> 
> In the discussion about what version to assign to the next release:
> It has been my understanding that the version number code x.y is defined as:
>  x is the major number, which indicates a change in interface or function or 
> some other large-scale impact, possibly with implications to backward 
> compatibility.
>  y is the minor number, which indicates an incremental improvement.
> By this notion, as long as FreeDOS is undergoing incremental improvements, it 
> would stay 1.y, however large y might get.
> And therefore a 2.0 would reflect a large change to the way FreeDOS works. 
> Perhaps the start of a movement away from the "same as MSDOS 6.22" objective. 
> Or perhaps a major change in the structure, such as a rewritten kernel, that 
> doesn't affect compatibility at all.
> Not that I can say MSDOS itself held to this principle.  I was never aware of 
> using versions of MSDOS with different major numbers, nor of the Borland 
> compilers I always used having to issue an upgrade to accommodate a new DOS 
> version, but I wasn't really paying attention, either.

I think that is the general practice. However if I try and look back to MS-DOS 
days, I think the users perspective was a little different. Going from MS-DOS 
3.3 through 6.22, it wasn’t really about major changes or breaking backwards 
compatibility. It was more along the lines of bug fixes and the new great 
features that were supplied with the OS. For instance, the addition of disk 
compression to increase storage capacity.

:-)

Jerome

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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

> On Apr 1, 2022, at 7:42 AM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> 
>  Activé jeu., 31 mars 2022 21:42:12 -0400 Michael Brutman 
>  écrit 
> 
> Please forgive me for getting lost on this thread, but what exactly is the 
> problem that we are trying to solve?
> 
> Are we trying to make things simpler for novice users?  Advanced users?  
> FreeDOS maintainers (Jerome in particular) ?
> 
> 
> When I said one should not modify a previous main directory of a released 
> version, I think the problem I try to resolve is to allow maintainers of 
> packages to compare the version on the released media with the more recent 
> versions, be it to evaluate the impact of a vulnerability or a change causing 
> bug in earlier version, or something similar.
> 
> My idea of releasing is, mostly upgrading the tree of packages by:
> 1)creating a new sub-version main repository that contains security and 
> updates of the current version
> 2)create an empty sub-version update and a security repository
> 3)create a new sub-version media with the content of the newly created main 
> repository created at step 1
> 
> I think part of the reason that we have not feel the need to do it like that 
> is that we build the media from an alternative
> place: gitlab repository. So we don't need, did not need the main repository 
> to build the media.

Correct. Originally, the RBE would only pull packages from ibiblio, process 
them and create the release media. During the development of 1.3 (forget which 
RC), the RBE was update to be capable of building the release in additional 
ways. Both related to using Git. Namely the FreeDOS archive on GitLab. The 
default is to clone the master branch of the package, do some processing (less 
required than those pulled from ibiblio) and create the release media. That is 
now the default method used. However, there is an additional option. The RBE 
can look for (and when present) a specific branch during the clone process. It 
can use that branch to create the build.

> 
> Maybe we should come back to the question wheter we should continue to use 
> ibiblio for releasing packages, or should concentrate on a (gitlab or github) 
> repository.

I think the ibiblio repo should be kept for several reasons. First, you can 
connect over plain http. Another, they downloaded zip can easily be installed. 
Ibiblio is easier to browse.


> 
> ___
> 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] Thinking about FreeDOS 2.0

[Jerome Shidel]

Hi Adam,

> On Mar 29, 2022, at 9:24 AM, Adam Peart  wrote:
> 
> If you had the base install by default, and gave the option to install the 
> separate categories as options that would work.  If you wanted go go into 
> more details then you could list each item in each category and let people 
> choose individually, but that would probably be too much work for the 
> installer and for the user. But at least allowing people to choose whether 
> they want games, gui's, development tools, etc. would be nice instead of 
> installing everything for everybody.
> 
> Adam

At present in NORMAL mode, the installer offers BASE, BASE + SOURCES, FULL and 
FULL + SOURCES. I was thinking that packages are easy to install afterwards 
using FDIMPLES. So, just skip thatqeestion in NORMAL mode.

At present in ADVANCED mode, the installer offers BASE, BASE + SOURCES, FULL, 
FULL + SOURCES, CUSTOM and CUSTOM + SOURCES. When either CUSTOM is chosen, the 
installer launches FDIMPLES. FDIMPLES uses the package list from the installer 
and allows the user to modify it however they desire. When finished, it returns 
to the installer with a CUSTOM set of packages defined by the USER and installs 
that onto the system. I was thinking in this mode, keeping the BASE and CUSTOM 
options and discarding the FULL options.

The end result would be.. Normally BASE gets installed and the user could 
install other packages that are included with the media afterwards if they 
wanted. Or when run in advanced mode, they could just install BASE or could 
include/exclude additional items at that time.

The customization of the list of packages used by the installer under advanced 
mode was the original intent and usage of FDIMPLES. That is where the name 
originated. The FreeDOS Installer - My Package List Editor Software. Unlike the 
creator of Gif, I want the pronunciation of the acronym to be up to the 
community to decide. So, if you like FDIMPLES, FD-IMPLES, FDI-MPLES or some 
other way to pronounce it, go for it. I support your effort.  

:-) 

Jerome

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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

Per Jim’s recent post,

I went ahead and split the repositories (no symlink’d repos) as well as created 
a new one for the eventual upcoming 2.0.

Also, I added a simple index file to help visitors browsing those repositories 
more easily navigate to the HTML pages.

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/indexes.html
 


On the administration side….

When packages are added or updated, the default repository (at present) is 
“latest”. To add or update packages for the other repositories, you will need 
to specify the repository desired using command line options. It is easy to do, 
just see built-in help for performing operations on repositories other than the 
configured default. 

Also, the default repo is the only one that self-updates, indexes, etc. If we 
want any of the others to do that as well, we will need to update the cron-job 
slightly. 

On a side note, I will probably update the HTML template to make it obvious 
which repository is being viewed when below the primary index page for the 
repositories. I will probably also add a navigation link back to the Repository 
List as well. 

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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

> On Mar 28, 2022, at 6:04 PM, Eric Auer  wrote:
> 
> 
> Hi!
> 
>> Jim has mentioned the possibility of slimming down the release some for 2.0.
>> At present we have the options of BASE, BASE + SOURCES, FULL, FULL + SOURCES 
>> durning installation.
>> But with how easy package installation is after the initial install using 
>> FDIMPLES,
>> I wonder why bother with FULL at all?
> 
> Even with Ubuntu, the default still is to download a LARGE image of
> a DVD, not a SMALL network installer. In addition, which tiny part
> of todays hardware supports network for DOS? The part which does not
> would force DOS users to first download 100 separate packages from
> another OS by hand before handing them over to FDIMPLES, so I really
> like having a FULL ISO :-)

Once again, I don’t think the packages should not be included on the media. 
Although we may decided to change what is included in the release and what is 
excluded, that is not what I am referring to. For the moment, lets assume no 
changes what is included. With that assumption the packages included on the 
media would not change. What I was thinking about was only changing what got 
installed automatically. Possibly limiting the install to just BASE. The user 
could then install any of the other packages that would still be on the install 
media. But, by default those would not get installed and left to the user to 
pick and choose. No downloading would be required. The packages would still be 
on the CD (or other install media). 

> Also, creating the corresponding source ISOs could be automated and
> those contain be only zipped sources without the binaries to be small.

Sure, it is doable. That would provide the advantage of squeezing more things 
onto the CD (or at least reducing it size). However, it would require 
additional overhead and require the end user to fetch another CD if they want 
the sources.

> Thanks and regards, Eric



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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

Hi Jim,

> On Mar 28, 2022, at 1:40 PM, Jim Hall  wrote:
> 
> On Mon, Mar 28, 2022 at 10:41 AM Paul Dufresne via Freedos-devel
>  > wrote:
>> 
>>> The branches that receive updates (1.2, 1.3, latest) contain the latest
>>> version of the packages that we have created. I don’t see a reason
>>> to add a new branch. If we decided to change package file extensions
>>> (and possibly format), 1.2 and 1.3 would be detached from Latest. And
>>> most likely would receive few if any updates.
>>> 
>>> Jim already provides the ‘raw’ files under a couple directories at
>>> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/ . They are
>>> raw mirrors and most are not in package format.  Oh, I was confused
>>> thinking latest was not in package format. It is because it is in
>>> repositories.  I see that there is less categories in freedos/files
>>> than in the repositories however.
>> 
>> I am very surprised that 1.2 and 1.3 repositories are (still unsure)
>> symlinks to latest repository.  Because in my mind, you have no right
>> to modify 1.2 or 1.3 after they have been released.  But it seems the
>> project don't share this mindset.
>> 
> 
> 
> To clarify, we shouldn't be mixing "1.2" and "1.3" afterwards. Making
> updated packages available for "1.2" or "1.3" is one thing, but
> pushing package updates from FreeDOS 1.3 to a FreeDOS 1.2 user seems
> like the wrong approach in maintaining a distribution. If someone has
> installed FreeDOS 1.2 and then updates to the latest packages in
> "1.2", then they shouldn't get packages from FreeDOS 1.3 which could
> have some differences in paths and other assumptions. (I know that
> mixing packages shouldn't be a problem, but I think it's cleaner to
> keep "1.2" as "1.2", and "1.3" as "1.3".)
> 
> But it looks like we do that in Ibiblio. I didn't realize that was the
> setup.

 It’s been that way since 1.3 development began years ago. 

I’m fairly sure I mentioned it before. But, maybe not or maybe not clearly 
enough. That was a long time ago. 

> Here's what I see on Ibiblio:
> 
> $ ls repositories/ -l
> total 8
> drwxr-xr-x 12 freedos users 4096 May  8  2016 1.1
> lrwxrwxrwx  1 freedos users6 Nov 20  2018 1.2 -> latest
> lrwxrwxrwx  1 freedos users6 Nov 20  2018 1.3 -> latest
> drwxr-xr-x 18 freedos users 4096 Mar 28 03:05 latest
> 
> 
> I wonder if there's a way to revert this on Ibiblio so we don't "mix"
> the updates from FreeDOS 1.2 and 1.3?
> 
> Or is it too late to do that?

1.2 and 1.3 are more or less compatible. There could be some path based 
differences. However, most of that is handled by the package manager. But like 
you stated, there could be other assumptions made in 1.3 that could cause 
issues under 1.2. 

We can split them up and should do that. It’s not a problem for the repo 
management utility. It was designed with such things in mind. 

FreeDOS 2.0 will probably be different enough, that it will definitely need 
it’s own repository from the start. 

So if you want, I’ll go ahead and fork 1.2 and 1.3 repos. While I’m at it, I 
will add one for FreeDOS 2.0.

Jerome

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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

> On Mar 28, 2022, at 11:40 AM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
> The branches that receive updates (1.2, 1.3, latest) contain the latest 
> version of the packages that we have created. I don’t see a reason to add a 
> new branch. If we decided to change package file extensions (and possibly 
> format), 1.2 and 1.3 would be detached from Latest. And most likely would 
> receive few if any updates.
> 
> Jim already provides the ‘raw’ files under a couple directories at 
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/ 
>  . They are raw 
> mirrors and most are not in package format. 
> Oh, I was confused thinking latest was not in package format. It is because 
> it is in repositories.
> I see that there is less categories in freedos/files than in the repositories 
> however.
> I am very surprised that 1.2 and 1.3 repositories are (still unsure) symlinks 
> to latest repository.
> Because in my mind, you have no right to modify 1.2 or 1.3 after they have 
> been released.
> But it seems the project don't share this mindset.

I think there is some confusion. The purpose of the repository is to provide 
updates. Not to provide the version of the packages that shipped with the 
release. For the version that comes with the release, those are on the release 
media. Keeping a separate static copy, to me seems like just a waste of space. 

Linux distress behave the same way. The online repository provides the newest 
version of the packages. When you select to install something from online, it 
does not install the old version that would have come with the release. It 
installs the newest version available. 

:-)

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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

> On Mar 28, 2022, at 10:20 AM, Paul Dufresne via Freedos-devel 
>  wrote:
> 
>  Activé lun., 28 mars 2022 08:24:15 -0400 Jerome Shidel 
>  écrit 
>> But with how easy package installation is after the initial install using 
>> FDIMPLES, I wonder
>> why bother with FULL at all?  Why not just install BASE? The user could 
>> install additional packages later
> For people installing on real hardware, DOS may not provide network drivers 
> for their hardware.
> For them installing almost all make much sense.

Those packages could still be provided on the CD or other Release Media. I just 
don’t know if we need to install the “FULL” set. Maybe just install BASE and 
the user can pick and chose stuff off the release media (and someday the online 
repos) after they install. 

I think it would also help them know what is actual installed on their system. 

> 
> I was about writing some of my ideas about goint toward constant releases.
> 
> Current ibiblio repositories goes like:
> 1.1
> 1.2
> 1.3
> latest

At present, packages for 1.2 and 1.3 are more or less compatible. On the 
server, both paths are just symlinks to latest. 
The 1.1 branch receives no updates.

> 
> I am thinking going toward:
> 1.1
> 1.2
> 1.3
> 1.3Updates
> raw
> next
> 
> where 1.3 updates would contains new packages for 1.3, even if fdimples would 
> probably know how to
> handle it... still usefull to me to have a place with just changed packages 
> since 1.3
> 
> raw would be not yet packaged files... for developers not making specifcally 
> freedos packages
> 
> next would be the next version with the new ideas, maybe with a slightly 
> differrent package format.
> I am thinking about having an extension of .dpk or .dpg for (Free)D(os) 
> packages. To make it explicit
> it is a file ready to be served to fdimples, rather than some .zip file.


The branches that receive updates (1.2, 1.3, latest) contain the latest version 
of the packages that we have created. I don’t see a reason to add a new branch. 
If we decided to change package file extensions (and possibly format), 1.2 and 
1.3 would be detached from Latest. And most likely would receive few if any 
updates.

Jim already provides the ‘raw’ files under a couple directories at 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/ 
<http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/> . They are raw 
mirrors and most are not in package format. 

While you can just “unzip” and use most of the packages, I don’t recommend it. 
For starters, you won’t be able to remove it using a package manager like 
FDIMPLES. You can easily cause issues if you try to use a package manager to 
update or install later. Furthermore, some packages are configured for very 
specific paths and won’t work properly if unzipped to the wrong location. There 
are also other issues that can crop up. As always, I highly recommend 
installing the packages with a package manager. 

As for changing the extension, IDK. It would prevent users from just unzipping 
things which is good and bad. As for the extension, .dpk is already in use and 
would probably cause confusion. Not sure about .dpg. But if we were to change 
it, I think I’m partial to .fdp (F)ree(D)OS (P)ackage.

:-)

Jerome

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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

Hi, 

Back to the FreeDOS 2.0 topic…

Jim has mentioned the possibility of slimming down the release some for 2.0. 

At present we have the options of BASE, BASE + SOURCES, FULL, FULL + SOURCES 
durning installation. But with how easy package installation is after the 
initial install using FDIMPLES, I wonder why bother with FULL at all?  Why not 
just install BASE? The user could install additional packages later. As for the 
option to install SOURCES? IDK. I think the vast majority don’t care. As for 
the rest, the sources are in the packages. But, do we need to ask everyone to 
make it slightly easier for a select few during normal installation? 

In other words, during normal install may it not be better to just skip the 
"pick you package set with / without sources” prompt and just go straight to 
“install now” and install BASE w/o sources. Then in advanced mode provide the 
existing BASE & BASE with SOURCES and the CUSTOMIZED with or without sources” 
options? (Advanced mode already provides the customized options during install).

( Eventually, FDIMPLES will get support for multiple online repositories. For 
now, it is limited to using local media (InstallCD, BonusCD, RepoCD, USB stick, 
HD Path, etc). However it does offer some more advanced features like package 
change sets to automatically add/remove a user’s custom package preferences. I 
think few (if any) users know about or use those features. )

As for the Live Environment, I’ll leave that for later.




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

[Freedos-devel] 50,000 feet

[Jerome Shidel]

Hi all,

Fairly often we get asked, whats new. This is usually difficult to answer 
because it is usually a lot of smaller things. There are updates to the 
installer, changes to the media, additions and removals of utilities, package 
updates and more. To help answer this “what’s new” question, I added a new 
project on gitlab in the FreeDOS archive under 
https://gitlab.com/FreeDOS/OS/misc  that 
contains a Changes.log file. By no means will this log contain everything. 
However, it will attempt to provide a 50,000 foot view (birds-eye-view) of many 
of the bigger changes and most updates. Going forward, I will try to remember 
to keep this file up to date. If you were to take a peek at the file now, you 
would see that almost a dozen such entries have already occurred since the 
release of FreeDOS 1.3 roughly a month ago. 

:-)

Jerome

(PS, The 50,000 foot view idiom is a ridiculous phrase. Birds don’t fly that 
high. 50,000ft is actually higher than most commercial air traffic.)


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

Re: [Freedos-devel] Lost in translation

[Jerome Shidel]

Hi, 

Well, that’s step 1 (package descriptions) of the FreeDOS NLS Desktop 
application. (FD-NLS app)

macOS - https://up.lod.bz/FDNLS_OSX 
Linux - https://up.lod.bz/FDNLS_LNX 
Windows - https://up.lod.bz/FDNLS_WIN 

I also made a couple of minor improvements. 

I need to decide if I should ad in-app git support and/or export changes 
functionality before or after moving on to supporting for individual FreeDOS 
related programs. If your not familiar with the layout of of the FD-NLS 
Translations Project and are not using git, it could be difficult to know what 
files to send to update translations. 

:-)

Jerome


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

Re: [Freedos-devel] Lost in translation

[Jerome Shidel]

Hi,

Update… 

The Windows cross-compiled version seems to be working now. 
https://up.lod.bz/FDNLS_WIN 

Mac version at https://up.lod.bz/FDNLS_OSX 

Just leaves the Linux version of step 1. 

Probably tomorrow.

:-)

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

Re: [Freedos-devel] Lost in translation

[Jerome Shidel]

Hi,

> On Mar 21, 2022, at 7:21 PM, Jim Hall  wrote:
> 
> On Mon, Mar 21, 2022 at 5:41 PM Mark Olesen  wrote:
>> 
>> Is it not possible to create maco wrappers around the new api to
>> retain compatibility with the old? Sorry for my ignorance, I never
>> used FD-NLS libraries. I would think it should be seamless and
>> transparent. For me, the biggest change would be migrating data files.
> 
> We already have the Cats and Kitten libraries, which mimic the Unix
> catgets() function. Kitten is the smaller version of Cats. catgets()
> is much easier to implement on a limited memory system like DOS than
> gettext().
> 
> Jim

First, like Jim mentions... There is Kitten. There are also similar extremely 
light weight and very fast methods used by DOS programs. For example, some use 
hard coded assembly tables and are compiled into the executable. Those have 
more code dedicated to detecting the users language then what is used to handle 
the actual text. 

At present there is no such thing as FD-NLS libraries. When I say the FD-NLS 
desktop uses an “api”, this is internal to the application itself and has to 
deal with the git repository and the different formats and standards used by 
programs to handle the various types of NLS used. This “api” doesn’t have 
anything to do with DOS programs themselves. Nor would it be used in creating 
them. The “api” abstracts all different aspects of dealing with the different 
files, formats, locations and data structures needed to perform translations of 
the NLS for those DOS programs. 

But, the “api” (Application Program Interface or abstraction layer) is used by 
the desktop application could eventually be used by other utilities to perform 
various tasks on the different DOS program NLS files. Including things like 
conversion to PO and back again. It provides a single method for handling all 
of the different formats used so a single program can aid in creating and 
editing translations for the DOS programs. It is not for the DOS programs 
themselves. They already have their own NLS systems. 

I guess the the way to look at the FD-NLS Desktop app is it is for Translators 
not Programmers. It will provide translators a single easy way to manage 
translating the various forms of NLS used by DOS programmers regardless of what 
type of NLS they chose to use in their program. Or, at least that is the 
overall intent. 

After I finish implementing the cross-platform work arounds for Windows and 
Linux, step 1 will be complete. The macOS version is already available for use. 
Step 1 was to make translating package descriptions easier. The previous method 
required the translator to edit them in a spreadsheet program and convert to 
and from DOS codepages. While it was better than what was required even 
earlier. It had several aspects that were easy to make mistakes, miss things or 
even break the translations for that language. Step 1 fixes all those issues. 
It also provides some nice features and an much better experience to the entire 
process.

When the FD-NLS Desktop project is finished, all aspects of providing 
translations for FreeDOS related programs will be improved. It could be as 
simple as just download the App and begin translating. With all such things 
(like interacting with GitHub), handled by the program. The end result could 
potentially remove any barriers for translators to provide contributions. But, 
it will take a while. 

:-)

Jerome








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

Re: [Freedos-devel] Lost in translation

[Jerome Shidel]

Hi Mark,

> On Mar 21, 2022, at 1:27 PM, Mark Olesen  wrote:
> 
> https://www.gnu.org/software/gettext/
> 
> Port then migrate your current translations to PO format

That’s not going to happen. We can’t even find enough people to fix some minor 
years-old bugs. Expecting someone to rewrite all of the programs, to use a more 
complicated PO format as opposed to the native application NLS format, will 
probably never happen.

However assuming you read my entire previous post, you would have seen that I 
do refer to PO files. When FD-NLS Desktop is finished, the underlaying code 
could port the probably dozen or so different native formats to and from PO. 
But at that point, you might as well use the application. It would probably 
provide a better experience translating for DOS programs than the generic PO 
based translations sites.

:-)

Jerome

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

[Freedos-devel] Lost in translation

[Jerome Shidel]

Hi all,

As many of you are probably already aware, a while back I started coordinating 
language translations for FreeDOS and related projects over on GitHub in the 
FD-NLS project[1]. The translators that have been contributing do a great job. 
But with all the various formats and methods used by the individual projects, 
there are often difficulties providing some of the translation needs. 

It is a fairly large and complex problem. It has numerous interwoven 
complications and issues to consider. But, providing translations for FreeDOS 
is going to be getting a whole lot easier. Since the release of FreeDOS 1.3 
final, I’ve begun to tackle the problem. 

The first step in process was to provide a easier way to translate the package 
descriptions. The package descriptions are the information provided about the 
package in programs like FDIMPLES and websites like the Official online 
repository. 

Translating those was done through a large CSV spreadsheet. Although better 
than previous methods, it was easy to make mistakes while editing the extremely 
wide spread sheet. It required conversion to and from UTF-8 to codepage 
formats. Often programs would manage to not properly format the columns or 
mangle the codepage versions. It was a "hope for the best” then “fix what is 
broken” system.

Well, step 1 is nearly complete. The macOS version[2] (my primary development 
system) of the cross-platform desktop application works great. There are a 
couple minor FPC/Lazarus UI framework issues possibly related to the slightly 
different compiler/IDE versions that will require me to implement work-arounds. 
But, the Linux and Windows versions should be out over the next day or so. The 
macOS version[2] is available now. And for anyone who is curious, a screen 
shot[3] of package description editing is provided on the download page. 

Step 1 required a lot of “under the hood” stuff. But, it provides a means to 
easily edit the package description translations. It has automatic 
UTF-8/Codepage conversion. It even includes a live simulated preview of how the 
translation will appear in FDIMPLES using DOS codepages and fonts. 

Step 2 will involve translation support for the projects themselves. It will be 
a long process with many substeps. But, the end goal will include live previews 
for the different types and formats of translations with sample data. Just to 
name a few, Kitten based programs, Source code based, Html based, and many 
more. It won’t be done overnight. But, in many small steps and stages. 

On a side note, all the nitty-gritty stuff that deals with the FD-NLS 
repository, translation files, codepage/UTF-8 conversion, etc. is being done 
separately from the UI code through an “API”. That makes it a little more time 
consuming to create the Desktop app. But, it eventually would make it easier to 
port versions to mobile platforms. It would also make it possible to create 
some command-line utilities to deal with all the various needs. It could even 
possibly permit switching to modern translation systems like PO files. 

To contribute translations using the FD-NLS Desktop app, it is very easy. You 
head over to the FD-NLS project[1] and clone/download the whole thing to your 
hard drive somewhere. Run the FD-NLS app and point it at that repository. If 
the language you want to create  translations for is not yet created, add 
settings for it and possibly create a codepage map (all in app stuff, and 
fairly easy). Then have fun translating.

When satisfied, push your changes to the GitHub repository and we can merge 
them. If you created a new language profile or codepage map, be sure to include 
that in your commit. Eventually, the handling of the git repo related aspects 
will be integrated into the application as well. 

Anyway, once I work-around the cross-platform issues for Linux and Windows, 
I’ll post an update. 

:-)

Jerome

[1] https://github.com/shidel/fd-nls 
[2] https://up.lod.bz/FDNLS_OSX 
[3] https://dnld.lod.bz/FDNLS_OSX-001.png 





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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

> On Mar 3, 2022, at 10:42 AM, Adam Peart  wrote:
> 
> Personally in the test stream I would like an updated LiveCD, and a way of 
> updating the files for an already installed FreeDos. For an existing 
> installed version, I don't like the idea of having to re-install everything 
> every time there's updates. I would prefer just updating all the exe files 
> with the latest version, and leave everything else alone. But it would be 
> nice to have a way to get updated files without having to download ever 
> single package, then having to figure out what directory the extracted go 
> into, every time there's updated files, without having files that are 2+ 
> years out of date.
> 

You can more or less do a simple exe update now using FDIMPLES.

There have been a couple package updates since the 1.3 release. If you visit 
the Official Online Repository on ibiblio at 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/ 
 
you will see a cdrom.iso. Currently 705MB, so technically should be a DVD. You 
can download that ISO and burn it to disc or use it as is for a virtual 
machine. Simply boot your FreeDOS system, insert that disc (or attach the 
image). Run “FDIMPLES /UPDATE”. It will pre-select the packages that can be 
updated. If you forget the /UPDATE switch, you can still toggle them while 
using the program. You can tell it to leave some alone or toggle the update 
status while using FDIMPLES by group (press lowercase u) or everything (press 
uppercase U). To view the changes it is going to make you can press upper or 
lower case V. You can also make additional installs or removals while doing 
this process. Once satisfied, hit OK and it will make the updates, installs and 
removals. 

If you update FreeCOM or the kernel, you will need to take extra steps to make 
them work. Eventually, I should add some stuff to FDIMPLES that will take care 
of that. But, everything takes time and I have not got around to that.

There are only two packages FDIMPLES will refuse to update or remove. FDIMPLES 
itself and FDNPKG. Originally, FDIMPLES was running under extreme memory 
limitations. At that time it was looking like the program was going to need to 
swap itself in and out of memory. So, it “locked” its package. There were some 
changes that permitted it to use lower memory. So, it locking it’s package is 
not necessary. I just haven’y got around to removing that. As for FDNPKG, 
FDIMPLES uses it to perform the actual install and removal. At some point, I 
will add support for other methods that will happen automatically. But for now, 
it needs it to remove, add or update things. 


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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

> On Mar 3, 2022, at 5:33 AM, richardkolacz...@hotmail.com wrote:
> [..]
> So with your plans on more frequent releases - (USB only wise) - where does 
> it leave me?  

Although, your using a USB stick. Your using it as your HD. So, I’d consider 
that installed and not Live. You would probably want to just do upgrades with a 
rolling release. Depending on your system and if you get CD/DVD support 
working, there are ways to do that with the current installer(s). However, I 
think long term a simpler “upgrade" utility would make sense. 

As for your CD/DVD not working at present, there are only a couple open source 
CD/DVD drivers provided with the release. However, the CD initialization helper 
knows about some other drivers. If any of those known drivers are installed 
into FREEDOS\BIN, the helper will try to use them first. Those other drivers 
are not open source and cannot be provided on the release. However, they are 
readily and freely available online. To get a list of which drivers are 
currently supported by the helper and the order they are tried, run “CDROM.BAT 
help”. Make sure to include the extension, there is a exe or com that has the 
same basename that deals with the cd tray which DOS may execute first when the 
extension is not included.

Also, it has been reported to me that some users have had luck running the 
ELTORITO driver when not booted from an ELTORITO CD. It is included and used by 
the LiveCD. However, not installed because it’s only supposed to work when 
booting a ELTORITO disc. 

Jerome

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

Re: [Freedos-devel] Thinking about FreeDOS 2.0

[Jerome Shidel]

Hi, 

> On Mar 3, 2022, at 1:13 AM, Jim Hall  wrote:
> 
> On Sun, Feb 20, 2022 at 4:16 PM Jim Hall  wrote:
> [..]
>> I'm sure we'll want to discuss "1.4" or "2.0" or whatever version
>> comes after 1.3. (I can start a new conversation next week to talk
>> about that.)
> 
> 
> Now that FreeDOS 1.3 has been out for a little while, I wanted to
> start thinking about what comes next. Let's use this thread to discuss
> it.
> 
> What would you like to see changed or added (or removed) in the next
> distribution?
> 
> My top three ideas:
> 
> 
> 1. Move to a "rolling release"
> 
> It's taken several years* to release a new version of FreeDOS. Yes,
> DOS is pretty stable, so we don't need a new distribution very often
> anyway. But for many folks, the new official distribution is the only
> way they get the updated tools (most people don't download individual
> tools to update a running FreeDOS system.)
> 
> *Not counting Release Candidates, the last few releases were:
> 1.0 (2006) - 1.1 (2012) - 1.2 (2016) - 1.3 (2022)
> 
> I think it would be interesting to set up a system that builds a new
> FreeDOS "test" distribution whenever we update packages on the FreeDOS
> Files Archive at Ibiblio. That doesn't need to be a new build every
> night, but maybe every month.

Since the RBE (Release Build Environment) is fully automated, the is nothing 
prevent throwing a copy into a virtual machine that can run once a week week, 
month, quarterly or whenever.

Just a side note… The previous version of the RBE used would pull down a copy 
of the packages from the Official Software Repo on ibibio. However with the 
improvements to package staging, update and deployment, it makes more sense to 
pull them from the GitLab archive. This also permits making test branches of 
projects that can be used during the release build process. Such changes are 
temporary and can be permanently included or discarded prior to committing 
those packages to the Software Repository on ibiblio. This can include updates 
to metadata, translations, configuration or any other part of a package and is 
great for “testing” things before fully committing to a change.

> 
> I think these distributions would come in only two versions: a "full"
> FreeDOS that looks like the LiveCD (see also #3 below) and a "mini"
> FreeDOS that contains just the FreeDOS "Base" packages, without source
> code. (The "mini" should be very tiny, and basically the same as a
> "floppy" FreeDOS install .. I guess "floppy" is a third distro
> version, but I think it could be derived from the "mini.”)

The RBE can be told to only bother making specific skews. 

LiveCD. No problem. 
Mini CD? Well, wouldn’t take much to add that. 
Floppy Edition. No problem.

However, you cannot really derive the Floppy Edition from the the install 
process used by the LiveCD. The installers are completely different. Although, 
the end result of an install is more or less the same on most VM’s and 
Hardware. The work in completely different ways, using different process and 
methods and are not compatible with each other. The process used by the LiveCD 
(FDI) requires a 386+ and cannot be split across floppy diskettes. The Floppy 
Edition (FDI-x86) only requires an 8088/86 and is made to span diskettes. 

So practically speaking. That leaves three choices for a MiniCD. 

1) Since it is on CD, requiring a 386+ is not a problem. It can use FDI (the 
primary installer). FDI is already capable of having a source media that only 
contains a BASE package set. (no FULL set). This can if desired include extra 
packages that don’t get installed. Or, just BASE and nothing else. It will 
automatically, limit the package selection choices to just (BASE and BASE 
w/sources). 

2) Create a MiniCD based on the Floppy Edition using the FDI-x86 installer. 
Basically, create an ISO of the “Install using floppy edition” that exists on 
the LiveCD. That ISO would probably not have a menu. Just boot straight to the 
FE installer.

3) Similar to 2, except instead of using the HD image, create a modified 
version that boots a floppy image with CD support and install from the CD 
portion. This is similar to booting into the Live Environment, going to the 
FDI_X86 subdirectory on the CD and running setup. 

All that being said. I don’t think we need to worry about doing a MiniCD. I 
think it is probably to small a subset of users to worry about making for every 
“test” release. The Floppy Edition is very flexible and they could just use it. 
Either from the LiveCD, the Floppy Edition Diskettes or even copy it to a 
subdirectory on there hard drive and run it from there. 

I think that doing interval LiveCD + FloppyEdition should be sufficient. If you 
want to keep each around, they will use a lot of disk space as it is.

We may want to consider only just releasing the LiveCD at intervals. My guess 
is that probably what 99% of users want. Although, there may be a large portion 
who want the BonusCD.

This reminds me of 

Re: [Freedos-devel] freedos 1.3 at german magazine heise

[Jerome Shidel]

> On Feb 25, 2022, at 8:00 PM, Ralf Quint  wrote:
> 
> On 2/25/2022 4:02 AM, Jim Hall wrote:
>> https://www.heise.de/news/Betriebssystem-Oldtimer-FreeDOS-1-3-mit-neuen-Programmen-und-Features-6515775.html
> 
> Just had a quick read over that one and noticed one strange thing mentioned. 
> Apparently the CPU detection in the installer would only recognize an 80186 
> even though apparently installation on an 80286 was attempted... :?
> 
> Ralf

Probably do to translation, this is not entirely accurate.

This is a known issue and it is mentioned in the README doc for the release. 
Accordingly, installation defaults to a 386 or better system. 

But, I’ll explain further here.

The standard primary installer (FDI) used when booting from USB, CD, or CD boot 
floppy installs either BASE (plus a few extras), FULL or in advanced mode 
possible a custom set of packages regardless of the system and it processor. 
This is not going to be on any system with less than a 386 level processor. 
This installer also uses external utilities that require a 386. 

The Floppy Edition installer (FDI-x86) installs only the BASE (plus a few 
extras) packages supported by the system and CPU. This could be on any system 
with a 8088/86 or higher machine. This installer only uses utilities that can 
run on a 8088/86. However until I get around to doing it, it does require EGA 
or better graphics. Eventually, lesser display cards are intended to be 
supported. 

Both installers, then install a custom FDCONFIG.SYS and FDAUTO.BAT file that is 
appropriate to the CPU, Hardware and/or Virtual machine platform. 

Although not a bug, the information used to perform CPU detection is not 100% 
reliable with all processors. 8086/88 is obviously assumed. 80186 is fine.   
However, 286 tests fail on some 486 machines. I don’t know if they function on 
586 (no Pentium to test). But they do work on 686 (Pentium Pro) and higher 
CPU’s. Being the 286 test is for a 286, it should work there. However, I’ve 
only got so many test machines and it is unknown if the test passes on machines 
with less then a 686. 

So at present, results of the test algorithm for specific CPU’s are 8086/88 
(good), 80186 (good), 286 (possibly good), 386 (possibly good), 486 (rarely 
good), 586 (possible good), 686+ (good), Virtual Platforms (good, handled 
differently).

So on some 486 systems (probably most, including my 486DX2/66), the 286 test 
fails and it is detected as a 80186. 

So until I have to time to dig into it and come up with a better test for the 
CPU, both installers have a work-around for the well known issue. When the 
result of the test says it is less then a 386, they assume it is a lie and 
assume it is a 386 (or better) system. They then install the default (386 
based) config files. 

When FDI-x86 makes the assumption it is a 386, it also installs the 386 set of 
packages. Package installation is not effected by CPU for the primary FDI 
installer.

FDI-x86 can also be told to completely ignore any/all types of system and CPU 
test results and install based on a command line option for any specific 
CPU/System. So only the 8088/86, 80186 or 80286 compatible packages can be 
installed, if the user desires. 

> 
> 
> -- 
> 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



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

[Freedos-devel] 1.3 Final

[Jerome Shidel]

Hello All,

I think all of the most important issues, features, improvements and testing 
regarding FreeDOS 1.3 final have been wrapped up. So, 1.3 should be released 
very soon. Possibly even this weekend sometime. 

And there is even more good news. With the work on 1.3 winding down, it gave me 
the chance to create two new open source games out of a long list of ideas. 
Both are planned for their initial public release coincide with the release of 
1.3 Final. Neither game is anything like what has been on previous releases. 
One is a very simple classic memory game called SaysWho. The other is a falling 
block game just called BlockDrop. It is completely different and not a Tetris 
clone. Once you understand the basic premise, it starts out easy enough. But as 
you level up, it can get really fast and extremely difficult. In early builds, 
the game got far too hard too quickly. Getting beyond level 5 was near 
impossible. But, I think I got the difficulty nailed down now. Be sure to 
glance at the readme to understand how to play. It’s not hard to play, it is 
just a little different. I hope everyone enjoys playing them.

:-)

Jerome

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

Re: [Freedos-devel] RAMdrive install problem (on bare metal)

[Jerome Shidel]

Hi,

First, if you load the driver in the FDCONFIG.SYS you need to provide the full 
path to the driver. If you remove the line you have added to that file, then 
you can simply add this to the end of the FDAUTO.BAT or even create a separate 
batch file to only start the RAM disk when needed.

( assuming a separate file like MYRAMDRV.BAT )

@echo off
devload srdxms.sys E:
srdisk 8M

Although, you could make it a little smarter by using an environment variable 
that points to the drive like so…

@echo off
if not “%RAMDRV%” == “” goto Present
SET RAMDRV=E:
devload srdxms.sys %RAMDRV%
srdisk 8M
if errorlevel 1 goto Failed
echo RAM Drive %RAMDRV% created
goto Done

:Failed
echo Could not create RAM Drive 
set RAMDRV=
goto Done

:Present
echo RAM Drive present as drive %RAMDRV%

:Done

Then you can always test the %RAMDRV% variable to see if it exists and what 
drive it resides (incase you need to change it). 

Thats about all there is to it. Of course, there are different options for 
SRDISK to make the drive much bigger and reserve space for programs.

However, all of that assumes SRDISK works on your system. Otherwise, you may 
need to try one of the other RAM disk drivers like SHSURDRV.

:-)


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

Re: [Freedos-devel] Any package updates for FreeDOS 1.3?

[Jerome Shidel]

Hi, 

> On Feb 15, 2022, at 10:59 PM, Michael Brutman  wrote:
> 
> I'm working on a new mTCP version, and this thread reminded me to ask about a 
> problem.
> 
> I update mTCP more often than FreeDOS gets updated; it's under active 
> development and I need to get fixes out.  Where this becomes a problem is 
> that I often see people using the 2013 version of mTCP because they got it 
> with FreeDOS and did not know that they could look for updates.  And while 
> that was a solid release, it has been superseded by a release that is almost 
> 7 years newer.  With lots of bug fixes and enhancements too …

At present, the version that will be on FreeDOS 1.3 final dates from 3/7/2020. 

> 
> How can I alert FreeDOS users using mTCP that they should check for newer 
> versions?  Would it be possible to add a second README.TXT (or something 
> similar) in the directory where mTCP gets installed?
> 
> Also, does mTCP get installed in it's own directory or does it share a 
> directory with other networking utilities?  (I'd prefer it to be separate, as 
> it is a standalone project.  That also keeps the README.TXT or other file 
> conflicts to a minimum.)
> 

Those are all good questions. :-)

First, to explain where mTCP gets installed. I should go into at least a little 
about how packages get installed. 

Like all programs, mTCP actual installation and removal of the files is handled 
by FDINST. This is the case for programs installed by the Primary Installer 
(FDI) or later through the use of FDIMPLES. (This is not the case with the 
Floppy Edition installer FDI-x86. It uses SLICER. However, it creates the 
additional files needed to use programs like FDIMPLES, FDINST, etc. after 
installation). 

When FDINST installs a package, the directory structure in the zip archive are 
more or less aliases that then get mapped to actual directories. Unless 
overridden, the mapping is defined in the %DOSDIR%\BIN\FDNPKG.CFG file. For 
example if a package contains a path called \PROGS\APP, the \PROGS gets 
remapped to C:\ and it files in that path get put under C:\APP. Likewise \BIN 
is mapped to %DOSDIR%\BIN. However, many of these mappings use the same 
directory as the alias. 

At present, this is the case for MTCP. The package has it’s executable and 
document files under \NET\MTCP. So if a user has not modified the mapping 
config file, they would get installed into C:\NET\MTCP. 

So, yes.. Additional files can be added without much concern of conflicts. And, 
yes… it should be in it’s own directory.

As for alerting users that there is an update, I couldn’t say. However, there 
are some things you can consider that could make it a lot easier for end users 
to have the latest version of you program.

Nowadays, there is a simple process in place for the packages that get included 
with a FreeDOS release or placed on the official online repository. All such 
packages get staged in their own GitLab repository under the FreeDOS archive 
group https://gitlab.com/FreeDOS  . The packages 
there are fully extracted, with sources, executables, translations and 
metadata. They kept in a ready to “zip-and-ship” package directory structure 
for FreeDOS.  

When the RBE (Release Build Environment) creates the OS release install media 
(USB sticks, LiveCD, etc), it clones the projects from GitLab that will be 
included in the release. It performs some analysis and verification on those 
files then compresses them for inclusion on the media. 

Those GitLab projects are also the preparation and staging area for the 
packages that go into the Official FreeDOS Software Repository 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/
 

 . Network aware package managers like FDNPKG can check the official 
repository. Then retrieve and update the packages installed on the user’s 
computer. 

My recommendation is to request developer access to the package staging project 
for mTCP at https://gitlab.com/FreeDOS/net/mtcp 
 . By doing so, you could ensure we always 
have the latest version on any release of FreeDOS. It would also help us keep 
the version in the Online Repo up to date as well. Then there is also the added 
benefit of being able to setup alerts for if a user reports an issue. 

On a side note, the Online repository is not currently up to date with many 
projects in the GitLab Archive. There have been a bunch of updates to programs. 
And, just about all the package metadata has been modified numerous times. 
Instead of constantly updating the ones in the Online Repo, I’ve been putting 
it off until just before the release of 1.3 Final. At which point, I’ll 
probable purge the current repo and refresh all the packages with the latest 
versions from GitLab. 

> 
> Regards,
> Mike

:-)

Jerome

___

Re: [Freedos-devel] Sea Code by the C Shore

[Jerome Shidel]

> On Feb 8, 2022, at 7:34 PM, Mark Olesen  > wrote:
> 
> are you familiar with it?

I had heard of it. But, wasn’t familiar.

> The file can be embedded straight into C
> code. Once the xpm file is created you can translate it into other
> data structures of a specific language. Therefore, there is no need to
> support a variety of image formats. XPM externally -> transform bitmap
> internally to whatever
> 
> Just an idea, not sure if that is exactly what you are looking for?

After looking into that format, I don’t think it is quite what I’m looking for. 
XMP3 (the current version) would be easy to export and I may add it. However, I 
think it requires a little to much overhead on the users side. Everything is 
just a blob of text in a single structure that would possible require string 
processing to interpret data like image width, height, etc. 

However, XPM is based on XBM. That looks more like what I’m thinking. For that, 
I could just include additional defines and potentially the additional 
structures for the palette and RLE versions. That allows for extremely lite 
weight end user code. 

Thanks for pointing me towards these.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Sea Code by the C Shore

[Jerome Shidel]

> On Feb 8, 2022, at 8:50 AM, Mark Olesen  wrote:
> 
> Have you ever considered using xpm file format?

Not specifically. 

At present, it has full support for simple bitmap raster fonts like those in 
the GNUFONTS package. Danger Engine native formats like fonts (current max 
32x32), Graphics (IGG) and  Sprites (IGS). Limited support for BMPs (Win 3.x 
level of complexity). Exports Nasm and Pascal Code for images.

Maybe someday, add full PCX and basic ICO. GIF. Maybe add exporting PNG, TIFF 
and GIF. That would be all the major DOS graphics formats. 

Depending on their complexity, I’m open to other formats. 




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

[Freedos-devel] Sea Code by the C Shore

[Jerome Shidel]

Hi everyone,

I’m not really much of a C (pick your flavor) user. Mostly I work in Assembly, 
Pascal and other languages. However as I’m well aware, C is very popular for 
development in FreeDOS. So, I have a favor to ask of one of the C gurus.

One of the programs that I’ve made recently is a pixel editor. It is geared 
towards development and is simply called ImgEdit. It is primarily for creating 
and editing graphical assets for programs running on top of my “Danger Engine” 
game/application framework. It can export images to several file formats. Being 
geared towards development, it can also export those images to a Pascal Unit 
and NASM include as well as BMP and it’s native graphics IGG format. 

To make the editor more useful, I would like to add export capability for any 
generic version of C as well. 

Bellow is the output of a simple 16x16 white hollow square to source code as 
NASM include and Pascal Unit. At present, the NASM version includes a 
additional simplified Run Line Encoded version (DRE-Data Run Encoding) of the 
image that is not in the Pascal version. And, the Pascal version includes some 
structured variable that wouldn’t be very useful in assembly. Both also include 
a palette map. Also, both structured in a way to not increase compiled size for 
unused data. In NASM, that is done with the use of macros/defines. In Pascal, 
the compiler just optimizes the extra stuff out.

If one of you could create a C version that hopefully does not require a 
specific version of C from the code bellow, I’ll examine it and add an 
appropriate export filter to match. I could probably do it without assistance. 
But, it is likely to result in something sub-optimal. 

:-)

Jerome

——
NASM include version: DEMO_IMG.INC
——
; Nasm 2.x compatible raw graphic image include
; auto-created by Danger Engine

%define IMAGE_DEMO_IMG_BYTES  0x0100; 256 bytes
%define IMAGE_DEMO_IMG_WIDTH  0x0010; 16 pixels
%define IMAGE_DEMO_IMG_HEIGHT 0x0010; 16 pixels

%macro IMAGE_DEMO_IMG_DATA 0
db 0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F
db 0x0F,0x0F,0x0F   ; 0
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 1
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 2
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 3
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 4
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 5
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 6
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 7
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 8
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 9
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 10
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 11
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 12
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 13
db 0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
db 0x00,0x00,0x0F   ; 14
db 0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F,0x0F
db 0x0F,0x0F,0x0F   ; 15
%endmacro ; IMAGE_DEMO_IMG_DATA

%macro IMAGE_DEMO_IMG_RGB 0
; RGB Palette Values 0-255. Most VGA takes 0-63. So, divide them by 4. Or,
; simply shift them right by 2.
db 0x00,0x00,0x00, 0x00,0x00,0xA8, 0x00,0xA8,0x00, 0x00,0xA8,0xA8   
; 0
db 0xA8,0x00,0x00, 0xA8,0x00,0xA8, 0xA8,0x54,0x00, 0xA8,0xA8,0xA8   
; 4
db 0x54,0x54,0x54, 0x54,0x54,0xFC, 

Re: [Freedos-devel] LiveCD boot from floppy

[Jerome Shidel]

Hi Willi,

> On Jan 19, 2022, at 10:25 AM, Wilhelm Spiegl  wrote:
> 
> OK, if the diskette is kept, what about the following idea:
>  
> Simply add a sentence in the readme file that the diskette will not start a 
> live environment but only an installation. This says everything even to 
> newbies.
> This is done in two minutes. Is this ok? 

Probably. 

In a recent post I made, I asked everyone if we should also include a floppy 
image that DOES start the Live Environment.  That floppy image could be 
included along side the CD Install Boot Floppy image. Although you can install 
the OS from the Live Environment, I don’t think a Live Floppy image should 
replace the CD Install Boot Floppy image. It is possible that on older systems 
the drivers and such required to start the Live Environment may have problems. 
So, the much simpler CD Install Boot Floppy image should be kept. 

However, no one commented on wether or not they thought it was I good or bad 
idea. So, IDK.

> Willi
>  

:-)

Jerome

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

Re: [Freedos-devel] LiveCD boot from floppy

[Jerome Shidel]

Hi Willi

> On Jan 19, 2022, at 7:39 AM, Wilhelm Spiegl  wrote:
> 
> 
> Hi to all,
> did you ever try to boot from the diskette with an inserted CD or from the 
> diskette itself?

Yes many many many times.

> As it is a live version the CD offers "Use FD in live environment mode",  
> "Install to harddisk",  "Boot from HD" and "Boot from diskette".
> When you choose "Boot from diskette" at this position

It would boot any diskette. Not just the install diskette. For example, a 
Windows 95 install diskette or Linux recovery diskette.

> (or when you directly boot from diskette) there is NO option for "Use FD in 
> live environment mode" - it only offers INSTALLATION (at least I did not find 
> it, if it exists, please tell me).

Correct. At present, only selecting the Live Environment when booting the Live 
CD provides the live environment mode.

> If I go to CD-ROM drive D: I can only see setup.bat - and this one also only 
> offers installation, no live environment. I am sure there is a batch file 
> that offers live environment too,but it is not in the root folder, means: 
> newbies will not find it.

There is not a readily available batch to do that. 

> From my sight this is dangerous, even there is a warning that it may 
> overwrite your system.
>  

I disagree for several reasons.

First, the installer does warn that it will replace the present OS. 

Second, almost all newbies that are just trying out FreeDOS will be doing it 
using a VM. 

Third, if a newbie is actually using real hardware, it is probably a machine 
made within the last decade. Most machines in the last 15 years don’t have any 
floppy drives. If the machine is very new, it will probably either be UEFI only 
or at least set to UEFI booting and won’t boot any of our release media.

> @Jerome: sorry, but I think this is an important point for discussing - and 
> not distributing the diskette.
>  

I think if it was pre year 2000 it might be worth putting some additional 
safeguards in place to prevent a newbie from trashing their existing operating 
system. 

However, even if the installer required the user to type “YES, Please 
completely ERASE and DESTROY Everything on my computer now” and even required 
matching case, there would still be users who did not realize it would break 
there current operating system.

But, it is now the year 2022 and based on how most people run and use FreeDOS 
and other DOS platforms, such additional measures just are not warranted. 

A single warning by the installer is sufficient.

> Willi
>  
>  

:-)

Jerome

> Sent: Tuesday, January 18, 2022 at 12:46 PM
> From: "Jerome Shidel" 
> To: "FreeDOS Developers" 
> Subject: [Freedos-devel] LiveCD boot from floppy
> Hello all,
>  
> The LiveCD menu also contains a Boot from floppy disk entry.
>  
> Do we really need to keep this option on the menu?
>  
> A user can just insert a floppy disk and boot it without having the CD 
> inserted. I think the use case for this option is very low. Removing it would 
> problem only be a minor inconvenience. If it affected anyone at all, it would 
> only effect a handful users at most.
>  
> Jerome
> ___ 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 mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] LiveCD boot from floppy

[Jerome Shidel]

Hello all,

The LiveCD menu also contains a Boot from floppy disk entry.

Do we really need to keep this option on the menu?

A user can just insert a floppy disk and boot it without having the CD 
inserted. I think the use case for this option is very low. Removing it would 
problem only be a minor inconvenience. If it affected anyone at all, it would 
only effect a handful users at most.

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

[Freedos-devel] LiveCD FloppyEdition

[Jerome Shidel]

Hi Everyone (but mostly Jim),

This is what I’m thinking for 1.3-Final regarding the LiveCD Boot menu.

Leave everything as it is already. Except create an entry after “Install to 
harddisk” called “Install using the Floppy Edition”. Then for it’s descriptive 
text at the bottom of the screen, probably just put “Install FreeDOS 1.3 using 
the Floppy Edition from the CD-ROM. This a small hardware specific installation 
of the BASE package binaries only.” 

I think that should be sufficient to point out the most important difference.  

So, I’ll probably go ahead and just change it. 

Can anyone think of some better?

Or, did you have something else in mind Jim?

:-)

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

[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

[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

[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

[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 

Re: [Freedos-devel] Fwd: ACPI auto power ON

[Jerome Shidel]

Hi,

> On Jan 13, 2022, at 9:14 AM, Mercury Thirteen via Freedos-devel 
>  wrote:
> 
> This feature was nonstandard across various BIOS implementations, so it is 
> highly likely that if the BIOS does not support it via its built-in interface 
> (the "Press  to enter SETUP" prompt) it is probably entirely unavailable.
> 
> Just to be sure, I checked the CMOS Memory Map document 
>  in Jerome's excellent online 
> version of the Ralf Brown Interrupt List - the feature is not listed.
> 
> Sent with ProtonMail  Secure Email.

I didn’t see anything obvious when I looked either. Could be it was never 
documented prior to the last RBIL update. Or, like you said possibly never 
standardized. 

But after looking at Resume by Alarm 
 and Power Management 
, I was thinking maybe there 
is a trick. I wonder what would happen if you programmed it to “Resume” in the 
past. Would it refuse, clear it, wait for the clock to roll over or wake 
immediately. I suspect all of the above depending on the BIOS. Maybe if set 
everything to 0x, it would wake instantly. But, thats all just guesswork on 
my part. 

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

Re: [Freedos-devel] is there anyway i can contribute to freedos's development with C++?

[Jerome Shidel]

Hi,

> is there anyway i can contribute to freedos's development with C++?

As a first step, I recommend reading the wiki on Contributing to FreeDOS.

http://wiki.freedos.org/wiki/index.php/Contribute 





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

Re: [Freedos-devel] Pushing source code to Github

[Jerome Shidel]

> On Jan 10, 2022, at 4:54 PM, Tyson Oswald  wrote:
> 
> I wa able to create and mount/format a VMDK virtual hard disk with fixed size 
> 600MB  file. I was able to mount I on MacOS. Thanks Jerome for the assist. 
> Maybe I will do a YT video on it.
> 
> Now the fun begins.
> 
> Tyson

Your welcome. 

:-)

Jerome



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

Re: [Freedos-devel] Pushing source code to Github

[Jerome Shidel]

Hi,

> On Jan 10, 2022, at 1:37 PM, Jim Hall  wrote:
> 
> 
>> 
>>>> On Jan 10, 2022, at 10:57 AM, Tyson Oswald  wrote:
>>>> 
>>>> Alright I have tried to Crete a VMDK virtual hard disk in Box but when I 
>>>> go to format the disk I get an error
>>>> 
>>>> DOS Diver error (hex) 01
>>>> 
>>>> [Error 129]
> 
>>>> On Jan 10, 2022, at 11:53 AM, Jerome Shidel  wrote:
>>> 
>>> Assuming it was renamed properly, and during boot the kernel displays the 
>>> drive….
>>> 
>>> Without knowing more… I think that is an FDISK bug. Or, possible one with 
>>> FORMAT.
>>> Regardless, I’ve seen this several times with small drives.
>>> 
>>> Make sure you HD size is in excess of 512 MB. Pre-allocated and not set to 
>>> SPLIT.
> 
>> On Mon, Jan 10, 2022 at 11:20 AM Tyson Oswald  wrote:
>> 
>> Ah, I had it set for 500mb, I’ll try something larger
>> 
> 
> 
> Not to confuse things, but I've used a much smaller VDI (200MB) on
> VirtualBox to install "plain DOS" with FreeDOS 1.3 RC5, and that
> worked fine. ("Plain DOS" takes only 20MB on the hard drive, so I
> didn't need a very big virtual disk.)
> 
> I set it as "fixed size" so it creates the full VirtualBox Disk Image
> ("VDI") right away .. because 200MB or even 500MB is not that big
> these days. Creating a 500MB VDI took less than a second to do during
> my video:
> https://youtu.be/vE9CwMBvqnw?t=79
> 
> Jim
> 

Yup, me too.

But, I’ve also seen issues with <512mb partitions as well. So, IDK. It’s weird.





> 
> ___
> 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] Pushing source code to Github

[Jerome Shidel]

Hi,

> On Jan 10, 2022, at 10:57 AM, Tyson Oswald  wrote:
> 
> Alright I have tried to Crete a VMDK virtual hard disk in Box but when I go 
> to format the disk I get an error
> 
> DOS Diver error (hex) 01
> 
> [Error 129]

Assuming it was renamed properly, and during boot the kernel displays the 
drive….

Without knowing more… I think that is an FDISK bug. Or, possible one with 
FORMAT. 
Regardless, I’ve seen this several times with small drives. 

Make sure you HD size is in excess of 512 MB. Pre-allocated and not set to 
SPLIT.

Jerome




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

Re: [Freedos-devel] REMember a bug

[Jerome Shidel]

Hi Robert, 

> On Jan 9, 2022, at 12:31 PM, Robert Riebisch  wrote:
> 
> Hi Jerome,
> 
>> 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?
>> 
>> Personally, I think it should be fixed. No one should be using that. If they 
>> were, I feel they are technically just exploiting a bug and there is no 
>> obligation to continue supporting that “feature.”
>> 
>> I don’t/won’t work on FreeCOM. I’m just curious about your thoughts on this. 
> 
> Just leave it in. By the way, it's the same with '<' or '>’.

Well out of more curiosity, I just tried it from an XP command.com window. 

REM this | echo that

It generated no output. 

FYI, COMMAND.COM  for Win95 & Win98 both output text as 
well.

However, there really is no MS-DOS latter than 6.22 and COMMAND.COM 
  from 
Win95+ probably don’t count. But, MS did eventually fix it in there command 
shell.

:-)

Jerome

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

Re: [Freedos-devel] Pushing source code to Github

[Jerome Shidel]

Hi, 

> On Jan 9, 2022, at 12:51 PM, Tyson Oswald  wrote:
> 
> There is supposedly a way to mount the virtual disk on macOS when it is 
> unmounted from the VM but I haven’t been able to get it to work. VB comes 
> with MacFuse for that purpose but have never been able to get it to work. 
> Basically it can’t find the MacFuse library.  

There is and you don’t need anything special.

Basically, when you create the VM in VirtualBox or other system. You must pick 
VMDK and DO NOT SPLIT and PRE-ALLOCATE disk space. Your VM will create two 
files. One really small one called something.vmdk and another big one called 
something-flat.vmdk. Once that is done, shutdown VirtualBox. Open Finder and 
rename something-flat.vmdk to something-flat.img. The something.vmdk is just a 
text configuration file. Open it in your favorite editor and change the entry 
for something-flat.vmdk and change the extension to .img. 

Then your all set. VirtualBox will use the renamed file and when it is not 
running you can double click the img file in finder to mount it. 

Not hard to do. Just need to pick the correct settings when creating the VM, 
rename a file and change the config file. 

> 
> I remember I tried doing assembly development using nasm in DOSBox but when I 
> compiled it would crash DOSBox so I gave up on it. Mostly VB works fine for 
> me, I do not need PC speaker support and I guess there is something in VB for 
>  Linux that an do it. I saw it when I was looking into PC speaker support but 
> you might beed to have a PC speaker on your system to handle  it. It would be 
> cool if it could just emulate it and send it to with the audio interface.

I use NASM all the time in DOSBox. Although for larger things or when I’m in a 
hurry, I just use NASM on the Mac then run the executable in DOSBox.

NASM for the mac is fairly fast. NASM for DOS is very slow.

:-)

Jerome

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

Re: [Freedos-devel] Pushing source code to Github

[Jerome Shidel]

Hi, 

> On Jan 9, 2022, at 9:45 AM, Tyson Oswald  wrote:
> 
> Quick Question.
> 
> I see Jim has placed several projects out on GitHub in the past few weeks, 
> cool.

Maybe Jim should do a video on his DOS/GitHub workflow. :-)

> I am developing on FreeDOS but how are others placing their code out on 
> Github? 
> 
> Right now I FTP the files from my FreeDOS VM (VirtualBox) to my NAS and from 
> my NAS I can either push it to Github or do that from my Mac which has a 
> mount point to the NAS.

Usually, I develop using an editor on a Mac (BBEdit) directly to a directory 
accessible to DOSBox. DOSBox is running a hybrid install of 1.3-RC5. This is 
basically everything but the FreeDOS kernel.  Then, I build and run in DOSBox. 
Or switch to a terminal window in macOS and use git. Although for somethings, I 
also build in the terminal windows (like NASM based stuff) and just test run in 
DOSBox. This is very quick and easy. 

For things that need to be tested in a VM or on real hardware, I have EtherDFS 
server running on a Linux Server. Then, I use EherDFS to mount it as a drive in 
FreeDOS. But usually other than testing or disk level development, using DOSBox 
works fine.

> Thanks,
> Tyson
> 

:-)

Jerome



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

Re: [Freedos-devel] REMember a bug

[Jerome Shidel]

Hi Jose,

> On Jan 8, 2022, at 7:46 PM, Jose Senna  wrote:
> 
> Jerome Shidel said:
> 
>> 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.
> 
> It is not a bug, "|" is the sign for a pipe, so the 
> parser thinks the output should be piped to 4]].
> Of course, one would expect the line should be
> completely ignored, but perhaps the parser ignores 
> the line up to "|".
> I suggest to try some tests with some non-reserved 
> character in place of "|" and also other REMmed 
> statements inluding the "|" in other places.  

For the BAT in question, I did not write it.

I just found myself needing to fix it. I immediately 
knew what was happening and swapped out the pipe
for a comma. No more problem in that batch REM 
statement.

Since the docs say everything after the REM is ignored,
I feel that the behavior is not consistent with the stated 
behavior. So, it is a bug in either the handling of the pipe
in a REM statement. Or, it is a bug in the documentation.

Either way, It is more of a philosophical question.MS-DOS
is NOT bug free and just because happens in MS-DOS,
does that mean it needs to do the same thing in FreeDOS.
Even if it is a bug in MS-DOS?

:-)

Jerome



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

[Freedos-devel] REMember a bug

[Jerome Shidel]

Hi all,

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?

Personally, I think it should be fixed. No one should be using that. If they 
were, I feel they are technically just exploiting a bug and there is no 
obligation to continue supporting that “feature.”

I don’t/won’t work on FreeCOM. I’m just curious about your thoughts on this. 

:-)

Jerome


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

Re: [Freedos-devel] Installer NLS Questions

[Jerome Shidel]

Hello,

> On Jan 7, 2022, at 7:12 AM, Emir SARI via Freedos-devel 
>  wrote:
> 
> Hello Jerome,
> 
>> Boot to standard US English Codepage.
> 
> Changed the codepage to 437, verified with broken Turkish display characters.
> 
>> Then run them through the conversion program (mkvV8Font). You will see that 
>> some characters in the normal codepage are aligned differently. You will 
>> want to tell it to include those in the new font as well (Press Y). If you 
>> tell the program to try auto mode, I don’t recall if it will auto-accept 
>> different alignment. It’s been a while since I through that program together.
> 
> Run the CP857.FNT font file through the program (just gave the file name as 
> argument), manually approved all characters with “y”, it told me that it 
> saved all the characters. I see that there is a file named .V8F is saved, 
> renamed it to CP857.V8F.
> 
> On another note, all characters baseline seemed to be the same.
> 
>> Once, you created the V8F file. While still Using the English codepage, load 
>> it using vfont and just set LANG=TR. The run"PKGINFO /d /p” to output a 
>> bunch of text and verify it looks correct. 
> 
> It says: “Invalid font file format”.
> 
> Did I do something wrong?

Hmmm, it is possibly a bug in the conversion program. It was thrown together 
very quickly and only has been used a couple times. 

So, did you approve all 256 characters or just the alpha-numeric ones? If it 
was just yes to everything, the program might have had issues generating the 
V8F file. 

Did you make any character changes? If so, send me a set and change them over. 
If not, I’ll just convert the existing version I have again. Making sure to 
include all alphabet characters. Not just the language changed/new ones.

Jerome



> 
> Best regards,
> Emir (ఽ఺఍)
> 
>  ** E-mail needs to stay simple
>  ** Use plain text e-mail
> 
> ___
> 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] Installer NLS Questions

[Jerome Shidel]

Hello Emir,

> On Jan 6, 2022, at 3:32 AM, Emir SARI via Freedos-devel 
>  wrote:
> 
> Hello Jerome,
> 
>> Let me know if you run into any problems or have any questions.
> 
> I’ve tested the Turkish characters file with imgedit. As far as I can see, 
> the glyph ascenders and descenders for Turkish-specific characters are 
> in-line with the other standard characters. Is there something that I’m 
> missing?

Probably not.

Boot to standard US English Codepage.

Then run them through the conversion program (mkvV8Font). You will see that 
some characters in the normal codepage are aligned differently. You will want 
to tell it to include those in the new font as well (Press Y). If you tell the 
program to try auto mode, I don’t recall if it will auto-accept different 
alignment. It’s been a while since I through that program together.

Once, you created the V8F file. While still Using the English codepage, load it 
using vfont and just set LANG=TR. The run"PKGINFO /d /p” to output a bunch of 
text and verify it looks correct. 

:-)

Jerome

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

Re: [Freedos-devel] dir /od

[Jerome Shidel]

Hi,

> On Jan 3, 2022, at 1:35 PM, Jim Hall  wrote:
> [..]
> That's a cynical and disingenuous statement. Development happens all
> over, and some folks prefer using different tools. Perdition set up
> his kernel repo in GitHub because that was his tool. And he did that
> before we set up the GitLab repo for FreeDOS (gitlab.com/freedos) so
> the kernel isn't in there.
> 
> I think we should merge the kernel back into the new FreeDOS GitLab
> repo, now that we have one. But that's a separate discussion I'll
> start with Perdition.

I’ve had similar thoughts regarding FD-NLS. I’ve thought about moving it over 
to the GitLab Repo.
But, It’s been fairly active with contributions and I’d need to talk the 
Translators into moving over. 

Same goes for the Installers (FDI & FDI-x86). They should probably be moved as 
well. 

Perhaps, post 1.3-Final.

At present, the versions in GitLab are mirrors of the Github ones and kept up 
to date automatically. 

Jerome

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

Re: [Freedos-devel] dir /od

[Jerome Shidel]

If you want to put stuff into or take stuff out of a Virtual Machine hard 
drive, you should stick with a Flat Fixed Size VMDK. That is one that is not 
split into pieces and is pre-allocated to the entire size. You end up with two 
files for the Virtual Machines hard drive. One is a descriptor/configuration 
file. The other file is a normal disk image even if it is using a different 
file extension. That image can be burned to USB sticks or mounted easily on 
Linux, Unix, Mac and related systems. There are programs for Windows that can 
also mount standard image files. Other formats are just that… other formats. 
Good luck trying to mount those to copy stuff around. 

The USB stick images for the FreeDOS release are created in a reverse process. 
The RBE creates an image file. Mounts it and puts all the stuff onto it. Then 
the RBE programmatically generates the descriptor/config file for that image. 
This provides a VMDK that can be mounted by many Virtual machine platforms. 

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

Re: [Freedos-devel] Installer NLS Questions

[Jerome Shidel]

Hi Emir,

Since I haven’t got around to making a doc for creating the V8F font files, 
here is the easiest way…

For Turkish, make sure you have a copy of the raw font from FD-NLS. 

https://github.com/shidel/fd-nls/blob/master/fdi/language/CP857.FNT 


And get a copy of mkV8Font.exe from 
https://github.com/shidel/makeV8Font/blob/master/MKV8FONT.EXE 


You will also need ImgEdit and V8Power Tools. These are both installed in RC5 
with FULL. However, 
you can also retrieve them from:

https://fd.lod.bz/repos/current/pkg-html/imgedit.html 

https://fd.lod.bz/repos/current/pkg-html/v8power.html 


You may want to do this in DOSBox. it is easier to copy things in and out.

Once you have all you need…

The edit the font using ImgEdit. Other editors may work. But, IDK. 

run:imgedit cp857.fnt
make any changes and save the file.

use:vfont cp857.fnt
Temporarily loads the font so you can test it.  

when your satisfied. 
run: mkv8fnt cp857.fnt

It will ask examine the default characters and compare them to your font. 
(y/yes means use my char, n/no means use the default).
You probably don’t want auto mode and let it use the defaults for unchanged 
characters. 
Once done it will create a V8F font file. 

you should reset your text mode to load the default character set. 
you can use: vmode 3

now test the V8F file
run cp857.v8f

Anyhow, it’s not hard to do. :-)

Let me know if you run into any problems or have any questions.

:-)

Jerome



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

Re: [Freedos-devel] mkey keyboard

[Jerome Shidel]

> On Dec 31, 2021, at 1:02 PM, tom ehlert  wrote:

> However I react supercritically when people that never contributed
> anything suggest that I contribute some  work.

I hope you are not suggesting the Wilhelm does not contribute.

While he may not write code, he has put a lot of work into cleaning up the HTML 
help,
provided numerous translations and translation fixes and has done a lot of 
release and
software testing. My guess that just over the past several months, he has 
contributed 
dozens or even hundreds of hours of his time helping improve FreeDOS. 

Thank you William for all the work you do. 

Jerome

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

Re: [Freedos-devel] Installer NLS Questions

[Jerome Shidel]

> 
>> While the installer (FDI) is not fast, the main issue is your whole VM is 
>> really slow. I could even see the initial boot menu drawing each line. I 
>> think most of the “slowness” your experiencing is video related. You really 
>> want to enable some sort of acceleration. Jim has shared his invocation of 
>> QEMU a couple times. I think the command line may be longer than "War and 
>> Piece". 
> 
> Thanks for the link! Some of the commands seem deprecated or removed, but 
> I’ll try to research on this, and being on macOS, KVM acceleration is not 
> present I believe. But, thanks.

Your welcome.

If your on an Intel based Mac, I recommend using VirtualBox. It’s free, fairly 
easy to use and works well enough. 

Although, if you scale the display to something other than %100, it can be 
sluggish. But, that probably has a lot to do with the model of Mac and it’s 
video card.


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

Re: [Freedos-devel] Installer NLS Questions

[Jerome Shidel]

Hello,

> On Dec 31, 2021, at 5:03 AM, Emir SARI via Freedos-devel 
>  wrote:
> 
> 
> Hello everyone,
> 
> I have been making the final tests for the installer in Turkish, and have 
> some questions below.
> 
> Also, the installation process seems to be pretty slow on QEMU. I have used 
> qemu-system-i386 -m 32m -drive file=drivec.img,media=disk,format=raw -drive 
> file=FD13LIVE.iso,media=cdrom -boot order=d command. Any suggestions for 
> improving the speed are welcome.

While the installer (FDI) is not fast, the main issue is your whole VM is 
really slow. I could even see the initial boot menu drawing each line. I think 
most of the “slowness” your experiencing is video related. You really want to 
enable some sort of acceleration. Jim has shared his invocation of QEMU a 
couple times. I think the command line may be longer than "War and Piece". 

https://sourceforge.net/p/freedos/mailman/message/36905969/ 


> I am also attaching the videos of my installation[1]. I understand that 
> letters with accents and diacritics might shift a little bit, but the Turkish 
> letter ı also seems to shift. It would be nice to improve this a bit.

Yep, it could use a better Turkish font. 

The installer itself needs to repeatedly change fonts and does not use the 
codepage system. It uses vfont and V8F (vfont font files) to accomplish that. 
The V8F files contain only the subset of characters that need to be changed 
from the default character set. That can include the standard ASCII characters 
or not. vfont can load normal FNT files (like those in the GNUFONTS package). 
But, for the installer (and limited space on floppies) it uses the V8F format 
files to cut the size in half or greater. 

I need to make a doc file on “how to make those v8f files”.

Anyhow, that is all maintained at 
https://github.com/shidel/fd-nls/tree/master/fdi/language 


> There is also a small visual glitch before changing the installer language 
> into Turkish (see the video).

Since the installer does not clear the screen it will always be there. 
That mostly goes away with faster video and looks better than everything 
vanishing and reappearing. 

> 
> I will send a patch once I have improved the needed areas.
> 
> Whilst checking, I have noticed that I am not sure about how all the failure 
> messages are handled, I could not find the frame width for it. I guess they 
> are displayed full screen. If so, please ignore.

I didn’t see any failure messages in the video. 

But, if you mean just in general… There are only two. One for normal mode and 
one for advanced mode. 
See the section starting at line 113 in the english version. 
https://github.com/shidel/fd-nls/blob/6fe293d50feeb938de3bd8c8c700a53740f2d652/fdi/language/en/FDSETUP.DEF#L113
 


> 
> There is another issue with the keyboard layout name definition files. I 
> would like to make some corrections, like some countries are defined by their 
> names instead of the language name (e. g. Brazil, Holland, Denmark etc.). 
> Also some layouts are not clear, like which French is the AZERTY one? I want 
> to proceed with the changes but I am not sure how to handle the encoding. I 
> can modify them to UTF-8, and make corrections in all languages, would that 
> be okay? I think we can change all languages before the release. I can 
> proofread Turkish and Russian and send a public patch for everyone to see 
> after changing the languages.

First, the installer files can not be in UTF format. 

Also, Do not modify and submit updated versions of the files on the install 
media. Most files of the installer files on the install media undergo a little 
or a lot of modification by the release build environment (RBE). Consider those 
files compiled executables. Changes need to be made at the source level. 

If I understand what you are asking….

There are two separate systems in the installer regarding keyboard settings. 
The first is the Main selection screen. The installer attempts to pre-select 
the one matching the users language. The number of keyboard selections matches 
the number of languages the installer itself supports. 

The second system is slower but allows any number of additional keyboard 
choices. 

When looking at the keyboard sources, the distinction is a little clearer. 

If the installer was an EXE, it would use only one system for selecting 
keyboards. However being batch based, breaking it into two pieces yields better 
performance and overall works better.

> 
> Also, it was a while ago, but I was also able to start the Jerome’s new 
> installer in Turkish. How to start that and from where? I would like to test 
> that one as well.

New installer? Do you mean the FloppyEdition installer (FDI-x86)?

Although there are translations for 

Re: [Freedos-devel] Thank you Jerome

[Jerome Shidel]

Hello All,

You are welcome and Thank you. 

There just are not enough hours in a day. 
But what I can manage to squeeze in, I try to get done.

:-)

Jerome


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

Re: [Freedos-devel] Bare Metal installation of FreeDOS

[Jerome Shidel]

> On Dec 27, 2021, at 11:16 PM, richardkolacz...@hotmail.com wrote:
> [..]
> In the above link, photo 002.jpg illustrates error with CD-ROM initialization 
> - attempting to use the UDVD2 CD driver -error 255 (failed). Any ideas how to 
> fix? My laptop has an internal DVD drive (laptop about 8 years old).

If you are having problems with UDVD2 on your system, you may need a different 
driver.

There are several CD/DVD drivers that the CD initialization routine will try 
(when present) before attempting UDVD2. Unfortunately, those drivers are not 
open source and are not included in the release. 

I suggest VIDE-CDD.SYS or OAKCDROM.SYS. Both are fairly easy to to find and 
freely available online (google). 

Just put the SYS file(s) in the %DOSDIR%\BIN directory (ie. FREEDOS\BIN) and 
the CD initialization will see the driver(s) and try it first.

:-)

Jerome

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

Re: [Freedos-devel] Two remarks about FreeDOS 1.3 RC5

[Jerome Shidel]

Hi Juan,

> Hello.
> 
> I can access the site without any issues at all but anyway an
> alternative location is:
>  ftp://ftp.fu-berlin.de/pc/languages/djgpp/current/v2tk/l290d10b.zip
>  ftp://ftp.fu-berlin.de/pc/languages/djgpp/current/v2tk/l290d10d.zip
>  ftp://ftp.fu-berlin.de/pc/languages/djgpp/current/v2tk/l290d10s.zip
> If for some reason this also does not work, then you can check for a
> set of djgpp mirrors at:
>  http://www.delorie.com/djgpp/getting.html
> 
> Kind regards,
> Juan M. Guerrero

I should have posted an update that I was able to download them delorie.com 
 earlier today. I’ve updated our version to 2.9.0-dev.10r2 
(release 2). 

Thank you

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

Re: [Freedos-devel] Bare Metal installation of FreeDOS

[Jerome Shidel]

Hello,

> On Dec 27, 2021, at 7:41 AM, richardkolacz...@hotmail.com wrote:
> 
> Jerome
> 
> 
> Thanks for your detailed instructions - HOWEVER  nothing seemed to work for 
> me.
> 
> 
> With my Windows 10 computer, I could not even get to any install screen (for 
> FD13 RC5), even IF I wanted to use full install USB stick for hard drive 
> install (maybe I just misunderstood your instructions). So for instance I 
> could not get to the FDISK stage.
> 
> Using RUFUS to FAT32 format usb and the usb img file results in an error 
> message (and the usb stick is "dead" now) - as below.
> 
> 
> I hope the following links (photos of attempts for FreeDOS install) are 
> self-explanatory.
> 
> 
> 
> When using RUFUS with FD img file
> 
> https://www.dropbox.com/s/bevyd8dn2nfg18c/FreeDOS13_format_error.PNG?dl=1
> 

This makes me wonder if there is an issue with the USB stick itself. 
Or, if RUFUS is manipulating the IMG before writing it.

For all intents and purposes, I haven't used Windows in 15+ years. I do have a 
Win10 box. But other that cross-compiling and video conferencing, I basically 
don’t use it. So unfortunately, I have know idea what RUFUS may or may not be 
doing when it writes the image to the USB stick. 

> With FD 13 RC5 on NTFS formatted usb stick (booting from this)  --> no OS
> 
> https://www.dropbox.com/s/x3lh2tu6w6lbfoc/noOS_IGP2203.JPG?dl=1

The OS does not natively support NTFS. 

Booting from and using FAT32 is not a problem.

> Using RUFUS to format FAT32 with RUFUS version of FreeDOS
> 
> https://www.dropbox.com/s/x4cf6dg4d440g30/Rufus%20IGP2204.JPG?dl=1

Since the RUFUS version of FreeDOS boots… This should work.

Download the LiveCD. 
Extract the zip and mount the iso image.
copy the FDOS-x86 and packages directory from the CD to the USB stick. (The 
rest won’t be needed)
boot the USB stick.
change to FDOS-x86 and run “setup adv” (no need to backup, make sure your OS 
Target drive matches the USB stick — drive C: also probably skip updating the 
MBR)

That should install BASE and allow you to install packages using FDIMPLES.

Otherwise, you can do stuff manually and you can get a mostly working version 
of FreeDOS.  But, the directory structure will probably not match what is 
expected by many things and you may run into many minor issues. But, it is 
doable.

Jerome

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

Re: [Freedos-devel] Bare Metal installation of FreeDOS

[Jerome Shidel]

Hi, 

> On Dec 26, 2021, at 5:32 AM, richardkolacz...@hotmail.com wrote:
> 
> I am investigating installing FreeDOS 1.3 RC5 as a bare metal installation 
> (i.e. everything is on a 16 GByte USB stick) and will try to boot off the USB 
> stick (i.e. the USB stick becomes the C:\ drive and so the hard drive with 
> Windows 10x64 is not accessible).
> 
> I have never used FreeDOS before - a while ago I experimented with a RUFUS 
> formatted USB stick FAT32 and used same as a bare metal setup for DOS (and 
> with some 30 year old 16 bit software and a special DOS version recent 
> software package).
> 
> A partial list of DOS-type files on the USB stick include HIMEM.exe 
> UMBPCI.sys MEM.exe MORE.exe EMMEX.exe EMM386.exe XDVD2.sys RDISK.com and 
> others (all are dated later than 2005).
> 
> At this stage I wish to avoid say using (DOSbox and DOSbox-X) and Virtual 
> Machine.
> 
> 
> From my experimenting with above I was happy to, from DOS environment, to 
> actually access a 3200x1800 display (though I did end up with only about 240 
> colors - not millions of colors). There were a number of issues I could not 
> sort out with my previous bare metal configuration.
> 
> The computer I am using has an INTEL i7 x64, 256 GByte PCIe SSD, 4TByte SSD, 
> built-in DVD drive, 32 GByte RAM and 3200x1800 display. The computer is about 
> 8 years old.
> 
> If I understand correctly, all your releases are for actual installation on a 
> hard drive - i.e. not for installation onto a USB BOOT stick. Because I had 
> serious problems when I previously tried to have dual boot (Windows initially 
> installed + LINUX later) - resulting in computer not being useable for 2 
> weeks until I could finally completely re-install Windows + apps - I do not 
> wish to install anything onto the hard drive (at this stage).
> 
> Is it possible to have a zip file of the individual FreeDOS programs - so 
> that I can copy same to my already FAT32 formatted USB stick (i.e. as  a 
> "parallel" DOS-type operating system)?
> 
> I look forward to using FreeDOS, though I may be initially faced with various 
> issues for my bare metal configuration requirements.

There is a way to install FreeDOS to a USB stick by only using a USB drive…
• Download FD13-FULL usb stick images. 
• On a Unix, Linux or macOS use dd to write that image to the Flash 
Drive. There should be a Windows equivalent to dd (I don’t know what it is). 
The image should be written as-is and not stretched or modified by the program 
writing it.
• Boot the Flash Drive and exit the installer.
• Use FDISK to manually create an additional partition on the USB stick 
and reboot again.
• Use FDISK to identify the drive letter assigned to the new partition 
and exit. (I will assume it is E:)
• Change directories to C:\FDOS-x86
• Run “setup E:\FREEDOS” 
• (answer the prompts, and install FreeDOS)
• Reboot

There is a minor bug in the FloppyEdition installer that I just discovered 
while doing this myself. Once the system reboots, there will be an error 
loading the shell (COMMAND.COM). Until the next OS release, this is how you fix 
it.

• type “C:\COMMAND.COM” and hit enter
• type “FREEDOS\BIN\EDIT FDCONFIG.SYS” and press enter
• there are two lines near the end that will have “/C:1024” change them 
to “/E:1024”, save and exit.
• reboot

That should provide you with a BASE FreeDOS install. The original partition 
will still be available and you can use FDIMPLES or another package manager to 
add or remove different programs as needed. 

There is a way to do something similar using the Primary Installer. However 
depending on your hardware and BIOS, using the FloppyEdition installer is more 
reliable. 

:-)

Jerome



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

Re: [Freedos-devel] Two remarks about FreeDOS 1.3 RC5

[Jerome Shidel]

Hi,

> The second issue is that the DJGPP port of lynx distributed with RC5 is
> broken. As I have announced in:
>  https://www.delorie.com/archives/browse.cgi?p=djgpp/2021/12/02/18:54:50
> the fixed port is available as:
>  http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10b.zip
>  http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10d.zip
>  http://ftp.delorie.com/pub/djgpp/current/v2tk/l290d10s.zip
> Please note the time stamp of 2021-11-30 or later for the zip files.
> Please use the fixed port in your distribution so I do not get bug
> reports about things that have already been fixed.
> 
> Kind regards,
> Juan M. Guerrero

I was going to update our version now. However, the site appears to be down at 
present.

Jerome

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

Re: [Freedos-devel] Let me count the ways

[Jerome Shidel]

Hi Tom,

> On Dec 25, 2021, at 3:47 PM, tom ehlert  wrote:
> [..]
> being a programmer, I had expected that ALL of these different methods
> to install freedos would have resulted in 2 possible different
> outcomes: normal mode, and advanced mode.

The "normal ways to install list" makes it seem more complicated than it is in 
reality.

When it comes down to it, there are really just the two installers FDI and 
FDI-x86 that 
have normal and advanced modes. The rest are options in the installers for 
things 
like languages, keymap, etc.

Being batch file based, the installers rely heavily on FreeCOM and other tools. 
There 
are numerous work arounds in it for older shell bugs that may no longer exist 
and 
even some newly detected ones. 

For example, there is a bug in FreeCOM that affected the installer since 1.2 
that 
more or less went undetected for over 5 years. It would only crop up in some
edge case installs. Once I discovered that issue, I reworked that part of the 
installer
to avoid the bug. I also submitted bug reports on that and several other issues.

( If you want to read more about the bugs I found in FreeCOM recently, check out
the bug reports at https://github.com/FDOS/freecom/issues 
 )

Everything else is just different media and ways to boot/launch the installers 
and
variables in the installer.  So, it’s not nearly as bad as the list made it 
seem. 

That being said, many of those ways do get tested originally and occasionally 
as 
changes are made. 

Mostly, the list is to point out that — like with all things... The further 
down the list 
you go increases the possibility of finding undetected or unforeseen issues. 
Testing 
the more obscure methods is always very helpful.

:-)

Jerome


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

[Freedos-devel] Let me count the ways

[Jerome Shidel]

Thank you for your help in testing RC5.

So far, testing has gone very well. 

Regarding installation and the media, there have been a few minor issues that 
have been already corrected. A couple that still need fixed and a few things 
that need investigated further. This of course is not referring to bugs 
reported in things like the drivers, installed programs, kernel, etc. Just the 
two installers and release media. Most issues were regarding NLS. 

There are a multitude of ways to install FreeDOS 1.3-RC5. There are so many 
variations it is impractical for just a few people to test. Having the 
community root out edge case issues is a big help. 

How many variations for installation can occur? Let me count (most of) the ways…

boot LiveCD to Live Environment, run setup. (uses primary installer FDI, normal 
mode)
boot LiveCD to Live Environment, run setup adv (FDI in advanced mode)
boot LiveCD to Live Environment, change to FDI-x86 dir, run setup (uses 
FloppyEdition installer, FDI-x86 in normal mode from a subdir)
boot LiveCD to Live Environment, change to FDI-x86 dir, run setup adv (FDI-x86 
in advanced mode from a subdir)
boot LiveCD to Install to Hard Disk. (FDI in normal mode)
boot LiveCD to Install to Hard Disk, exit and run setup adv (FDI in advanced 
mode)
boot LiveCD using Easter Egg, (FDI-x86 in advanced mode from a HD image)
boot LiveCD using Easter Egg, exit installer run setup (FDI-x86 in normal mode 
from a HD image)
boot LegacyCD (FDI in normal mode)
boot LegacyCD, exit and run setup adv (FDI in advanced mode)
boot LegacyCD, exit, change to FDI-x86, run setup (FDI-x86)
boot LegacyCD, exit, change to FDI-x86, run setup adv
boot LiteUSB (FDI in normal mode)
boot LiteUSB, exit and run setup adv 
boot FullUSB
boot FullUSB, exit, run setup adv
boot FullUSB, exit, change to FDI-x86 dir, run setup (FDI-x86)
boot FullUSB, exit, change to FDI-x86 dir, run setup adv
boot FloppyEdition (any diskette version), (FDI-x86 normal mode)
boot FloppyEdition (any diskette version), exit, run setup adv (FDI-x86 in 
advanced mode)
xcopy FloppyEdition to some hard disk subdir and run setup.
xcopy FloppyEdition to some hard disk subdir and run setup adv.

all the CD versions, boot from CD boot Floppy and repeat.
all versions, preexisting OS installed or not, then with backup or not.
all versions, BASE or FULL, with our without sources.
all ADVANCED FDI installers, custom user package selection.
all FDI versions, variations on user language and keyboard settings.

Once that is done, repeat all steps on different virtual machines and different 
hardware.

Perhaps if your good a math, you could figure out all the permutations. Don’t 
forget all those multipliers. :-)

And this only covers the most likely scenarios. There are others.

Only the config and boot process changes.  The two installers and tools are the 
same. While many of the items mentioned effect the installers in subtle ways, 
some tests only verify no pieces went missing during media creation. 

It’s far to much for one or two people to fully test. 

Once again, thank you for your assistance.

:-)

Jerome



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

Re: [Freedos-devel] Two remarks about FreeDOS 1.3 RC5

[Jerome Shidel]

> On Dec 24, 2021, at 5:27 PM, Juan Manuel Guerrero  
> wrote:
> 
> I have been playing with the latestet FreeDOS 1.3 RC5 and I have
> observed that the line:
>  if exist %dosdir%\LINKS\NUL set PATH=%path%;%dosdir%\LINKS
> in FDAUTO.BAT does not work because LINKS and all the other network
> stuff is installed in the C:\NET directory and not into the directory
> pointed by %dosdir%. E.g.: LINKS is installed in the directory
> C:\NET\LINKS.  Thus the above line in FDAUTO.BAT will never work.
> Either the NET directory is removed and its content is moved into
> %dosdir% or the above line is adjusted accordingly so it points to
> C:\NET.

The PATH setting for %DOSDIR%\LINKS has nothing to do with either 
networking or the LINKS web browser. It is a directory where the package
manager places small com or batch files that “link” to programs that are
not generally included in the PATH settings. 

Depending on wether or not a full installation is performed. Or, if other 
packages that use the %DOSDIR%\LINKS directory are installed, that
directory may or may not exists. That is why was entered into FDAUTO
using the IF EXIST statement and not just always set into the PATH.





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

[Freedos-devel] The land that time forgot

[Jerome Shidel]

Hello Everyone,

Recently, I noticed we had translations for a program that was not in the 
online repositories. This caused me to to do some digging and I found out 
something rather interesting. 

Many years ago when FreeDOS 0.9 SR2 was released, it included several things we 
seem to forgotten about. There are programs and drivers present that are not in 
more modern releases. Some of these are were not in any of the repositories or 
even the file archives on ibiblio. They were only on the CD itself.

One such item I noticed was the ATAPICDD driver. It might be nice to have an 
alternate CD driver that might cover some additional hardware. So, I added to 
that one to the repos. But, I don’t know much about this driver other than it 
is open source. I don’t know if it will cover any hardware not currently 
supported. I don’t know if it is rock solid or buggy. I don’t know if we should 
include it in the release or not. I know very little about it.

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/atapicdd.html
 

https://gitlab.com/FreeDOS/drivers/atapicdd 


I’m going to try to find some time over the next few days to do some testing of 
that driver. But, I’d appreciate any feedback on it the group has regarding it. 
Does anyone remember anything about it? 

I would assume that when it comes to old programs most things that have been 
replaced or removed for good reason. But, this also raises an additional 
question. Are there other programs that we may have included long ago that we 
should re-examine now?

:-)

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

[Freedos-devel] RC4 Videos (was Testing FreeDOS 1.3 RC5)

[Jerome Shidel]

Hi Louis,

> On Dec 24, 2021, at 4:36 AM, Louis Santillan  wrote:
> 
> 
> An interesting (and series of very very long) "hot takes" of FD 1.3RC4 from 
> the "Temporarily Offline Retro Tech" youtube channel.

I’ve seen all but part 4 (which I’m going to watch in a few minutes). I didn’t 
think to mention them here. I’m glad you did.

His video’s provide a very ingesting perspective on RC4. Some of which has 
changed in RC5. Many things have not. 

He is new to FreeDOS but not new to DOS. Watching the videos, points out 
several glaring issues that should be resolved. 

> 
> FreeDOS Install and Bundled Apps - Part 1
> https://youtu.be/j6s50qGZzO4 
> FDOS! What's in the FDOS folder? - FreeDOS Part 2
> https://youtu.be/v-_RqLP_Bgs 
> More FDOS! = The Executables #DOSCember
> https://youtu.be/Qph-cg7K9bs 
> The Return of FreeDOS | Part 4 | The wrap!
> https://youtu.be/g892q2XxcKs 
> 
> 
> 
> On Wed, Dec 22, 2021 at 11:07 AM Jim Hall  > wrote:
> On Wed, Dec 22, 2021 at 12:45 PM Bret Johnson  > wrote:
> > I realize that VMs are all the rage these days for DOS, but I would
> > also like to see how things work on real hardware.  I rarely play
> > games myself any more, but games are usually a pretty good test of
> > compatibility.
> [..]
> 
> Yes, that's why I started this discussion thread. I'd love for others
> to test and share their experiences here.
> 
> Please test on real hardware and reply on this thread. Good to have
> testing all around.
> 
> Jim
> 
> 
> ___
> 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 mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Testing FreeDOS 1.3 RC5 (Games)

[Jerome Shidel]

Hi, Jim

Because, there are also VM’s like VMware, DOSBox, DOSBOX-X, Bochs, etc.

It might be good for you to start a compatibility spead-sheet. 

Jerome



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

[Freedos-devel] FDIMPLES support for BonusCD

[Jerome Shidel]

Hello All,

> On Dec 19, 2021, at 2:58 PM, Radek Krzyśków  wrote:
> [..]
> 
> 1) How to use `FDIMPLES` with Bonus CD?
> 
> Running `FDIMPLES` with "FD13BNS.ISO" shows "Package media not
> found!", so I install additional software by manually unpacking ZIPs.
> `FDIMPLES` only recognizes "FD13LIVE.ISO" and I don't know how to
> enable it with the Bonus CD packages.


With all the recent and last minute changes, I completely forgot to make sure 
FDIMPLES worked with the BonusCD prior to releasing RC5. Not that it matters. 
But basically, changes to that CD caused it to drift slightly out of compliance 
to how FDIMPLES identifies local package sources. 

Anyhow...

I’ve just updated FDIMPLES to version v0.11.2. It now has better support for 
such things and works the BonusCD. Of course, the new version will be on the 
next OS release. Nut, you probably don’t want to wait until then. 

You can download it directly from the Official FreeDOS repository on ibiblio at:
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/fdimples.html
 


Or, from my personal FreeDOS repo at:
https://fd.lod.bz/repos/current/pkg-html/fdimples.html 


Or, even from the GitLab Archive at:
https://gitlab.com/FreeDOS/apps/fdimples 


Or, if you have networkings support in you installation of FreeDOS, you should 
be able to just run:
fdnpkg update fdimples

:-)

Jerome

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

Re: [Freedos-devel] FDTUI and Minibox

[Jerome Shidel]

It wouldn’t hurt to report it to our GitLab issues as well. 

Then, if the developer no longer wants to update it, we will at least have it 
listed and possibly get to it ourselves at some point. 
Also, it will let anyone who intends to report the bug on our tracker, know it 
has already been reported.

:-)

Jerome

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

Re: [Freedos-devel] FreeDOS 1.3-RC5

[Jerome Shidel]

Hi,

> On Dec 10, 2021, at 2:02 AM, thraex  wrote:
> 
> 
> 
> On 9.12.2021 18:35, Jerome Shidel wrote:
> 
>> 
>>> * When launching PGME, I couldn't find the PGME.BAT file. So I can't
>>> start FDIMPLES for instance.
>> 
>> There is no such file as PGME.BAT. 
> 
> Ouch. PGM.BAT works just fine, I was looking for PGME.BAT, my bad.

No problem. 

When PGME is installed using it’s installer, it mentions the batch loader PGM. 
But when installed via FreeDOS package, there isn’t a good way to make these of 
PGM.BAT obvious. 

It doesn’t matter but… Technically, it is Program Manager version Eternity 
updated last on whatever date. Not Program Manager Eternity version (some 
date). So the E is actual a version reference. Even the abbreviated PGM is a 
through-back to an earlier time when it was once called “Program and Game 
Menu”. It has been around a very long time. It has been renamed several times 
and it’s first real version was just called Menu and ran on MS-DOS 3.3. 
However, that was my first use of DOS and I found a need for it almost 
immediately. However, it’s roots pre-date my first use of MS-DOS and the PC.  
The seed for what would eventually become PGME was first planted circa 1983-84 
on the Coleco Vision Adam and some bit hacking I did on a third party 
multi-boot game loader I did not make. 

> 
>>> * Speaking of FDIMPLES, it doesn't display Turkish characters like ş, ğ,
>>> ı and so on.
>> 
>> Well, the problem would not be FDIMPLES itself. It doesn’t care what 
>> character is being displayed. The exception being when converting 
>> upper/lower case may have odd behaviors with non-english characters.
>> 
>> That leaves the original translation, code page conversion, possible old 
>> metadata that has not been updated, an issue processing the meta-data by one 
>> of the package management utilities or processing done in the RBE.
>> 
>> It will need further investigation.
> 
> Okay, have fun :-P As an additional information, French letters such as
> é, ê, è and so on aren't displayed either.

Hmmm. Sounds like one of the utilities on Linux may be stripping down the 
characters. 

>>> But the Turkish Q keyboard doesn't work
>>> after installation (haven't tested the F layout yet) so bug # 306 on SF
>>> still seems to be with us.
>> 
>> Is it being set correctly in FDAUTO and just not working?
> 
> It would seem so. I see the line
> keyb TR,857,%DOSDIR%BINKEYBRD2.SYS
> in FDAUTO.BAT

Not %DOSDIR%\BIN\KEYBRD.SYS?

If those slashes are missing, it is a minor bug with the RBE not being told to 
escape the \ character. 

Please, file a bug report preferably at 
https://gitlab.com/FreeDOS/OS/builder/-/issues 
<https://gitlab.com/FreeDOS/OS/builder/-/issues> or on FD-NLS so I don’t forget 
to fix it. 
Also, one for the stripped characters. :-)

>> So to help determine what is going on. See it it still happens when LANG=EN. 
>> If it does, then the problem is probably not the FDNET.BAT file. 
> 
> Everything is working fine now. I don't know what the problem was and
> like Tom said, I should have written down the error message. Anyway, in
> English, French and Turkish in VirtualBox FDNPKG can connect and update
> the packages.

:-)

> 
>>> I also noticed some translation typos, stuff like a Parameter Error in
>>> French in CDROM.BAT, a /p in the installer in Turkish and some slight
>>> layout problems mem because of a missing space. After playing a little
>>> more with the new RC, I'll send corrections to FD-NLS.
> 
> Alright, the /p was enclosed in quotation marks, so this was easy.
> Regarding the Parameter Error messages, I noticed them in cdrom.fr and
> fdnet.fr for instance.
> 
> Let's consider:
> CD.TRY_DRVR= /g tentative d'utilisation du pilote CD /fYellow "%1" /fGrey
> in cdrom.fr, in English it's
> ERROR.HARDWARE=/fLightRed Physical hardware networking is not supported
> at this time. /fGrey /p
> or
> ERROR.HARDWARE=/fLightRed La mise en ré‚seau maté‚rielle n'est
> actuellement pas prise en charge. /fGrey /p
> in fdnet.fr -- in English it's
> ERROR.HARDWARE=/fLightRed Physical hardware networking is not supported
> at this time. /fGrey /p
> 
> I guess these are used in batch files and that the ' character is the
> problem. Should it be escaped or be in double quotation marks?

V8Power Tools and NLS it provides for batch files doesn’t use escapes for stuff 
like that. Instead, it uses a “flexible quote” system. 

There is a reference to it in the DOCs about it 
https://github.com/shidel/fd-nls/blob/master/v8power/help/en/v8power.en 
<https://github.com/shidel/fd-nls/blob/master/v8power/help/en/v8power.en>

But, it is something that can be easily forgo

Re: [Freedos-devel] FreeDOS 1.3-RC5

[Jerome Shidel]

Hi, 

> On Dec 9, 2021, at 8:55 AM, thraex  wrote:
> 
> 
> 
> On 9.12.2021 01:15, Jerome Shidel wrote:
>> Hello FreeDOS Community,
>> 
>> The wait for 1.3-RC5 is over. It has arrived!
> 
> Yay! Thank you!

:-)

> I gave it a quick try in VirtualBox after choosing French and Turkish in
> the installer and here are some remarks:
> 
> * Blocek needs to be updated to 1.62r2, translations do not seem to be
> included for 1.4

Not sure whats going on with Blocek. I’ve tried to run it a couple times in a 
VM, but have never been able to get them to work. So, IDK.

> * When launching PGME, I couldn't find the PGME.BAT file. So I can't
> start FDIMPLES for instance.

There is no such file as PGME.BAT. 

Instead of running PGME.EXE, just run PGM it is in the path spec. 

Basically, there are several ways to run PGME. As the warning states when you 
tried to run FDIMPLES, that when PGME is directly invoked by using PGME.EXE and 
not started through the Launch Batch file PGM.BAT (No E), some functions are 
not available.

When PGME launches a program, it reduces its memory footprint down to about 
10k. Usually, this is adequate. But for some programs or special tasks, PGME 
completely removes itself from memory using some batch magic. There are various 
reasons you may want PGME to completely exit memory. And generally, PGME 
handles wether or not it leaves a stub in memory or completely shuts down 
automatically. However, the free all memory / 0k footprint requires starting 
PGME through the launcher batch. PGME is smart enough to notice that you did or 
did not start it using the batch.

You can also start it to a menu or specific program… 

pgm games
pgm doom

And so on.

> * Speaking of FDIMPLES, it doesn't display Turkish characters like ş, ğ,
> ı and so on.

Well, the problem would not be FDIMPLES itself. It doesn’t care what character 
is being displayed. The exception being when converting upper/lower case may 
have odd behaviors with non-english characters.

That leaves the original translation, code page conversion, possible old 
metadata that has not been updated, an issue processing the meta-data by one of 
the package management utilities or processing done in the RBE.

It will need further investigation.

> * APPEND /? is in English whereas translations for several languages
> exist on FD-NLS repo.

We will need to check if APPEND is actually using any NLS. 


> * After installing in French, the keyboard layout is correct, so bug
> #282 on SF seems to be fixed.

Good.

> But the Turkish Q keyboard doesn't work
> after installation (haven't tested the F layout yet) so bug # 306 on SF
> still seems to be with us.

Is it being set correctly in FDAUTO and just not working?

> * In VirtualBox the network seems to be automagically detected, which is
> *great*. But when I try to use say FDNET, I get a packet driver error
> and it can't establish a connection. Has anyone tried to see if that
> works by default with a NAT connection?

Works fine for me in VirtualBox. Which is where I do most of my testing.

There were some changes in FDNet and the DHCP client was also updated. But, the 
packet drivers haven’t changed. 

So to help determine what is going on. See it it still happens when LANG=EN. If 
it does, then the problem is probably not the FDNET.BAT file. 

I’m always running the latest version of VirtualBox (6.1.30) on a Mac and the 
default VM config using PCnet-FAST III adapter as NAT works fine. 

DHCP reports:

IPADDR 10.0.2.15
NETMASK 255.255.255.0
GATEWAY 10.0.2.2
NAMESERVER 192.168.10.1 (which is correct for this subnet on my network)

> On my side the gateway is
> detected as 10.0.2.2 whereas it should be 192.168.0.1.

When using NAT, the gateway is some network range made up by the host computer 
and not your home network.
Using Bridged mode, kinda shares the ethernet adapter and puts the VM directly 
on the network (probably 192.168.x.x)

> I also noticed some translation typos, stuff like a Parameter Error in
> French in CDROM.BAT, a /p in the installer in Turkish and some slight
> layout problems mem because of a missing space. After playing a little
> more with the new RC, I'll send corrections to FD-NLS.

Sounds great.

> Thanks again for the RC5!

:-)

Jerome



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

[Freedos-devel] FreeDOS 1.3-RC5

[Jerome Shidel]

Hello FreeDOS Community,

The wait for 1.3-RC5 is over. It has arrived!

There are so many changes, improvements and updates that it is not practical to 
go into it all. But, I’ll point out a couple special things to look forward to 
in RC5.

New FreeCOM 0.85a
New Kernel 2043 and an 8086 version with FAT32 support.
FloppyEdition now uses compression and requires about 1/2 as many diskettes.
The return of FDNet
Some new programs and games.
Many many many package updates.
Some updates and improvements to NLS.
Better handling of if/when to overwrite the MBR. 
Some support to automatically set the COUNTRY.SYS information.
Improved CD initialization for the boot media and installed system.
much, much more.

As discussed during the online get-togethers, we intend to eventually move bug 
reporting from SourceForge over to the https://gitlab.com/FreeDOS 
 group page on GitLab. Around the release of 
1.3-Final, we will probably freeze reporting on SourceForge entirely. This will 
not effect the mailing lists. Only bug reporting will be affected. 

With the GitLab pages being the first stop to report bugs, a contributor can 
see all the projects related to FreeDOS. Also if that project is actively 
maintained elsewhere, there is a prominent link to point them at the developers 
website for reporting issues. 

Release announcement on the Website and places like Facebook will be made at a 
later time. But, you can go ahead and grab RC5 from the Official FreeDOS 
download site at 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc5/
 

 or from my server at https://fd.lod.bz/releases/1.3/previews/1.3-rc5/ 
 .  

:-)

Jerome


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