Re: [Freedos-user] FreeDOS/V
Hi, On Thu, 4 May 2023 at 20:38, Ralf Quint wrote: > > * Collating/lowercase/uppercase tables, which in turn implies that > > DBCS are handled where strings are handled, and my worry is about > > filenames: how are filenames stored? how does it relate to 8.3 > > limitation, does it become 4.1 or does it require LFN...? > For one, as DOS/V would specifically apply to Japanese (but the same > would apply at least to Hangul (Korean) and Chinese), none of the script > systems being used (Katagana, Hiragana, and certainly not Kanji (Chinese > "characters")) has the concept of upper case/lower case... > Yeah, I know :) I just mentioned for completion, and specially for the collating table. > Ok, here is were that soft brown matter hits the fast rotating household > appliance. I am pretty sure that in order to create a DBCS version of > MS/PC-DOS, they did not use one and the same code base. Some basic DOS > function would have to be completely replaced with DBCS aware versions, > I don't think you can simply maintain dual-capable versions without > significantly increased memory requirements. > Sure thing. Most worrying to me is to deal with DBCS strings where kernel deals with strings, that is specially on filenames. > And most importantly, I don't think that we at FreeDOS have simply the > capacity to do any such adaptation. It would require AT LEAST one person > that is fluent in English and Japanese, as well as being sufficiently > proficient in programming. I don't think there is even remotely anyone > that could possibly fill that role within the current participants, nor > even lurkers, or they would be more active (and possibly proposing > required changes). > Agreed. > This would not only apply to adaptations to the before mentioned East > Asian languages and scripting systems, but also to things like > right-to-left systems like Arabic and Hebrew > (Urdu/Farsi/Pashto/Punjabi/Sindhi/etc) > Yeah, that's another adventure that would involve heavier changes in the console at least. Aitor ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
On 5/3/2023 12:29 PM, Aitor Santamaría wrote: Hello! Although I am some years late, my thoughts on this thread. By the way, a very interesting thread on localisation for a hard case (the need for DBCS). Well,.. These thoughts are provided from the simple logic, not knowing about DOS/V. In my understanding, supporting Japanese would *at least* require the following functionalities, where the clue is given by NLSFUNC/COUNTRY: * Country settings (for date, currency, etc.), that should be easy. That indeed would be the easy part. But... * Collating/lowercase/uppercase tables, which in turn implies that DBCS are handled where strings are handled, and my worry is about filenames: how are filenames stored? how does it relate to 8.3 limitation, does it become 4.1 or does it require LFN...? For one, as DOS/V would specifically apply to Japanese (but the same would apply at least to Hangul (Korean) and Chinese), none of the script systems being used (Katagana, Hiragana, and certainly not Kanji (Chinese "characters")) has the concept of upper case/lower case... * All character devices that currently support IOCTL, should support this DBCS. As we have no PRINTER.SYS for PRN, we just need to focus on CON: - DISPLAY.SYS does not support DBCS, but I suppose that NNANSI that is being discussed here will do the work. However: - It would require KEYB to work with DBCS: this could work well: + if no codepage change is to be issued, DBCS can be outed as "strings" by keyb (with an appropriate KL file) + if codepage changes is to be issued (because NNANSI implements it), it should call KEYB * Finally, non-console UI utilities should be made to work with DBCS: this includes EDIT, INSTALL, ... Ok, here is were that soft brown matter hits the fast rotating household appliance. I am pretty sure that in order to create a DBCS version of MS/PC-DOS, they did not use one and the same code base. Some basic DOS function would have to be completely replaced with DBCS aware versions, I don't think you can simply maintain dual-capable versions without significantly increased memory requirements. And most importantly, I don't think that we at FreeDOS have simply the capacity to do any such adaptation. It would require AT LEAST one person that is fluent in English and Japanese, as well as being sufficiently proficient in programming. I don't think there is even remotely anyone that could possibly fill that role within the current participants, nor even lurkers, or they would be more active (and possibly proposing required changes). This would not only apply to adaptations to the before mentioned East Asian languages and scripting systems, but also to things like right-to-left systems like Arabic and Hebrew (Urdu/Farsi/Pashto/Punjabi/Sindhi/etc) Ralf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
Hello! Although I am some years late, my thoughts on this thread. By the way, a very interesting thread on localisation for a hard case (the need for DBCS). These thoughts are provided from the simple logic, not knowing about DOS/V. In my understanding, supporting Japanese would *at least* require the following functionalities, where the clue is given by NLSFUNC/COUNTRY: * Country settings (for date, currency, etc.), that should be easy. * Collating/lowercase/uppercase tables, which in turn implies that DBCS are handled where strings are handled, and my worry is about filenames: how are filenames stored? how does it relate to 8.3 limitation, does it become 4.1 or does it require LFN...? * All character devices that currently support IOCTL, should support this DBCS. As we have no PRINTER.SYS for PRN, we just need to focus on CON: - DISPLAY.SYS does not support DBCS, but I suppose that NNANSI that is being discussed here will do the work. However: - It would require KEYB to work with DBCS: this could work well: + if no codepage change is to be issued, DBCS can be outed as "strings" by keyb (with an appropriate KL file) + if codepage changes is to be issued (because NNANSI implements it), it should call KEYB * Finally, non-console UI utilities should be made to work with DBCS: this includes EDIT, INSTALL, ... All that I can come up with for adding NLS support to DOS (probably there are more that I am neglecting). Aitor On Wed, 8 Jul 2015 at 07:47, sparky4 wrote: > ah! i will fix that asap > > i just changed the configuration and compiled it > > thats all > > FreeDOS/V is to DOS/V > like what FreeDOS is to DOS > > > > -- > View this message in context: > http://freedos.10956.n7.nabble.com/FreeDOS-V-tp19922p23010.html > Sent from the FreeDOS - User mailing list archive at Nabble.com. > > > -- > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > ___ > 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] FreeDOS/V
On 7/7/2015 10:41 PM, Mateusz Viste wrote: Sorry if this is obvious -- what is FreeDOS/V ? cheers, Mateusz Well, as Sparky4 already mentioned, it is (supposed to be) for FreeDOS what DOS/V was for MS/PC-DOS: A double-byte aware Japanese localized version of FreeDOS... http://lmgtfy.com/?q=DOS%2FV Ralf --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
Hi, On Tue, Jul 7, 2015 at 3:44 PM, Jim Hall jh...@freedos.org wrote: I clicked Send before I meant to. The date (version 5/93) suggests this is GNU GPL v2. The GNU GPL v2 was released in 1991, and the GNU GPL v3 was released in 2007. Just FYI, I did mirror NNANSI to iBiblio recently. It is GPLv2, but it does maybe have some small (test?) auxiliary program or two that aren't. I didn't feel like mucking with the original .ZIP without good reason (plus was too busy with other concerns), but perhaps now would be a better time to take a closer look. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/nansi/nnansi/nnans593.zip For the record, this was also on Simtel back in the day (circa 1993, with old license): 67946 Jun 06 1993 /msdos/screen/nnans593.zip IIRC, this was originally heavily modified by Tom Almy but based upon Daniel Kegel's work. With upstream NANSI.SYS 3.4 in 1999, Kegel re-released his as GPL, and Almy followed suit with his fork soon after (2001). http://www.almy.us/dospage.html http://www.almy.us/files/nnans593.zip 18009 2001-10-28 13:36 GPL.TXT P.S. sparky, I would recommend against including a *.LST file in your .ZIP, it's just a waste of space. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
http://4ch.mooo.com/fdos/pack/jp.zip here i made a package I hope this is OK -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-V-tp19922p22999.html Sent from the FreeDOS - User mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
I did not expect this thread to take off ok i did find some utilities and their sources! i am very worried about licensing -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-V-tp19922p22998.html Sent from the FreeDOS - User mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
http://4ch.mooo.com/fdos/pack/nnansijp.zip http://4ch.mooo.com/fdos/pack/jp.zip here the 2 packages! if you find any bugs PLEASE let me know! -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-V-tp19922p23001.html Sent from the FreeDOS - User mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
Package nnansijp is missing its copy of the GNU GPL. From a comment at the top of NNANSI.ASM: ;--- nnansi.asm -- ; New, New ANSI terminal driver. ; Optimized for speed in the case of multi-character write requests. ; Original NANSI terminal driver (C) 1986 Daniel Kegel ;Bellevue, Washington Pasadena, California ; Modifications by Tom Almy without restrictions. ; May be distributed as specified in the GNU General Public License, ; which is supplied hera as file GPL.TXT I don't know if this is meant to be GNU GPL v2 or GNU GPL v3. The program output doesn't hint either: db 'By Tom Almy, version 5/93' db 13,10,10 db 'Based on NANSI.SYS V2.2' db 13,10 db 'Copyright 1986, Daniel Kegel.' db 13,10 db 'May be distributed per GNU General Public License' db 13,10 db '(see file GPL.TXT in distribution)' On Tue, Jul 7, 2015 at 2:16 PM, sparky4 spar...@cock.li wrote: http://4ch.mooo.com/fdos/pack/nnansijp.zip http://4ch.mooo.com/fdos/pack/jp.zip here the 2 packages! if you find any bugs PLEASE let me know! -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-V-tp19922p23001.html Sent from the FreeDOS - User mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
I removed it! thank you for telling me! I think i should build my own DOS/V system for FreeDOS! -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-V-tp19922p23004.html Sent from the FreeDOS - User mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
On Tue, Jul 7, 2015 at 11:37 AM, sparky4 spar...@cock.li wrote: http://4ch.mooo.com/fdos/pack/jp.zip here i made a package I hope this is OK Looks like jp.zip is not ok to redistribute. There is no license information to indicate if these programs can be shared. Just because it has source code does not mean it is free. The intent was probably that CHEJ was not free software. At the top of the chej/CHEJ.PAS file, the All right reserved comment suggests that Natrium meant this as non-free software: (** * * * CHEJ.EXE MultiMode CHEV * *(82BF82A582B682A5) ver 6.10 * * COPYRIGHTED (C) by Natrium, since 1992.7 * * All right reserved. * * * ** *) I do not know about dspvv/DSPVV.ASM, as it does not contain any statements to indicate its status. At best, this comment: ; DspVV V1.09 Display Driver for Vanilla VGAby Torry But without any indication that this is free software or may be otherwise shared, the assumption is that is not. I infer that fontn10/fontn.asm is meant as commercial software, and probably proprietary. The comment block at the top is unhelpful, but this output later in the code says it is from Nanshiki Corp.: fontx_name db 'FONTX2' title_msg db 'Font subsystem [',EXM,'] Ver ',VER,' Copyright 1996 (c) Nanshiki Corp.',CR,LF,'$' My advice is that you should not share the jp.zip package. This is non-free software. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
I clicked Send before I meant to. The date (version 5/93) suggests this is GNU GPL v2. The GNU GPL v2 was released in 1991, and the GNU GPL v3 was released in 2007. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
On Tue, Jul 7, 2015 at 3:53 PM, sparky4 spar...@cock.li wrote: my compiled nnansi version? From my other email, looks like nnansijp is missing its copy of the GNU GPL. This is free software, but it would be best to include the corresponding copy of the GNU GPL in your distribution of nnansijp. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
it is located in doc\nnansijp\ -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-V-tp19922p23008.html Sent from the FreeDOS - User mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
On 07/07/2015 22:53, sparky4 wrote: my compiled nnansi version? Looks good to me, although I find it lacks some clarity: if I understand well, you took the standard nnansi and recompiled it and/or added some #defines to include japanese support, is that right? If so, then I don't think you should be listed as the author in the LSM file, as it it would imply you created nnansi in the first place. recompilation with very slight patching fits as 'maintenance' (hence you should definitely appear as the maintainer, but not necessarily the author). Also, it would be good to have some text file in sources that describes what you did exactly to add Japanese support (even a patch file maybe? if necessary) Sorry if this is obvious -- what is FreeDOS/V ? cheers, Mateusz -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
ah! i will fix that asap i just changed the configuration and compiled it thats all FreeDOS/V is to DOS/V like what FreeDOS is to DOS -- View this message in context: http://freedos.10956.n7.nabble.com/FreeDOS-V-tp19922p23010.html Sent from the FreeDOS - User mailing list archive at Nabble.com. -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
On Sat, 09 Nov 2013 04:02:58 +0100, Eric Auer e.a...@jpberlin.de wrote: If that just returns a charset-specific static table, maybe it would be some sort of charset rendering and keyboard / input method driver that actually implements this, not the kernel? Sure, it could also be a TSR. I forgot how flexible DOS is in API extensibility. :) And importantly, note how much of DOS (and tools) do NOT have to know about the DBCS nature of text: It makes no difference for FIND if you search for a four letter word or for four bytes which MEAN two DBCS characters. Among other things, this is thanks to having a lead byte / next byte distinction and having no upper or lower case in CJK languages if I remember correctly. Actually, it makes a big difference for FIND, which why I mentioned it. While leading bytes of double byte characters all have the highest bit set, the following bytes do not. So searching for the ASCII character i would give you incorrect results, as 69h is a perfectly valid second byte of a double byte character, for example of ナ, katakana syllable na (8369h). Additionally, case insensitive searching works by comparing pairs of characters converted to the same case, so searching for i would not only find lines containing ナ, but also オ, katakana syllable o (8349h), and other characters. For the same reason, FreeCOM does not have to care. Well, it does for sorting filenames in the DIR command. :) SORT is a different story, but I do not know whether DOS is supposed to include Japanese etc aware SORT or whether that is normally part of a separately available package of JKC tools. Also, what license do such packages have? I don't know. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
On Sat, 09 Nov 2013 06:36:49 +0100, Rugxulo rugx...@gmail.com wrote: On Fri, Nov 8, 2013 at 8:02 PM, Matej Horvat matej.hor...@guest.arnes.si wrote: PS: I just wrote all that and found this: http://nokonoko365.cocolog-nifty.com/blogfile/freedos/index.html Is that third party software for Japanese support or what? No, according to Chrome's translation, it seems to just be somebody trying FreeDOS + Windows 3.1 under VirtualPC, nothing more. No, I meant this post: http://nokonoko365.cocolog-nifty.com/blogfile/2011/01/freedos-a3f2.html Look at the screenshots. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
Hi, On Sat, Nov 9, 2013 at 5:13 AM, Matej Horvat matej.hor...@guest.arnes.si wrote: On Sat, 09 Nov 2013 06:36:49 +0100, Rugxulo rugx...@gmail.com wrote: On Fri, Nov 8, 2013 at 8:02 PM, Matej Horvat matej.hor...@guest.arnes.si wrote: PS: I just wrote all that and found this: http://nokonoko365.cocolog-nifty.com/blogfile/freedos/index.html Is that third party software for Japanese support or what? No, according to Chrome's translation, it seems to just be somebody trying FreeDOS + Windows 3.1 under VirtualPC, nothing more. No, I meant this post: http://nokonoko365.cocolog-nifty.com/blogfile/2011/01/freedos-a3f2.html Look at the screenshots. The original website seems to have disappeared. I did check Wayback, and the Win32 .ZIP sfx (PE .EXE) downloads okay. It contains an .IMA (floppy image) file with various tools, but I'm unsure of the licenses, and I don't see any sources. So I'm not sure how useful it is (by default) right now. I'm moreso thinking of keyboard and fonts vs. just localized older versions of Edlin or FreeCOM or whatever. Well, I didn't check too close, it's hard enough relying on Chrome to translate! -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
On Sat, 09 Nov 2013 00:36:49 -0500, Rugxulo rugx...@gmail.com wrote: Hi, On Fri, Nov 8, 2013 at 8:02 PM, Matej Horvat matej.hor...@guest.arnes.si wrote: ... irrelevant comments by me deleted ... PS: I just wrote all that and found this: http://nokonoko365.cocolog-nifty.com/blogfile/freedos/index.html Is that third party software for Japanese support or what? No, according to Chrome's translation, it seems to just be somebody trying FreeDOS + Windows 3.1 under VirtualPC, nothing more. The top of the blog page is indeed about running jp win3.1. Below that it talks about adding Japanese support to FD. The link is broken but a google search turns up working links for fdos0138.exe or fdos0138.lzh. With the drivers being loaded in fdconfig.sys it becomes possible to switch between standard character-mapped text mode (needed for running FD EDIT, etc.) and the VGA mode for running Japanese DOS programs. The readme file with the disk image seems to say that the license is GPL or freeware (I am not good enough to parse Japanese legalese), and includes an email address for the author minashir...@yahoo.co.jp -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
Hi, On Sat, Nov 9, 2013 at 1:43 PM, TJ Edmister damag...@hyakushiki.net wrote: On Sat, 09 Nov 2013 00:36:49 -0500, Rugxulo rugx...@gmail.com wrote: On Fri, Nov 8, 2013 at 8:02 PM, Matej Horvat matej.hor...@guest.arnes.si wrote: PS: I just wrote all that and found this: http://nokonoko365.cocolog-nifty.com/blogfile/freedos/index.html Is that third party software for Japanese support or what? No, according to Chrome's translation, it seems to just be somebody trying FreeDOS + Windows 3.1 under VirtualPC, nothing more. The top of the blog page is indeed about running jp win3.1. Below that it talks about adding Japanese support to FD. The link is broken but a google search turns up working links for fdos0138.exe or fdos0138.lzh. http://web.archive.org/web/20100520230541/http://homepage1.nifty.com/bible/fdos/freedosvd.html The two main files seem to be (as mentioned) fdos0138.exe (.ZIP sfx of .IMA) and jis4pack.lzh (three .fnt files, the first of which is huge, presumably only useful with something on the .IMA, perhaps FONTNX.EXE ??). With the drivers being loaded in fdconfig.sys it becomes possible to switch between standard character-mapped text mode (needed for running FD EDIT, etc.) and the VGA mode for running Japanese DOS programs. I still don't understand which encoding, which scripts, etc. are supported here. Plus, it's not obvious (to me) which third-party programs are supported or whether such support has to be built into each by default. The readme file with the disk image seems to say that the license is GPL or freeware (I am not good enough to parse Japanese legalese), and includes an email address for the author minashir...@yahoo.co.jp I don't see any sources, but I know that FreeDOS heavily frowns on anything that isn't free/libre (four freedoms). In other words, I don't think freeware, no matter how useful, is good enough to mirror. Presumably the mention here of GPL only refers to FreeDOS proper stuff (kernel, shell), not the others. I really am too pessimistic to email the author. If you or someone else isn't willing, I could try, but I really doubt it would help any of us here very much. And of course I don't speak Japanese, so -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
On Sat, 09 Nov 2013 18:22:40 -0500, Rugxulo rugx...@gmail.com wrote: The two main files seem to be (as mentioned) fdos0138.exe (.ZIP sfx of .IMA) and jis4pack.lzh (three .fnt files, the first of which is huge, presumably only useful with something on the .IMA, perhaps FONTNX.EXE ??). Yes, and they are both downloadable here http://dos.minashiro.net/freedosvd.html I still don't understand which encoding, which scripts, etc. are supported here. Plus, it's not obvious (to me) which third-party programs are supported or whether such support has to be built into each by default. I believe the encoding used is Shift-JIS. Instead of the usual character-mapped text mode, the display is switched to a bitmapped mode, the fonts are loaded into memory, and the driver intercepts calls to write text to the screen and handles drawing the characters itself. 7-bit ASCII can be written as normal (half-width characters), but bytes in the 128-255 range can be combined with the following byte to form a longer character code. These can represent any of the kana/kanji/etc. and while they are two bytes long they are also physically twice as wide on the screen (full-width characters). Once the drivers are installed then for instance, one could use the TYPE command to display the included readme file and the Japanese characters would then be displayed properly. Whereas in a normal FreeDOS install, trying to view the file would result in mojibake (nonsense strings). I imagine this would allow running any other legacy DOS programs which were designed to use Shift-JIS. But then, I've never used DOS/V, or any Japanese DOS programs other than the command-line utilities that are included with Japanese Windows XP, so I'm not entirely sure. I also don't know how kanji input (if any) works. I don't see any sources, but I know that FreeDOS heavily frowns on anything that isn't free/libre (four freedoms). In other words, I don't think freeware, no matter how useful, is good enough to mirror. Presumably the mention here of GPL only refers to FreeDOS proper stuff (kernel, shell), not the others. I really am too pessimistic to email the author. If you or someone else isn't willing, I could try, but I really doubt it would help any of us here very much. And of course I don't speak Japanese, so I don't know if it is a good candidate for a mirror, but at least anyone who wants Japanese support in FreeDOS can try it out. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
Hi, On Fri, Nov 8, 2013 at 12:46 AM, sparky4 insano sparky44...@gmail.com wrote: Will there ever be any official support for the Japanese language in FreeDOS? At risk of stating the obvious, FreeDOS is free to modify, but support can only improve if someone decides to volunteer to do it. Presumably that would have to be a semi-fluent Japanese speaker with either a software background or else heavy sympathy for DOS. Until (or if ever) that happens, you're stuck with making do with what already exists (or doing without, I guess). I don't personally know enough (and literally nothing about .jp) to volunteer much for that, so all I can do is search around. While not all Americans are monolingual, the majority (like me) seem to be, due to lacking any direct reason to be otherwise. Nevertheless, I do have some (very small) curiosity and interest in other languages, so it's not like I'm totally content to say or do nothing. So you want to edit Japanese text? Dunno, can't try myself, but can you try one of the following DOS software and report back? GNU Emacs (23.3) or Mined (2013.23) or Blocek (1.4) http://na.mirror.garr.it/mirrors/djgpp/current/v2gnu/em2303b.zip http://www.towo.net/mined/ http://laaca.sweb.cz/ The first two are text mode only but have their own input methods for other languages. This means you can edit anything, but it won't directly represent 1:1 on the screen what you're reading or typing. Blocek is graphical for UTF-8 and requires a mouse (but I think it relies on KEYB supporting your language input), but I dunno how full the fonts are for your needs. Text mode is usually limited in hardware to 256 glyphs (although 512 is allegedly possible, but I don't know of any specific programs using it). A quick search implies that FreeDOS doesn't support DBCS (which other DOSes do??). Dunno what that even means in concrete terms. http://en.wikipedia.org/wiki/DBCS I'm assuming you know more about the Japanese language than I do! :-) A quick search on Wikipedia shows three major writing styles (kanji, hiragana, katakana), not counting romaji (romanization of Japanese). http://en.wikipedia.org/wiki/Romaji FD KEYB does support Japanese, apparently, in KEYBOARD.SYS (see KPDOS31S.ZIP's jp106.txt and jp.key), but it's for cp932, which AFAIK doesn't exist for FreeDOS proper. Though DOSLFN also has a cp932uni.tbl translation file. http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT But even the relevant 8-bit (256) chars mentioned there only seem to be the standard 7-bit ASCII and only some upper 8-bit chars from katakana, which sounds somewhat limiting: http://en.wikipedia.org/wiki/Katakana In contrast to the hiragana syllabary, which is used for those Japanese language words and grammatical inflections which kanji does not cover, the katakana syllabary is primarily used for transcription of foreign language words into Japanese and the writing of loan words (collectively gairaigo). It is also used for emphasis, to represent onomatopoeia, and to write certain Japanese language words, such as technical and scientific terms, and the names of plants, animals, and minerals. Names of Japanese companies are also often written in katakana rather than the other systems. Apparently there are various Romaji methods, and one in particular seems to be Kunrei-shiki, standardized in ISO 3602, although Wikipedia seems to imply that modified Hepburn is used more frequently. All Japanese who have attended elementary school since World War II have been taught to read and write romanized Japanese. Therefore, almost all Japanese are able to read and write Japanese using rōmaji, although it is extremely rare in Japan to use this method to write Japanese, and most Japanese are more comfortable reading kanji/kana. So a copout (from a FreeDOS perspective) would be to say, Just use romaji. But from what I can tell, the kana (hiragana, katakana) comprise 48 characters each (total 96). However, Kanji is much larger and our biggest obstacle. Even Joyo kanji is 2136 kanji: 1006 taught in primary school, 1130 taught in secondary school. http://en.wikipedia.org/wiki/Kana http://en.wikipedia.org/wiki/J%C5%8Dy%C5%8D_kanji Even if we were to restrict to that (2136 + 96), that would be a mouthful. But I guess it depends how low (or high) you want to go with support. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
Would this accomplished by loading a Unicode Japanese code page font file using mode? On Nov 8, 2013 3:59 PM, Rugxulo rugx...@gmail.com wrote: Hi, On Fri, Nov 8, 2013 at 12:46 AM, sparky4 insano sparky44...@gmail.com wrote: Will there ever be any official support for the Japanese language in FreeDOS? At risk of stating the obvious, FreeDOS is free to modify, but support can only improve if someone decides to volunteer to do it. Presumably that would have to be a semi-fluent Japanese speaker with either a software background or else heavy sympathy for DOS. Until (or if ever) that happens, you're stuck with making do with what already exists (or doing without, I guess). I don't personally know enough (and literally nothing about .jp) to volunteer much for that, so all I can do is search around. While not all Americans are monolingual, the majority (like me) seem to be, due to lacking any direct reason to be otherwise. Nevertheless, I do have some (very small) curiosity and interest in other languages, so it's not like I'm totally content to say or do nothing. So you want to edit Japanese text? Dunno, can't try myself, but can you try one of the following DOS software and report back? GNU Emacs (23.3) or Mined (2013.23) or Blocek (1.4) http://na.mirror.garr.it/mirrors/djgpp/current/v2gnu/em2303b.zip http://www.towo.net/mined/ http://laaca.sweb.cz/ The first two are text mode only but have their own input methods for other languages. This means you can edit anything, but it won't directly represent 1:1 on the screen what you're reading or typing. Blocek is graphical for UTF-8 and requires a mouse (but I think it relies on KEYB supporting your language input), but I dunno how full the fonts are for your needs. Text mode is usually limited in hardware to 256 glyphs (although 512 is allegedly possible, but I don't know of any specific programs using it). A quick search implies that FreeDOS doesn't support DBCS (which other DOSes do??). Dunno what that even means in concrete terms. http://en.wikipedia.org/wiki/DBCS I'm assuming you know more about the Japanese language than I do! :-) A quick search on Wikipedia shows three major writing styles (kanji, hiragana, katakana), not counting romaji (romanization of Japanese). http://en.wikipedia.org/wiki/Romaji FD KEYB does support Japanese, apparently, in KEYBOARD.SYS (see KPDOS31S.ZIP's jp106.txt and jp.key), but it's for cp932, which AFAIK doesn't exist for FreeDOS proper. Though DOSLFN also has a cp932uni.tbl translation file. http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT But even the relevant 8-bit (256) chars mentioned there only seem to be the standard 7-bit ASCII and only some upper 8-bit chars from katakana, which sounds somewhat limiting: http://en.wikipedia.org/wiki/Katakana In contrast to the hiragana syllabary, which is used for those Japanese language words and grammatical inflections which kanji does not cover, the katakana syllabary is primarily used for transcription of foreign language words into Japanese and the writing of loan words (collectively gairaigo). It is also used for emphasis, to represent onomatopoeia, and to write certain Japanese language words, such as technical and scientific terms, and the names of plants, animals, and minerals. Names of Japanese companies are also often written in katakana rather than the other systems. Apparently there are various Romaji methods, and one in particular seems to be Kunrei-shiki, standardized in ISO 3602, although Wikipedia seems to imply that modified Hepburn is used more frequently. All Japanese who have attended elementary school since World War II have been taught to read and write romanized Japanese. Therefore, almost all Japanese are able to read and write Japanese using rōmaji, although it is extremely rare in Japan to use this method to write Japanese, and most Japanese are more comfortable reading kanji/kana. So a copout (from a FreeDOS perspective) would be to say, Just use romaji. But from what I can tell, the kana (hiragana, katakana) comprise 48 characters each (total 96). However, Kanji is much larger and our biggest obstacle. Even Joyo kanji is 2136 kanji: 1006 taught in primary school, 1130 taught in secondary school. http://en.wikipedia.org/wiki/Kana http://en.wikipedia.org/wiki/J%C5%8Dy%C5%8D_kanji Even if we were to restrict to that (2136 + 96), that would be a mouthful. But I guess it depends how low (or high) you want to go with support. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register
Re: [Freedos-user] FreeDOS/V
Hi, On Fri, Nov 8, 2013 at 6:02 PM, Chris Evans aaxiomfin...@gmail.com wrote: Would this accomplished by loading a Unicode Japanese code page font file using mode? No because Unicode, esp. for CJK languages, would never fit into 256 or 512 bytes, which (AFAIK) is a EGA/VGA hardware (text mode) limitation. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
On 11/8/2013 4:43 PM, Rugxulo wrote: Hi, On Fri, Nov 8, 2013 at 6:02 PM, Chris Evans aaxiomfin...@gmail.com wrote: Would this accomplished by loading a Unicode Japanese code page font file using mode? No because Unicode, esp. for CJK languages, would never fit into 256 or 512 bytes, which (AFAIK) is a EGA/VGA hardware (text mode) limitation. DOS/V used Kanji with a VGA (which was a requirement, that's what the /V actually stands for). But it requires more than just displaying Japanese characters, you need to be able to enter them and properly handle them in filenames etc as well. Not going to happen unless some native Japanese speaker with some fundamental DOS programming background is active participating in creating such a version. After all it has originally been a separate version of (PC-)DOS, not just a localized version. So the answer to the OP is pretty: It will never happen... Ralf --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
I downloaded a Japanese MS-DOS bootdisk (I'm not giving out any links
because this is probably not very legal) and started experimenting. Let me
report my findings.
It seems that there is just one special API function for double byte
character sets, 6300h:
http://www.ctyme.com/intr/rb-3142.htm
http://www.ctyme.com/intr/rb-3143.htm
It returns a table of ranges of valid DBCS leading bytes. This allows
applications to detect that it is reading DBCS characters as opposed to
ASCII or JIS X 0201 (an 8-bit encoding with ASCII in the lower half and
katakana in the upper half).
An application then simply uses standard DOS functions for everything, for
example INT 21h/AH=1 for input and INT 21h/AH=2 for output. DOS of course
does not supply any special string functions, so it is up to the
application to do any string processing. Open Watcom, for example, has a
header file called jstring.h which includes Japanese equivalents of
string.h and other functions, for example jishira, which checks whether a
character is a hiragana character.
I wrote a simple program that reads standard input and returns katakana
characters from it:
#include jstring.h
#include stdio.h
int main ()
{
JCHAR Buffer[1024]; // JCHAR is same as char (semantic difference)
JSTRING BufferAsStr; // JSTRING is same as JCHAR*
int Ch; // Result from getchar
unsigned int i;
JMOJI Moji; // 16-bit Japanese (or any DBCS) character
// Read from standard input into buffer.
// This part would be the same for a non-DBCS program.
i = 0;
for(;;)
{
Ch = getchar();
if(Ch == EOF)
break;
Buffer[i++] = Ch;
if(i == sizeof(Buffer) - 1)
break;
}
Buffer[i] = '\0';
// Now go through the string and output only katakana characters.
BufferAsStr = Buffer;
i = 0;
for(;;)
{
// jgetmoji takes a pointer into a string and returns the character
// at that position as a JMOJI, and a pointer to the next character.
BufferAsStr = jgetmoji(BufferAsStr, Moji);
if(*BufferAsStr == '\0')
break;
if(jiskana(Moji)) // If it's a katakana character, output it.
{
putchar(Moji 8); // Couldn't find a nicer way, but it works.
putchar(Moji 0xFF);
}
}
return 0;
}
I executed
DIR /? | name of program
and got back ディレクトリサブディレクトリファイルドライブ and so on.
So, what needs to be done?
1. INT 21h/AX=6300h has to be implemented.
2. INT 21h/AH=1 (and all other input functions) has to be modified so that
if a double byte character is entered, it returns the first byte and
remembers the second byte to return it in the next call.
3. INT 21h/AH=2 (and all other output functions) has to be modified so
that if it detects a leading byte of a double byte character, it has to
remember it and wait until the next call, when it gets the second byte, to
print the character.
4. A keyboard layout has to be made. I have no idea how keyboard layouts
work in DOS, so I can't say much.
5. A font has to be made. Perhaps the GNU Unifont could be converted?
6. Probably the hardest part: all FreeDOS packages, or at least basic ones
(FreeCOM, FIND, SORT, EDIT), have to be updated to support double byte
characters.
Adding support for Japanese (and Korean and Chinese, because the mechanism
is the same) would probably not be that difficult, but it would take a
long time to modify everything to support it.
Matej Horvat
http://matejhorvat.si/
PS: I just wrote all that and found this:
http://nokonoko365.cocolog-nifty.com/blogfile/freedos/index.html
Is that third party software for Japanese support or what?
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V - dbcs support for japanese chinese korean
Hi Matej, thanks for your research :-) It seems that there is just one special API function for double byte character sets, 6300h: http://www.ctyme.com/intr/rb-3142.htm http://www.ctyme.com/intr/rb-3143.htm It returns a table of ranges of valid DBCS leading bytes. This allows applications to detect that it is reading DBCS characters as opposed to ASCII or JIS X 0201 (an 8-bit encoding with ASCII in the lower half and katakana in the upper half). An application then simply uses standard DOS functions for everything, for example INT 21h/AH=1 for input and INT 21h/AH=2 for output. DOS of course does not supply any special string functions, so it is up to the app... ... thanks for the example code ... So, what needs to be done? 1. INT 21h/AX=6300h has to be implemented. If that just returns a charset-specific static table, maybe it would be some sort of charset rendering and keyboard / input method driver that actually implements this, not the kernel? 2. INT 21h/AH=1 (and all other input functions) has to be modified so that if a double byte character is entered, it returns the first byte and remembers the second byte to return it in the next call. I could imagine that this can also be done in the keyboard driver, similar to what the BIOS does with function keys which also have no ASCII equivalent and still use the BIOS keyboard buffer I/O like everything else... 3. INT 21h/AH=2 (and all other output functions) has to be modified so that if it detects a leading byte of a double byte character, it has to remember it and wait until the next call, when it gets the second byte, to print the character. Well, DOS itself cannot print in charsets beyond 1-byte-per- char, because it uses the BIOS functions which in turn use the VGA hardware which cannot have more than 2 x 256 chars sized fonts. So this again sounds like a job for a DRIVER, one which uses graphics mode to render extensive fonts. We already have support for Unicode fonts in a few graphical DOS text editors and similar (thanks :-)) and whether DBCS or UTF-8 is used, both share the size of character can be one or more bytes handling anomaly. I see your point in avoiding to print half double bytes, but because the graphical output is done externally to the kernel anyway, the disadvantages of DBCS-agnosticism for int 21 function 2 and similar seem limited: The graphical font driver would just remember having seen half of a DBCS itself and draw the actual character as soon as it receives the second byte of that. 4. A keyboard layout has to be made. I have no idea how keyboard layouts work in DOS, so I can't say much. Well layouts are one thing, but for beyond-alphabetic DBCS input, you probably need an input method driver, which is separate from the layout for ASCII. Normally that works by typing short ASCII sequences, typically in a special shift state, to select a Chinese / Japanese / Korean character. I assume that such drivers are separately available, also in free versions, working with any DBCS-enabled DOS system. Imagine that for example you type Strg-K-A-N-X and when you release the Strg again, the input method sends two bytes, in other words one DBCS, through the DOS console driver, saying somebody has typed the character named Kanji-Xen (I invented that character). So there is not one KEY that lets you type one Xen character, but a WAY to type one. 5. A font has to be made. Perhaps the GNU Unifont could be converted? The abovementioned editors use TrueType Fonts (TTF) as far as I remember, but in a fixed size way, I believe. So that conversion step is something people have experience with :) 6. Probably the hardest part: all FreeDOS packages, or at least basic ones (FreeCOM, FIND, SORT, EDIT), have to be updated to support double byte characters. See above for editing. And importantly, note how much of DOS (and tools) do NOT have to know about the DBCS nature of text: It makes no difference for FIND if you search for a four letter word or for four bytes which MEAN two DBCS characters. Among other things, this is thanks to having a lead byte / next byte distinction and having no upper or lower case in CJK languages if I remember correctly. For the same reason, FreeCOM does not have to care. File names cannot be more than 8 + 3 BYTES long, but if those 8 bytes happen to have 4 DBCS chars as content, it is the same to FreeCOM. Only the display driver has to graphically draw the 4 DBCS chars for you instead of 8 ASCII ones then. Again, the lead byte trick allows the driver to recognize whether an incoming byte is ASCII or part of a DBCS. Note that the 2nd half of a DBCS cannot be distinguished from ASCII if I guess correctly, so the graphical font display driver has to remember whether the previous char was a non printing DBCS lead byte (and which) or not, that's enough. SORT is a different story, but I do not know whether DOS is supposed to include Japanese etc aware SORT
Re: [Freedos-user] FreeDOS/V
Hi, On Fri, Nov 8, 2013 at 8:02 PM, Matej Horvat matej.hor...@guest.arnes.si wrote: ... irrelevant comments by me deleted ... PS: I just wrote all that and found this: http://nokonoko365.cocolog-nifty.com/blogfile/freedos/index.html Is that third party software for Japanese support or what? No, according to Chrome's translation, it seems to just be somebody trying FreeDOS + Windows 3.1 under VirtualPC, nothing more. I almost wouldn't even know where to search for such tools, honestly. But a quick check at one old (broken?) Simtel mirror showed some useful stuff, e.g. EDICT, which led me to the second link (below), which sounds more promising, if only slightly: http://www.lanet.lv/simtel.net/msdos/editor-pre.html ftp://ftp.monash.edu.au/pub/nihongo/00INDEX.html#ms_dos_r -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS/V
The full simtel mirror is at archive.org (all 10GB in a zip file) https://archive.org/details/simtelnet_bu_mirror_2013_04 -L On Fri, Nov 8, 2013 at 9:36 PM, Rugxulo rugx...@gmail.com wrote: Hi, On Fri, Nov 8, 2013 at 8:02 PM, Matej Horvat matej.hor...@guest.arnes.si wrote: ... irrelevant comments by me deleted ... PS: I just wrote all that and found this: http://nokonoko365.cocolog-nifty.com/blogfile/freedos/index.html Is that third party software for Japanese support or what? No, according to Chrome's translation, it seems to just be somebody trying FreeDOS + Windows 3.1 under VirtualPC, nothing more. I almost wouldn't even know where to search for such tools, honestly. But a quick check at one old (broken?) Simtel mirror showed some useful stuff, e.g. EDICT, which led me to the second link (below), which sounds more promising, if only slightly: http://www.lanet.lv/simtel.net/msdos/editor-pre.html ftp://ftp.monash.edu.au/pub/nihongo/00INDEX.html#ms_dos_r -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
