[Freedos-user] Unicode and codepages in apps already bundled with FreeDOS?
Hi all, as part of a mail with Vacek, I made a list of apps from https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/report.html which MIGHT have some sort of Unicode and codepage awareness: By that, I mean that those apps can process input and/or output which are encoded using Unicode or some codepage and then show or otherwise process it either in Unicode or using the current codepage (which could get autodetected), or graphically, maybe including a custom non-codepage font. It surprises me that there are more than 30 suspects, but only a fraction of those will ACTUALLY have the features I hope them to have. Maybe you can help me to make the list more exact :-) HTMLHELP shows input (HTML with Unicode and entity support) using awareness of which chars exist in the current codepage. DN2 (DOS Navigator file manager, Ritlabs and Necromancer forks) may be able to handle file names or view files beyond simple "treat as 8-bit, assume it fits codepage". Same for the DOSZIP file manager and PGME (which even comes with fonts, I think). The SQLITE database engine may still contain Unicode support even though it may be of limited use in DOS. Like file managers, some archivers may be aware of filenames supporting encodings beyond the current codepage: 7ZIP just distinguishes DOS, WIN and UTF, whatever that means. 7ZDEC may just assume that Unicode chars 0 to 255 are your codepage? CABEXTRACT seems to rely on ICONV for Unicode? ZIP and UNZIP may or may not support encodings in their Infozip DOS ports? I do not expect any of the other archivers to ponder encodings. Some of the larger programming languages, often ports using 32-bit compilers for DOS, could support Unicode in some way: DOJS (JavaScript), Euphoria, FreeBASIC (FBC), FreePascal (FPC), Lua, Regina Rexx, Perl, OpenWatcom C, OpenWatcom Fortran maybe? I suspect filesystem drivers to have Unicode or codepage awareness, suspects are: DOSLFN, LFNDOS, NTFS, USBDOX :-) Among text editors, MinEd seems to be as Unicode- and codepage- aware as HTMLHELP: http://towo.net/mined/term-dos.png Blocek even comes with a graphical Unicode font. SETEDIT, ELVIS and VIM are powerful enough to possibly support various encodings? The FOXTYPE viewer explicitly supports Unicode. GNUCHCP is a bit of an alternative to the DISPLAY/MODE/CPI font ecosystem. UNRTF converts RTF to other text formats. Likewise, internet apps such as Arachne, Dillo, Lynx, Links, SSHDOS and SSH2DOS could support Unicode and other encodings? Media player MPLAYER probably does, too. Maybe also OPENCP? Last but not least, the OPENGEM GUI distro could contain encoding-aware apps or infrastructure? What are your thoughts? There might be more Unicode in FreeDOS than I had intuitively expected. Even when support is minimal, it would be cool to know that multiple apps grasp the concept of, say, UTF-8 and codepages being able to show a tiny subset of Unicode space and that a few apps even come with fonts with far more than 256 different chars already :-) Thanks for your insights! Regards, Eric PS: For all things NOT mentioned above, I expect no support for Unicode or conversions at all. I expect those to just assume an 8-bit encoding in text (and file names) matching your codepage. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] EtherDFS ver 0.8.3
Hello, I've published a new version of EtherDFS today: version 0.8.3. This version fixes a bug kindly reported by Jerome Shidel. https://etherdfs.sourceforge.net SvarDOS users can update it as follows: pkgnet pull etherdfs pkg update etherdfs.svp Others will have to fetch the new zip file from sourceforge. Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Confusing details about SET and redirection inFreeC OM
> Maybe put in quotes? In some circumstances you can put things in double-quotes at a DOS command-line to enclose "special" characters, but that doesn't always work and different versions of DOS do things differently. Probably the simplest example of this is enclosing a long-file-name (at least if it contains spaces) in double-quotes. But, as Eric noted, the double-quote character does some unexpected things when used with a SET command (like not even needing a closing quote). Enclosing things in quotes won't fix the problem, at least not consistently across all DOS versions. E.g., I just did a couple of simple tests in both MS-DOS 6.22 and 7.1: SET "Test=8" creates an environment variable named "TEST with the contents of 8". I also did: SET Test=Test=8 SET "Test=Test=8" and got syntax error messages in both versions of MS-DOS. *** In FreeDOS 1.2: SET "Test=8" does the same things as MS-DOS. But in FreeDOS 1.2: SET Test=Test=8 creates (correctly, IMHO) an environment variable called TEST with the contents of Test=8, and: SET "Test=Test=8" creates an environment variable called "TEST with the contents of Test=8". Bottom line is that FreeDOS (at least version 1.2) doesn't work the same way as MS-DOS, but I'm not 100% sure which way is "buggier". ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Confusing details about SET and redirection inFreeCOM
Maybe put in quotes? On Thu, Jun 22, 2023, at 10:07 AM, Bret Johnson wrote: >> Hi fellow users :-) >> >> I have been wondering which chars are special in SET >> in FreeCOM and whether they can be escaped or similar. > > I don't know specifically about FreeCOM, but I know in some versions of > DOS an environment variable can't contain an equals sign. For example, > in some DOS versions you can't do this while in others you can: > > SET ParameterList=Var1=1,Var2=2 > > This has caused me some grief in the past when I try to allow the user > to enter option parameters either from the command-line or from an > environment variable. For example, if the program I'm trying to run is > called PROGRAM I allow the user to set an environment variable named > PROGRAM that contains the "default" command-line parameters: > > SET PROGRAM=Option1=Yes, Option2=No > > I want that to work the same way as if the user had done this: > > PROGRAM Option1=Yes, Option2=No > > Sometimes it works and sometimes it doesn't, depending on which version > of DOS I am using. And I'm not even sure it is consistent across all > different DOS versions from the same manufacturer. BTW, the way I get > around this problem is to allow the user to either enter an equals (=) > or a colon (:) as the separator character and explain the situation in > the documentation.. > > The reason I bring this up is that in a recent post there was some > discussion over whether or not FreeDOS should fix all the bugs in > MS-DOS (essentially, improving MS-DOS) or duplicate the bugs, and the > consensus seemed to be to duplicate the bugs. I don't know if allowing > an equals sign in an environment variable would be considered a bug or > a feature, but I would classify it as a bug, and I don't remember > specifically how MS-DOS handles it. > > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Confusing details about SET and redirection in Free COM
> Hi fellow users :-) > > I have been wondering which chars are special in SET > in FreeCOM and whether they can be escaped or similar. I don't know specifically about FreeCOM, but I know in some versions of DOS an environment variable can't contain an equals sign. For example, in some DOS versions you can't do this while in others you can: SET ParameterList=Var1=1,Var2=2 This has caused me some grief in the past when I try to allow the user to enter option parameters either from the command-line or from an environment variable. For example, if the program I'm trying to run is called PROGRAM I allow the user to set an environment variable named PROGRAM that contains the "default" command-line parameters: SET PROGRAM=Option1=Yes, Option2=No I want that to work the same way as if the user had done this: PROGRAM Option1=Yes, Option2=No Sometimes it works and sometimes it doesn't, depending on which version of DOS I am using. And I'm not even sure it is consistent across all different DOS versions from the same manufacturer. BTW, the way I get around this problem is to allow the user to either enter an equals (=) or a colon (:) as the separator character and explain the situation in the documentation.. The reason I bring this up is that in a recent post there was some discussion over whether or not FreeDOS should fix all the bugs in MS-DOS (essentially, improving MS-DOS) or duplicate the bugs, and the consensus seemed to be to duplicate the bugs. I don't know if allowing an equals sign in an environment variable would be considered a bug or a feature, but I would classify it as a bug, and I don't remember specifically how MS-DOS handles it. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
