Re: [Freedos-devel] FreeDOS 1.3-RC5 questions and bug-testing

[Ralf Quint]

On 12/19/2021 11:58 AM, Radek Krzyśków wrote:

Hello!

Here are a few questions and notes (testing new FreeDOS release on
VirtualBox 6.1.30)


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.


That's for Jerome to answer...




2) Env variables `%DOSDRV%` and `%FDRAMDRV%` are only set in LIVE CD
environment, but never set when launching the installed FreeDOS from
harddrive.

So you can only launch shortcuts from `C:\FreeDOS\LINKS\` if you are
currently on the `C:` drive, because paths like
`%DOSDRV%\GAMES\FILENAME.EXE` are parsed to `\GAMES\FILENAME.EXE` and
`\` at the beginning is equivalent for searching from root of the
current working drive.

If you switch drives (from "C:" to "D:" for example) then none of
"C:\FreeDOS\LINKS\*.BAT" shortcuts work, unlike the `PATH` variable
which works regardless of CWD.
Can't reproduce this. After the meeting I download and installed a local 
system from the LiveCD in VirtualBox 6.1.30 and all of that works just 
fine, not touching any settings and no %DOSDRV% or %FDRAMDRV% (which I 
think is only needed when in "Live mode" anyway)...


On the other hand, `%DOSDIR%` and `%CDROM%` are set correctly in
"C:\FDAUTO.BAT".


3) A random system (FreeCOM) crash that I cannot reproduce (after
editing "FDAUTO.BAT" and installing more packages), but it happened
constantly from a fresh installation:
```
REM "Full installation including apps and games"

REM Boot system from harddisk and ensure there is no disc in CD-ROM (D:) drive

C:\>d:
D:\>cd \
   Error reading from drive D: data area: drive not ready
   (A)bort, (R)etry, (F)ail?  [here, press any key]
   CHDIR failed for '\'.

D:\>c:
C:\>dir /w

   Interrupt divide by zero, stack:
   0053  3246 0DEB    00B3 0EF8 4200 6500 0119 0FAB

   Cannot terminate permanent FreeCOM instance
   System halted ... reboot or power off now_

Can't reproduce this neither...

Ralf



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



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

Re: [Freedos-devel] FreeDOS 1.3-RC5

[thraex]

On 10.12.2021 14:55, Jerome Shidel wrote:

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

Hm, I'll need to update the translations then.

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

Wow, the word "Eternity" makes more sense now.

 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. 

They are indeed missing. I added them and the keyboard layout seems to
be perfectly OK now.

> Please, file a bug report preferably
> at 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. :-)

Understood :)

> So, for your example you can “wrap” them several ways…
> 
> CD.TRY_DRVR= /g "tentative d'utilisation du pilote CD" /fYellow "%1" /fGrey
> ERROR.HARDWARE=/fLightRed "La mise en ré‚seau maté‚rielle n’est
> actuellement pas prise en charge." /fGrey /p
> 
> or
> 
> CD.TRY_DRVR= /g tentative "d'utilisation" du pilote CD /fYellow "%1" /fGrey
> ERROR.HARDWARE=/fLightRed La mise en ré‚seau maté‚rielle "n’est"
> actuellement pas prise en charge. /fGrey /p
> 
> or what ever makes sense to you.
> 
> Actually, since %1 won’t contain a quote character or /, it doesn’t
> actually need wrapped. It’s just habit. 

Thank you for the explanation. I had tried with double quotes and that
had gotten rid of the parameter errors but wasn't sure if that was the
right thing to do. Now, time to get work to wrap stuff correctly.

> Running TEST.BAT outputs three lines, with the “line” a different color
> and number with color attribute 15 (white on black). Also, the last line
> has a blue background the width of the display. (Grey and Gray are the
> same color)
> 
> 
> Anyhow, I hope that all makes sense. Looking forward to you pull request. 

Yes, thanks again. Bug reports and pull requests will be incoming in the
next few days :-)


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


But, it is something that can be easily forgotten or misunderstood. 

Basically, any one of the three different quotes can be used to wrap text, 
preserve spacing and 
prevent things from being processed as switches. 

Like so…

C:\>vecho 'His name is "Bob" not "Rob."'
His name is "Bob" not "Rob."
C:\vecho That is "Bob's" house.
That is Bob’s house.
C:\vecho Welcome to ‘   …"the House of 

Re: [Freedos-devel] FreeDOS 1.3-RC5

[thraex]

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.

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

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

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


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

Re: [Freedos-devel] FreeDOS 1.3-RC5

