Hi, > On Dec 10, 2021, at 2:02 AM, thraex <thr...@numericable.fr> 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 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 Bob!"‘ Welcome to … "the House of Bob!” C:\vecho Use the ‘"/p"‘ switch for new lines. Use the "/p" switch for new lines. And so on. Programmatically what happens is... When it encounters one of the three quote characters, all other quotation characters are treated as plain text until the same quote character is encountered again. While within a quoted section, switches are not processed and spacing is preserved. If it is not found again, the quote has not been terminated and it will throw a "parameter error”. 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. Also, I’m wondering why there is a /g in there. That switch is used to switch from the local to global framing region. Might be a typo on my part or laziness. Since, the CD initialization script doesn’t use local regions, it won’t hurt anything. I’m just wondering why I stuck it in there. On a side note.. vecho is very flexible. To do NLS it uses a /T switch that points to a file and index string. The string is looked up and processed like it is part of a command line with variable “%1-%9” being expanded. Here is a little trick it can perform.I don’t actually use it because of the risk of getting stuck in an infinite loop and a couple other reasons. But, it is neat… @echo off goto start LINE.1=This is /f%2 line /a15 1 /fGrey/p /t %1 LINE.2 %1 Yellow LINE.2=This is /f%2 line /a15 2 /fGray/p /t %1 LINE.3 %1 LightGreen LINE.3=/b1/e This is /f%2 line /f15 3 /a7/p :start vecho /t %0 LINE.1 %0 Cyan 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. :-) 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