[Wilhelm Spiegl]

Hi Tom,

I regret that you had a bad day today.

 

The reason: thraex and I are translators of this (a little buggy) OS. I know several of them, among others I reported that in fdisk it is not possible to enter partition sizes bigger than 999 GB for FAT32 partitions because the possible number of digits does not support this. I assume this bug still exists although it is longer time ago since I reported it. You remember?

Years ago I reported that mkeyb gr mixes x and z in virtual box. I remember your answer... Years later it was fixed...

 

As I tested a lot of programs (Win, Linux, DOS) in the last 22 years of work, I learned that you never know what the programmer really wants to receive as error message - where the logs are - if there are some at all. I personally learned to give as much feedback as possible, but sometimes it is not possible or very hard to describe for someone who never learned programming. My experience was that screenshots are often helpful to show what I mean. But some programmers of FDOS do not like them as they need so much space in mails...

 

@Berki: have a look at Github,  zzz-notes-and-misc-items NLS-was-funzt-was-nicht, among others you will find:

"edlin" edlin files now have name edlin16/32 - NLS exists but DOES NOT WORK! PLEASE CHECK!

I think append and others that were translated by us had the same problem, so do not be astonished.

 

Willi

 

 

 
 

Sent: Thursday, December 09, 2021 at 6:35 PM
From: "tom ehlert" 
To: "Technical discussion and questions for FreeDOS developers." 
Subject: Re: [Freedos-devel] FreeDOS 1.3-RC5

Hallo Herr thraex,

am Donnerstag, 9. Dezember 2021 um 14:55 schrieben Sie:
> I gave it a quick try in VirtualBox
thanks for testing

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


'I get a packet driver error' is pretty useless for diagnosis.
I'm fairly certain there is more detail available for this concrete
error message.

Why don't you people spend the minimal effort to report the
EXACT ERROR that you get? even when many (modern?) error messages are
not helpful, some are. And it saves a full email round trip if you
tell us the error message on first contact.

Tom



___
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] FreeDOS 1.3-RC5

[tom ehlert]

Hallo Herr thraex,

am Donnerstag, 9. Dezember 2021 um 14:55 schrieben Sie:
> I gave it a quick try in VirtualBox
thanks for testing

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


'I get a packet driver error' is pretty useless for diagnosis.
I'm fairly certain there is more detail available for this concrete
error message.

Why don't you people spend the minimal effort to report the
EXACT ERROR that you get? even when many (modern?) error messages are
not helpful, some are. And it saves a full email round trip if you
tell us the error message on first contact.

Tom



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

Re: [Freedos-devel] FreeDOS 1.3-RC5

[thraex]

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
* When launching PGME, I couldn't find the PGME.BAT file. So I can't
start FDIMPLES for instance.
* Speaking of FDIMPLES, it doesn't display Turkish characters like ş, ğ,
ı and so on.
* APPEND /? is in English whereas translations for several languages
exist on FD-NLS repo.
* After installing in French, the keyboard layout is correct, so bug
#282 on SF seems to be fixed. 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.
* 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? On my side the gateway is
detected as 10.0.2.2 whereas it should be 192.168.0.1.

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.

Thanks again for the RC5!






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

Re: [Freedos-devel] FreeDOS 1.3-RC5

[E. Auer]

Hi!


Do we wait for a new KERNEL and FREECOM release?


Jeremy was almost ready with those quite a while ago,

It would be nice if RC5 had those. But, I don’t know how far off those 
are.


Very nearby, I would say.


If we don’t include updates for those in RC5, I don’t feel it would be
wise to update them for 1.3-FINAL.


I would rather delay the release of the next release candidate
than say "if the next kernel update takes too long, we could
simply sell the next distro with a 5 year old kernel". That
would be a big disappointment regarding what you get by using
the new update.

So, dear distro experts: Please awaken Jeremy to officially
publish the new KERNEL and FREECOM versions and find somebody
(sorry, I am away from my build system) to update the FDISK
partitioning wizard as well. Also, while waiting for those,
please make sure to use the newest UHDD, UDVD2, DEBUG, XMGR
and, if you like, HIMEMSX with patched giga-sized RDISK from
Mercury's download page. Sad that we still have no news of
AHCICD, regarding licensing, from the author's survivors. I
also strongly recommend to make the "no XMS" boot option and
similar 8086 friendly boot editions use KSSF freecom, as the
XMS swap version would take away too much app memory. Thanks!

PS: FreeDOS.org says new Bochs, Links and other updates are here :-)



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