[Freedos-devel] confused by NLS-settings
Dear developer list, could anyone please help me out with a config.sys/autoexec.bat implementation of NLS-specific settings? I'm horribly confused by how startup files should look, as to my knowledge we've got the following: * COUNTRY in config.sys (harddisk installation) versus no such setting (bootdisks, as the file takes up too much space) * stable kernels (no COUNTRY support) versus unstable kernels (experimental COUNTRY support) * official MSDOS way of codepage setting versus FreeDOS adhoc settings (NLSFUNC related?) This involves the following: * COUNTRY= (config.sys, COUNTRY.SYS / COUNTRY2.SYS / COUNTRY3.SYS) * DISPLAY (a TSR by Aitor, versus device driver in MSDOS) * NLSFUNC (with optional COUNTRY support, but only if not listed in config.sys yet?) * MODE versus MODECON versus different configurations whether or not COUNTRY= is set? * CHCP (internal command to FreeCOM) * KEYB (and CPI/CPX files) I'd like to add above in a working configuration for a FreeDOS 1.1 (work-in-progress) including kernel 2040 (stable, with support for nlsfunc/country) but so many settings to consider it's hurting my head. Along with that there's ofcourse a few more annoying issues: * DEVLOAD /H (devload 3.21) bails out entirely of loading a device driver in no-UMB environments. I dislike having to make 2 or more entries for simply loading a CD driver. Non-optimal result thus for options 1 and 2 * EDIT 0.9a prints its version and DFLAT banner at every invocation. * FreeCOM unfortunately allows environment variables to end with empty spaces instead of stripping them. * I'm not sure which version of SHARE to include, there's quite a few of them floating around the internet Bernd (FD)CONFIG.SYS so far: !COUNTRY=001,437,C:\FDOS\BIN\COUNTRY.SYS !SET DOSDIR=C:\FDOS !LASTDRIVE=Z !BUFFERS=20 !FILES=40 !MENUCOLOR=7,0 MENUDEFAULT=1,5 MENU 1 - Load FreeDOS with JEMMEX, no EMS (most UMBs), max RAM free MENU 2 - Load FreeDOS with EMM386+EMS and SHARE MENU 3 - Load FreeDOS including HIMEM XMS-memory driver MENU 4 - Load FreeDOS without drivers 123?DOS=HIGH 12?DOS=UMB 12?DOSDATA=UMB 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST 2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE 2?DEVICE=C:\FDOS\BIN\JEMM386.EXE X=TEST I=B000-B7FF 3?DEVICE=C:\FDOS\BIN\XMGR.SYS 3?SHELL=C:\FDOS\BIN\4DOS.COM C:\FDOS\BIN /E:1024 /P:C:\AUTOEXEC.BAT 4?SHELL=C:\FDOS\BIN\COMMAND.COM C:\FDOS\BIN /E:1024 /P=C:\AUTOEXEC.BAT 12?SHELLHIGH=C:\FDOS\BIN\COMMAND.COM C:\FDOS\BIN /E:1024 /P=C:\AUTOEXEC.BAT Autoexec.bat so far: @echo off SET LANG=EN SET PATH=%dosdir%\BIN SET NLSPATH=%dosdir%\NLS SET HELPPATH=%dosdir%\HELP SET TEMP=%dosdir%\TEMP SET TMP=%dosdir%\TEMP SET WATTCP.CFG=%dosdir% SET MTCPCFG=%dosdir%\MTCP.CFG SET BLASTER=A220 I5 D1 H5 P330 SET DIRCMD=/P /OGN /4 if "%config%"=="4" goto end DOSLFN SHSUCDX /QQ /D3 IF EXIST FDBOOTCD.ISO LH SHSUCDHD /Q /F:FDBOOTCD.ISO LH FDAPM APMDOS if "%config%"=="2" LH SHARE MOUSE DEVLOAD /Q %dosdir%\BIN\UIDE.SYS /D:FDCD0001 /S5 ShsuCDX /QQ /~ /D:?SHSU-CDH /D:?FDCD0001 /D:?FDCD0002 /D:?FDCD0003 goto end :end MEM /C /N if not "%config%"=="" SHSUCDX /D SET CFGFILE=C:\FDCONFIG.SYS SET AUTOFILE=%0 alias reboot=fdapm warmboot alias halt=fdapm poweroff echo Done processing startup files %cfgfile% and %0 echo Type HELP to get support on commands and navigation echo. echo Welcome to the FreeDOS 1.1 operating system (http://www.freedos.org) -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi, quick reply from memory, others can answer too of course, On Thu, Jun 30, 2011 at 2:01 AM, Bernd Blaauw wrote: > Dear developer list, > > could anyone please help me out with a config.sys/autoexec.bat > implementation of NLS-specific settings? > I'm horribly confused by how startup files should look, as to my > knowledge we've got the following: > * COUNTRY in config.sys (harddisk installation) versus no such setting > (bootdisks, as the file takes up too much space) COUNTRY.SYS isn't needed for DISPLAY-only stuff, e.g. codepages on screen, nor for KEYB either. It's only other stuff (collate tables, y/n), I think. > * stable kernels (no COUNTRY support) versus unstable kernels > (experimental COUNTRY support) 2037, 2039 are the only ones supported (not counting 2040, which is "unreleased"). > * official MSDOS way of codepage setting versus FreeDOS adhoc settings > (NLSFUNC related?) It's all ad hoc! MS-DOS was far from perfect either. And, well, let's just say that MS-DOS is more limited than FreeDOS (esp. re: codepages, thanks to Henrique). > This involves the following: > * COUNTRY= (config.sys, COUNTRY.SYS / COUNTRY2.SYS / COUNTRY3.SYS) Eh? I'm only actively aware of COUNTRY.SYS, not any others. Ask Eduardo Casino (I think) for more info. > * DISPLAY (a TSR by Aitor, versus device driver in MSDOS) The only difference here is it lacks certain int 21h calls, no huge problem. Also, FreeDOS may not (much, if at all) support PRINTER.SYS. Otherwise, it shouldn't matter (much). > * NLSFUNC (with optional COUNTRY support, but only if not listed in > config.sys yet?) I don't think CONFIG.SYS' "COUNTRY=" affects NLSFUNC. You still need to run NLSFUNC at runtime (I think) to activate the collate tables, y/n, currency, time, etc. > * MODE versus MODECON versus different configurations whether or not > COUNTRY= is set? Isn't MODECON deprecated / unnecessary?? > * CHCP (internal command to FreeCOM) This was supposed to (I think) unify all the various subsystems (PRINTER, DISPLAY, KEYB) into one overall "system" codepage. Some of these subsystems (e.g. KEYB) try to align with DISPLAY and can stop you independently changing the codepage if no layout is supported (for example). My personal example (Esperanto), for my amusement only, it only works with DISPLAY and KEYB (for which I'm grateful!), not CHCP nor COUNTRY.SYS (lacking explicit E-o support, natch, which I don't really need anyways). > * KEYB (and CPI/CPX files) KEYB uses KEYBOARD, KEYBRD2, KEYBRD3.SYS (library) files. CPX is just a (UPX-)compressed CPI file. > I'd like to add above in a working configuration for a FreeDOS 1.1 > (work-in-progress) including kernel 2040 (stable, with support for > nlsfunc/country) but so many settings to consider it's hurting my head. Well, what explicit languages are you trying to support? Honestly, if you don't care about "full" NLS, you don't need everything and the kitchen sink. Latin-1 (850 or 819) is pretty much all you need for the common folk. (I'm not trying to marginalize anyone, just saying it's easier to support a subset.) Really, just including EGA.CPX alone (and without *.CPX) is probably sufficient for basic needs. > Along with that there's ofcourse a few more annoying issues: > * DEVLOAD /H (devload 3.21) bails out entirely of loading a device > driver in no-UMB environments. I dislike having to make 2 or more > entries for simply loading a CD driver. Non-optimal result thus for > options 1 and 2 Kinda a hack, ain't it? Just don't use DEVLOAD at all unless really required. (That may not be what you want to hear, though.) It's not meant to be used in 100% of cases, IMHO. > * EDIT 0.9a prints its version and DFLAT banner at every invocation. Recompile? :-) Or just include a different editor (I'd cram TDE, if possible, or EZEDIT if not). > * FreeCOM unfortunately allows environment variables to end with empty > spaces instead of stripping them. You mean the name or contents? "set BLAH=name " TDE can (optionally) trim trailing spaces upon save, if that bothers your .BATs. ;-) Or just use:sed -e "s/ *$//" myfile.bat > myfile.new > * I'm not sure which version of SHARE to include, there's quite a few of > them floating around the internet It's supposedly mostly non-functional anyways, doesn't fully support MS SHARE. I think Japheth had a hacked one for some old Win 3.x Office tools (Word, etc). Other than that, I don't know of any huge reason for it (and never use it personally). (more inline comments below) > (FD)CONFIG.SYS so far: > !COUNTRY=001,437,C:\FDOS\BIN\COUNTRY.SYS I don't think you need to specify this COUNTRY line at all for 437 (U.S.). > !LASTDRIVE=Z Too many unless you're really using them all (or relying on hardcoded drive values). I'd suggest "P" as a compromise. > !BUFFERS=20 Too many and unnecessary ... but only if using UIDE. Otherwise fine. > !FILES=40 Is that enough? Should be for most stuff, but 80 would be safer (in theory). > 1?DEVICE=C:\FD
Re: [Freedos-devel] confused by NLS-settings
I will try to respond better when I'm home. Kernel 2040 is released but not yet announced. Use share & country that is with kernel. I believe I checked all versions floating around a year or so ago & have latest share with kernel (I need to verify both SVN versions). I don't know much about using NLS support as I always used default codepages. Jeremy -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Op 29-6-2011 23:07, Rugxulo schreef: > COUNTRY.SYS isn't needed for DISPLAY-only stuff, e.g. codepages on > screen, nor for KEYB either. It's only other stuff (collate tables, > y/n), I think. Ah yes thanks for mentioning that. I'd like kinda 'full' support. > 2037, 2039 are the only ones supported (not counting 2040, which is > "unreleased"). You might want to check the kernel list archives. Jim seems to be on holiday so nothing listed yet. Don't know about Sourceforge files. > This involves the following: > * COUNTRY= (config.sys, COUNTRY.SYS / COUNTRY2.SYS / COUNTRY3.SYS) > Eh? I'm only actively aware of COUNTRY.SYS, not any others. Ask > Eduardo Casino (I think) for more info. You might be right, maybe I'm confusing country.sys with keyboard.sys. Oops http://eduardocasino.es/index.php?option=com_content&view=category&layout=blog&id=4&Itemid=9 is on Eduardo's site, not sure this made it into 2040 or not. > The only difference here is it lacks certain int 21h calls, no huge > problem. Also, FreeDOS may not (much, if at all) support PRINTER.SYS. > Otherwise, it shouldn't matter (much). I remember DISPLAY 2.0 being troublesome with regard to UMBs, but that was years ago. >> * NLSFUNC (with optional COUNTRY support, but only if not listed in >> config.sys yet?) > I don't think CONFIG.SYS' "COUNTRY=" affects NLSFUNC. You still need > to run NLSFUNC at runtime (I think) to activate the collate tables, > y/n, currency, time, etc. NLSFUNC seems to be able to take COUNTRY.SYS file as an argument/parameter > Isn't MODECON deprecated / unnecessary?? Guess so, but that's what my entire help request is about. > Well, what explicit languages are you trying to support? Honestly, if > you don't care about "full" NLS, you don't need everything and the > kitchen sink. Latin-1 (850 or 819) is pretty much all you need for the > common folk. (I'm not trying to marginalize anyone, just saying it's > easier to support a subset.) Really, just including EGA.CPX alone (and > without *.CPX) is probably sufficient for basic needs. It's easy enough to add full support once someone's able to give me a fully implemented specific configuration. http://support.microsoft.com/kb/60080 seems to list a specific example, but that's tied to MSDOS and I'm not sure it's complete. Thought Win98 bootdisks had some codepage stuff also but bootdisk.com website only shows modified file images. > Kinda a hack, ain't it? Just don't use DEVLOAD at all unless really > required. (That may not be what you want to hear, though.) It's not > meant to be used in 100% of cases, IMHO. Fair enough, but I like the flexibility. The loading works, but the /H option appears to have been modified from "use UMBs if available, otherwise still load in normal memory" into a "use UMBs if available, otherwise refuse to load at all" Changing it to "0123?DEVICEHIGH=" should be a solution yes, as that won't refuse to load when no UMBs (only give a huge warning) >> * EDIT 0.9a prints its version and DFLAT banner at every invocation. > Recompile? :-) Or just include a different editor (I'd cram TDE, if > possible, or EZEDIT if not). Pretty stuck at using EDIT as a baseline replacement of MS EDIT. Other programs always welcome as extension. > You mean the name or contents? "set BLAH=name " TDE can (optionally) > trim trailing spaces upon save, if that bothers your .BATs. ;-) Or > just use: sed -e "s/ *$//" myfile.bat > myfile.new Contents indeed. I've thus got a batchfile to fix somewhere. >> * I'm not sure which version of SHARE to include, there's quite a few of >> them floating around the internet > It's supposedly mostly non-functional anyways, doesn't fully support > MS SHARE. I think Japheth had a hacked one for some old Win 3.x Office > tools (Word, etc). Other than that, I don't know of any huge reason > for it (and never use it personally). Not even sure what SHARE was used for, was it MS-Client (TCP/IP) and Windows 3, to gain multiple accesses to same file by locking? >> (FD)CONFIG.SYS so far: >> !COUNTRY=001,437,C:\FDOS\BIN\COUNTRY.SYS > I don't think you need to specify this COUNTRY line at all for 437 (U.S.). I know, just want a full implementation/example so people can modify it themselves if desired so, without finding syntax and dependencies. > Is that enough? Should be for most stuff, but 80 would be safer (in > theory). Worth considering, I'd have to check the memory increase. If stuff goes into HMA anyway, I don't mind :) >> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST > Should probably have an "ultra-safe" choice somewhere in here: > > JEMMEX NORAM NOEMS X=TEST I=TEST > > The docs list a different safer value, probably preferable, but I > don't have it here. I'll read up on those parameters, thanks for your info. > (easier) set TMP=%TEMP% you're right, thanks. > This should be echoed at bootup, IMHO, so that people know what it's > default set to (in case of troubles). echo. echo %%BLASTER%% =
Re: [Freedos-devel] confused by NLS-settings
Hi again, On Thu, Jun 30, 2011 at 5:46 AM, Bernd Blaauw wrote: > Op 29-6-2011 23:07, Rugxulo schreef: > >> 2037, 2039 are the only ones supported (not counting 2040, which is >> "unreleased"). > > You might want to check the kernel list archives. Jim seems to be on > holiday so nothing listed yet. Don't know about Sourceforge files. Well, I don't know the entire list, of course. And apparently 2040 is out! But I haven't tested it yet (obviously??). >> The only difference here is it lacks certain int 21h calls, no huge >> problem. Also, FreeDOS may not (much, if at all) support PRINTER.SYS. >> Otherwise, it shouldn't matter (much). > > I remember DISPLAY 2.0 being troublesome with regard to UMBs, but that > was years ago. It still needs a lot of unnecessary UMB room free to load there, e.g. 64 kb or some fairly high amount. And you may even have to explicitly mention it. I forget exactly and always (I think) loaded it low. Well, I'd have to check >>> * NLSFUNC (with optional COUNTRY support, but only if not listed in >>> config.sys yet?) >> I don't think CONFIG.SYS' "COUNTRY=" affects NLSFUNC. You still need >> to run NLSFUNC at runtime (I think) to activate the collate tables, >> y/n, currency, time, etc. > NLSFUNC seems to be able to take COUNTRY.SYS file as an argument/parameter Yes, but it's hardcoded to a specific DISPLAY version, I think. Like I said, I never heavily used it (COUNTRY + NLSFUNC) since it lacked support for 853 anyways. >> Isn't MODECON deprecated / unnecessary?? > Guess so, but that's what my entire help request is about. Well, you'll have to wait for Eric's reply, then. > It's easy enough to add full support once someone's able to give me a > fully implemented specific configuration. > http://support.microsoft.com/kb/60080 seems to list a specific example, > but that's tied to MSDOS and I'm not sure it's complete. > Thought Win98 bootdisks had some codepage stuff also but bootdisk.com > website only shows modified file images. No offense to anybody, but even I know MS i18n codepage support is a joke. They never even bothered supporting Latins 1-4. I did make a bootdisk a while back (year ago?) intending to demo the codepage stuff with FreeDOS, but I never finished it (and nobody else seemed interested). I could (hopefully) dig it up if you're interested. >>> * EDIT 0.9a prints its version and DFLAT banner at every invocation. >> Recompile? :-) Or just include a different editor (I'd cram TDE, if >> possible, or EZEDIT if not). > Pretty stuck at using EDIT as a baseline replacement of MS EDIT. Other > programs always welcome as extension. Well, the 64 kb file limit was a bit of a put-off for me, personally. Maybe good for average use, I guess (just not my favorite preference). >> You mean the name or contents? "set BLAH=name " TDE can (optionally) >> trim trailing spaces upon save, if that bothers your .BATs. ;-) Or >> just use: sed -e "s/ *$//" myfile.bat > myfile.new > Contents indeed. I've thus got a batchfile to fix somewhere. "sed -n l myfile.bat" should show various escapes. Or you could do this: sed -n -e "/ *$/=" myfile.bat (that's two blanks there, one is optional, some seds confuse \+ with +) >>> * I'm not sure which version of SHARE to include, there's quite a few of >>> them floating around the internet >> It's supposedly mostly non-functional anyways, doesn't fully support >> MS SHARE. I think Japheth had a hacked one for some old Win 3.x Office >> tools (Word, etc). Other than that, I don't know of any huge reason >> for it (and never use it personally). > Not even sure what SHARE was used for, was it MS-Client (TCP/IP) and > Windows 3, to gain multiple accesses to same file by locking? It was something dumb like that, I dunno. ;-) >>> (FD)CONFIG.SYS so far: >>> !COUNTRY=001,437,C:\FDOS\BIN\COUNTRY.SYS >> I don't think you need to specify this COUNTRY line at all for 437 (U.S.). > I know, just want a full implementation/example so people can modify it > themselves if desired so, without finding syntax and dependencies. I think we need more real i18n testers. But they are hard to find. :-(( >> This should be echoed at bootup, IMHO, so that people know what it's >> default set to (in case of troubles). echo. echo %%BLASTER%% = >> %BLASTER% echo. > > worthwile considering. Perhaps I should even add DHCP and packet driver > to the standard setup. Getting complicated then though. This is just my personal opinion, but if you want to go that route, the best (IMHO) path would be to include suitable ones for QEMU (NE2000?) and VirtualBox (AMDPD). Though I'm not 100% sure those work as I haven't tried recently, but I've heard they do at least. >>> SET DIRCMD=/P /OGN /4 >> set DIRCMD=/P /OGN /4 /LFN >> lfnfor on >> lfnfor complete on > Are these FreeCOM 0.84pl2 abilities? I've used many versions, some had > LFN, other had different abilities (/Z for errorlevel reporting for > example). Confusing :) Only 0.84 has LFN, which (according to Eric)
Re: [Freedos-devel] confused by NLS-settings
I live in the USA, so don't have a need for any alternative language settings in my everyday life. But, I have messed around with a lot of keyboard layouts and code pages to test some of my keyboard related programs over the years, so I'll let you know what I've discovered. Nearly all of my experience is with MS-DOS, not FreeDOS, so take it with a grain of salt. > COUNTRY.SYS isn't needed for DISPLAY-only stuff, e.g. codepages on > screen, nor for KEYB either. It's only other stuff (collate tables, > y/n), I think. I think I agree here. The main things I think people care about are Code Pages (which I've always manipulated with MODE CON CODEPAGE PREPARE and MODE CON CODEPAGE SELECT) and keyboard layouts (KEYB). Most of the other stuff (NLSFUNC, COUNTRY, etc.) are mostly for sorting/collation and currency/number/time display. But, even this is limited to DOS itself, or programs that call DOS services to provide this functionality. I'm not sure how many programs would call DOS services to do this kind of thing for them, anyway -- a "serious" program would likely do all of this internally and not depend on the user to enter the appropriate settings in CONFIG.SYS or AUTOEXEC.BAT. Again, because I live in the USA, this has never been a concern for me, so I can't say for certain. > Also, FreeDOS may not (much, if at all) support PRINTER.SYS. > Otherwise, it shouldn't matter (much). IIRC, PRINTER.SYS only supported a few different kinds of printers anyway, and was relatively useless even back in the day (at least for me). >> !LASTDRIVE=Z > > Too many unless you're really using them all (or relying on hardcoded > drive values). I'd suggest "P" as a compromise. I personally always use LASTDRIVE=Z. This makes it much easier to manipulate things the way I want to "on the fly" when messing with USB drives or using SUBST or ASSIGN to create "temporary" drive letters. If you don't make LASTDRIVE big enough, you can end up needing to edit CONFIG.SYS and reboot -- really annoying. >> 1?DEVICE=C:\FDOS\BIN\JEMMEX.EXE NOEMS X=TEST > > Should probably have an "ultra-safe" choice somewhere in here: > > JEMMEX NORAM NOEMS X=TEST I=TEST If you are trying to make a "universal" disk that will work on any machine, you need to be careful about using JEMMEX. It doesn't work on every machine. I have a Sony laptop that JEMM refuses to install on, no matter which configuration options are chosen. MS HIMEM.SYS+EMM386.EXE installs just fine on the same computer. >> alias reboot=fdapm warmboot >> alias halt=fdapm poweroff > > I always put all aliases in a single file, e.g. MYALIAS.BAT. > Then, in autoexec, I could say "if exist MYALIAS.BAT call > MYALIAS.BAT". And of course "alias myalias=edit myalias.bat" for > easy tweaking. On the same machine (Sony laptop), FDAPM doesn't work at all because the BIOS doesn't have APM (only ACPI). So, if you're trying to create a "universal" disk, you probably shouldn't use FDAPM at all. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi,
On Wed, Jun 29, 2011 at 5:37 PM, Bret Johnson wrote:
>
> I live in the USA, so don't have a need for any alternative language settings
> in my everyday life.
Ditto. But we're "behind the times". I think only 24% of the world (or
some such small number) is monolingual. Everybody else speaks more
than one.
> Most of the other stuff (NLSFUNC, COUNTRY, etc.) are mostly for
> sorting/collation
> and currency/number/time display. But, even this is limited to DOS itself, or
> programs that call DOS services to provide this functionality. I'm not sure
> how
> many programs would call DOS services to do this kind of thing for them,
There aren't that many (relatively), but I'd be wrong to say none.
Especially European users seem to do it (more) often. One example
offhand is FASMD, though I can't remember exactly what for (perhaps
8-bit filename capitalization in the file open browser).
Maybe some others (NDN?) do also, but again, like you, I never tested
too heavily for default reasons (English only).
> anyway -- a "serious" program would likely do all of this internally and not
> depend
> on the user to enter the appropriate settings in CONFIG.SYS or AUTOEXEC.BAT.
Correct, e.g. TDE or Mined or GNU Emacs.
> IIRC, PRINTER.SYS only supported a few different kinds of printers anyway,
> and was relatively useless even back in the day (at least for me).
Well, I can't remember if it even exists! And, let's be honest,
printers are a pain even at the best of times. So me holding out blind
hope that FreeDOS will ever work ("for me"), in this particular
hardware area, is not going to happen.
Eric (Auer) probably knows more (or maybe Jim Tabor).
> I personally always use LASTDRIVE=Z.
I know, but it wastes a (tiny?) bit of extra RAM that way. Besides,
who needs more than "P"?? Besides you (in heavy testing), of course.
;-)
> If you don't make LASTDRIVE big enough, you can end up needing to edit
> CONFIG.SYS and reboot -- really annoying.
JEMM386 FASTBOOT:-)
> If you are trying to make a "universal" disk that will work on any machine,
> you need to be > careful about using JEMMEX. It doesn't work on every
> machine. I have a Sony
> laptop that JEMM refuses to install on, no matter which configuration options
> are
> chosen. MS HIMEM.SYS+EMM386.EXE installs just fine on the same computer.
Well, we'd *all* have to test all our dopey machines (even virtual).
Or you'd have to make sure it can be overriden (F8, so don't do
"SWITCHES=/F /N").
We still never officially patched HIMEMX to 3.33 with the "jmp $+2"
patch for old 386s. :-(
>>> alias reboot=fdapm warmboot
>>> alias halt=fdapm poweroff
>
> On the same machine (Sony laptop), FDAPM doesn't work at all because
> the BIOS doesn't have APM (only ACPI). So, if you're trying to create a
> "universal" disk, you probably shouldn't use FDAPM at all.
My old (dead) laptop didn't work with CTmouse. I think we all know
that hardware is flaky and incompatible, sometimes.
Just be sure not to use "SWITCHES=/F /N", and it'll be fine, IMHO. Or
alternately include a (very lean, spartan) setup as #1 choice or
whatever. At least then somebody can reboot "just to see" if it'll
work then if it didn't otherwise.
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi all, > Well, what explicit languages are you trying to support? Honestly, if > you don't care about "full" NLS, you don't need everything and the > kitchen sink. Latin-1 (850 or 819) is pretty much all you need for the > common folk. (I'm not trying to marginalize anyone, just saying it's > easier to support a subset.) Really, just including EGA.CPX alone (and > without *.CPX) is probably sufficient for basic needs. Cp819, along with almost all other ISO 8859-x codepages, has never been released; I've prepared them a long time ago but I really don't know whether is there any interest on ISO 8859 codepages. I have also prepared, a long time ago, MAC OS and Windows codepages. Should (all | most) of you tell me that support for them is interesting for FreeDOS, I would work on distinct sets of KEYB*.SYS keyboard layout library files. Henrique -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Bret, Em 29/06/2011 18:37, Bret Johnson escreveu: > I live in the USA, so don't have a need for any alternative language settings > in my everyday life. But, I have messed around with a lot of keyboard > layouts and code pages to test some of my keyboard related programs over the > years, so I'll let you know what I've discovered. Nearly all of my > experience is with MS-DOS, not FreeDOS, so take it with a grain of salt. you say you've messed around with a lot of keyboard layouts and codepages. That called my attention. Would you mind telling me which codepages you tried? I'm particularly looking for cp854 and cp776. I just know that they existed but I never found their description. If necessary, I could send you a list of all codepages I know and you could check it against your list. Thanks, Henrique -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Ruĝulo, > No offense to anybody, but even I know MS i18n codepage support is a > joke. They never even bothered supporting Latins 1-4. > > I did make a bootdisk a while back (year ago?) intending to demo the > codepage stuff with FreeDOS, but I never finished it (and nobody else > seemed interested). I could (hopefully) dig it up if you're > interested. How did that demo work? Henrique -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi, On Wed, Jun 29, 2011 at 9:10 PM, Henrique Peron wrote: > >> Well, what explicit languages are you trying to support? Honestly, if >> you don't care about "full" NLS, you don't need everything and the >> kitchen sink. Latin-1 (850 or 819) is pretty much all you need for the >> common folk. > > Cp819, along with almost all other ISO 8859-x codepages, has never been > released; I know. :-) But Kosta Kostis' old ISOLATIN.CPI works in a pinch. > I've prepared them a long time ago but I really don't know > whether is there any interest on ISO 8859 codepages. Probably not much. And I don't use i18n in FreeDOS very much these days. :-/ > I have also prepared, a long time ago, MAC OS and Windows codepages. > > Should (all | most) of you tell me that support for them is interesting > for FreeDOS, I would work on distinct sets of KEYB*.SYS keyboard layout > library files. Well, as you've previously said, things like 853 vs. 913, we already have 853 (DISPLAY, KEYB), big thanks to you, which (unlike 913) additionally supports box chars. 913 (Latin-3) is only good for ultra compatibility, but it's easy (for me) to translate a text (semi-)manually if needed. In short, sure, it'd be cool, but it's probably not worth you wasting too much time on it unless you really, really wanted to. I don't want to overburden you. :-(It's a volunteer project, so feel free to work on whatever you want. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Saluton, scipovanto!:-) On Wed, Jun 29, 2011 at 9:50 PM, Henrique Peron wrote: > Hi Ruĝulo, >> No offense to anybody, but even I know MS i18n codepage support is a >> joke. They never even bothered supporting Latins 1-4. >> >> I did make a bootdisk a while back (year ago?) intending to demo the >> codepage stuff with FreeDOS, but I never finished it (and nobody else >> seemed interested). I could (hopefully) dig it up if you're >> interested. > How did that demo work? How else? Just crammed a bunch of stuff on floppy, basically, trying to make as useful a disk as possible, esp. catering to i18n (KEYB, DISPLAY, COUNTRY, Mined, Blocek, Foxtype) while still being "overall" useful in general for DOS. I never finished it, and nobody whined. Plus I'd have to vaguely update it and gather all sources (ugh). But I can dig it up (maybe) if desired. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Saluton denove, On Wed, Jun 29, 2011 at 10:16 PM, Rugxulo wrote: > Saluton, scipovanto! :-) > > On Wed, Jun 29, 2011 at 9:50 PM, Henrique Peron wrote: >> Hi Ruĝulo, >> >>> I did make a bootdisk a while back (year ago?) intending to demo the >>> codepage stuff with FreeDOS, but I never finished it (and nobody else >>> seemed interested). I could (hopefully) dig it up if you're >>> interested. >> How did that demo work? > > How else? Just crammed a bunch of stuff on floppy, basically, trying > to make as useful a disk as possible, esp. catering to i18n (KEYB, > DISPLAY, COUNTRY, Mined, Blocek, Foxtype) while still being "overall" > useful in general for DOS. > > I never finished it, and nobody whined. Plus I'd have to vaguely > update it and gather all sources (ugh). But I can dig it up (maybe) if > desired. At risk of boring everyone (or even accidentally spamming the group), I'll post my AUTOEXEC.BAT and CONFIG.SYS here, as well as "ls -lR" contents of the disk itself (which I just dumped via PuppyLinux, in case you're wondering why it says "root" everywhere). I doubt anybody cares, but perhaps Bernd will see what settings he's looking for. (CONFIG.SYS): MENU 1 NLS: Greek MENU 2 *** NLS: Esperanto *** MENU 3 no NLS extras loaded MENUDEFAULT=2,20 REM SWITCHES=/F /N 12?IDLEHALT=1 12?KEYBUF=0x120,0x1d0 REM this needs 286+ (XMSv2 only) REM DEVICE=A:\FDOS\FDXMS286.SYS REM 386+ (XMSv3) 123?DEVICE=A:\UTILS\XMGR.SYS REM 5 MB cache (386+) REM DEVICE=A:\UTILS\UIDE.SYS /S5 /N2 123?DEVICE=A:\UTILS\UIDE.SYS /S5 /D:FDCD000 /C0 123?DEVICE=A:\FDOS\NANSI.SYS 123?DEVICE=A:\FDOS\MORESYS.SYS 123?SHELL=A:\COMMAND.COM A:\ /E:1024 /P 1?COUNTRY=030,869,A:\FDOS\COUNTRY.SYS 2?COUNTRY=1,,A:\FDOS\COUNTRY.SYS 123?DOS=HIGH,UMB 123?BUFFERS=10 123?FILES=40 123?LASTDRIVE=G (AUTOEXEC.BAT): @echo off if "%CONFIG%"=="1" set DEFAULT=869 if "%CONFIG%"=="2" set DEFAULT=853 alias autoexec=ezedit a:\autoexec.bat alias config=ezedit a:\config.sys alias 7za=7zdecode alias 7zdec=7zdecode alias p7zip=7zdecode alias gunzip=untar -d alias grep=xgrep alias uname=ver /r alias mined=mined386 alias attrib=attr alias edit=ezedit alias cpuid=cpulevel alias fdisk=xfdisk alias m=mem /c /p REM (must have soundcard hooked up to CD drive ??) alias playcd=cdrom2 play01 d: REM won't switch to 853 if KEYB is loaded, must unload + switch + reload alias esperanto=mode con cp sel=853 alias 853=mode con cp sel=853 alias 737=mode con cp sel=737 alias 869=mode con cp sel=869 alias sta=mode con cp /sta alias status=mode con cp /sta alias 25=mode 80,25 alias 43=mode 80,43 alias 50=mode 80,50 prompt [ FreeDOS ] $p$g path a:\;a:\fdos;a:\utils;a:\extras;g:\ for %%a in (TEMP TMP TMPDIR) do set %%a=g:\ set DIRCMD=/lfn lfnfor on lfnfor complete on REM (normally uses LONGNAME.DAT, not silly patented VFAT hacks) REM (note that your .EXEs need int 21h, 71xxh Win9x API, e.g. DJGPP) :: starlfn /i REM screen saver, auto-sleep monitor after 7 mins. of inactivity idledpms 7 :: (now using UIDE w/ 5 MB cache, sorry Eric!) REM 32/4 = 8 MB cache :: lbacache flop 32 REM tickle == cache helper for floppy :: tickle REM Jack's RAM disk rdisk /s10 /:g if "%CONFIG%"=="3" goto notnls g: if exist a:\fdos\ega2_17.tgz untar a:\fdos\ega2_17.tgz >NUL a: mode 80,43 display con=(ega,,3) mode con cp prep=((853) a:\fdos\ega.cpx) mode con cp prep=((,737,869) g:\ega5.cpx) mode con cp sel=%DEFAULT% nlsfunc /y a:\fdos\country.sys REM ... NLSFUNC test begin ... echo a:\tmp\upper.com êÖîÞë a:\tmp\upper.com êÖîÞë echo. echo a:\tmp\upper.com Rugxulo a:\tmp\upper.com Rugxulo echo. REM ... NLSFUNC test end ... :notnls REM (can unload later) REM BioMenace (bmenace2.exe) needs this setup + BIO.COM :: jemm386 load x=test i=test noram REM (both of these can unload later) ctmouse /w /o shcdx33e /Q /D?FDCD000 /~ if "%CONFIG%"=="3" goto finish g: if exist a:\fdos\keybrd.tgz untar a:\fdos\keybrd.tgz >NUL a: REM (can unload later, needs 286+) REM !! BUG ALERT !!: do NOT use 2009 KEYB*.SYS files w/ 2006 KEYB.EXE if "%DEFAULT%"=="853" keyb us,,g:\keyboard.sys if not "%DEFAULT%"=="853" keyb gk,,g:\keybrd2.sys echo. echo KEYB: Ctrl-Alt-F1 to disable or Ctrl-Alt-F2 to re-enable! echo. :: mode con cp /status country.exe :finish time /t date /t ver /r set DEFAULT= cd\tmp (I18NDOS.TXT): /mnt/sdb: total 117 -rwxr-xr-x 1 root root 2573 2011-02-15 08:40 autoexec.bat -rwxr-xr-x 1 root root 65846 2008-03-25 23:33 command.com -rwxr-xr-x 1 root root 640 2011-02-12 10:33 config.sys drwxr-xr-x 2 root root 512 2010-10-22 02:48 extras drwxr-xr-x 2 root root 1536 2010-10-22 02:38 fdos -rwxr-xr-x 1 root root 45161 2009-08-01 16:18 kernel.sys drwxr-xr-x 2 root root 512 2010-10-22 02:39 tmp drwxr-xr-x 2 root root 1024 2010-10-22 02:38 utils /mnt/sdb/extras: total 698 -r-xr-xr-x 1 root root 1528 2010-10-30 06:24 biopatch.txt -r-xr-xr-x 1 root root 2643
Re: [Freedos-devel] confused by NLS-settings
> you say you've messed around with a lot of keyboard layouts and > codepages. That called my attention. > > Would you mind telling me which codepages you tried? I'm > particularly looking for cp854 and cp776. I just know that they > existed but I never found their description. > > If necessary, I could send you a list of all codepages I know and > you could check it against your list. The only ones I have seen/tested are the ones that came with MS-DOS 6 & MS-DOS 7 / Win95 (437, 850, 855, 860, 861, 863, 865, and 866). I've never seen 854 or 776. I've tested with about 50 different keyboard layouts, again the ones that came with MS-DOS 6 & 7. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi!
>> IIRC, PRINTER.SYS only supported a few different kinds of printers anyway,
>> and was relatively useless even back in the day (at least for me).
>
> Well, I can't remember if it even exists! And, let's be honest,
> printers are a pain even at the best of times. So me holding out blind
> hope that FreeDOS will ever work ("for me"), in this particular
> hardware area, is not going to happen.
>
> Eric (Auer) probably knows more (or maybe Jim Tabor).
In MS DOS, it probably was something which knew the mapping
of characters to bytes for a number of widely used printers
for a number of possible DIP switch settings. I think today
it is more appropriate to just render text as graphics. Of
course this is a bit slower than printing plain text due to
the extra bandwidth used. It can work on e.g. HP/PCL, ESC/P
and PostScript printers (as GRAPHICS). Some printers, for
example ESC/P, also support limited font upload (faster).
There was some thread about how to make approximate fonts
for printers from VGA sized fonts a while ago.
alias reboot=fdapm warmboot
alias halt=fdapm poweroff
>>
>> On the same machine (Sony laptop), FDAPM doesn't work at all because
>> the BIOS doesn't have APM (only ACPI)...
ACPI is also supported but modern ACPI tables can be too
complicated for FDAPM. Then you will have to press ctrl-
alt-delete or the power button instead of using FDAPM...
> My old (dead) laptop didn't work with CTmouse.
That does not help much with testing ;-)
Eric
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi! >> COUNTRY.SYS isn't needed for DISPLAY-only stuff, e.g. codepages on >> screen, nor for KEYB either. It's only other stuff (collate >> tables, y/n), I think. Yes. And if you only need country style numbers and times, often the kernel built-in country table can be enough for you. > Most of the other stuff (NLSFUNC, COUNTRY, etc.) are mostly for > sorting/collation and currency/number/time display. But, even this > is limited to DOS itself, or programs that call DOS services to... For example EDIT and FORMAT use that for time / number formatting. > provide this functionality. I'm not sure how many programs would > call DOS services to do this kind of thing for them, anyway If you count command.com, a lot of your everyday DOS is covered. > a "serious" program would likely do all of this internally and not > depend on the user to enter the appropriate settings in CONFIG.SYS or > AUTOEXEC.BAT. The other way round. A serious program will ask the kernel or environment variables for your global settings from config and autoexec, so you do not have to config each program separately. Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi again, Just some brief comments. On 6/30/11, Rugxulo wrote: >>> I did make a bootdisk a while back (year ago?) intending to demo the codepage stuff with FreeDOS, but I never finished it > > At risk of boring everyone (or even accidentally spamming the group), > I'll post my AUTOEXEC.BAT and CONFIG.SYS here, as well as "ls -lR" This was all a response to xarilaos (?) on Sourceforge asking how to enable Greek. I tried answering him, but I later thought maybe he'd like a "real" example. But he never seemed to respond back. I tried not to overstep the 286 class (hence "untar" instead of .7z everywhere), if at all possible, though I did include optional 386 stuff. I also included some i18n-aware tools (FASMD, touch [DOS 2.0!], country) and some niceties (a few LFN utils, basic install tools, printing stuff, CDROM, mouse, screensaver, NANSI, MORESYS). Ezedit did work with KEYB, though, if you didn't want all the other bloatier solutions. The 43-line screen bit was just so you could comfortably see the country support data printed to screen in one page. I had to switch to UIDE exclusively since I ran out of room for LBACACHE + TICKLE (sorry, Eric). The little dinky UPPER.COM util was just to test something simple (int 21h 6522h). And yes, I was able to cram some goodies (Blocek, Foxtype, and Mined), even Kosta Kostis' ISOLATIN.CPI (for true Latin-[1-4], etc). P.S. Eric, did you ever mirror / download / update CuteMouse to have the patches for newer JWasm versions? (BTW, he updated JWasm and JWlink again recently, now at 2.06d.) http://www.japheth.de/JWasm.html CuteMouse v2.1b4: This is the version of CuteMouse converted to Masm/JWasm syntax. DOS 08/2010 ctm21b4 http://www.japheth.de/Download/DOS/ctm21b4.zip P.P.S. Since Bernd earlier mentioned SHARE.EXE Share: This is a version of FreeDOS Share which has a bug fixed making it impossible to run MS Office applications under Windows 3.1. This version of Share runs with FreeDOS only.DOS 08/2006 SHARE (20 kB) http://www.japheth.de/Download/DOS/SHARE.zip -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Bernd, Briefly in DOS, both kernel and character device drivers are (or should be) codepage aware. - Kernel because of the collation tables, used for example to turn filenames into the uppercase, and so store them uppercased in the FAT - Character devices, because sending out a character to a character device should be codepage independent. Thus, each character device should know how to "write" certain byte of certain codepage. This all is controlled using character device's IOCTL call This all is broadly not used in the US, thus it is mostly "loadable", in the sense that it isn't loaded by default kernel and character devices, and should be loaded as extensions. Finally, a kernel interrupt controls the codepage change (21h/6602h) in the system as a whole: changes the collation table and the character devices (issuing IOCTL's) globally. 2011/6/29 Bernd Blaauw : > This involves the following: > * COUNTRY= (config.sys, COUNTRY.SYS / COUNTRY2.SYS / COUNTRY3.SYS) Set the initial collation table (data is retrieved from the specified file) > * DISPLAY (a TSR by Aitor, versus device driver in MSDOS) CON extension: should control both keyboard and screen. To change screen's codepage, uses int9h. To change keyboard's codepage, calls KEYB (int 2Fh / AD81h) DISPLAY itself has a int 2Fh / AD00h backdoor, that can do all the IOCTL stuff: - MS-DISPLAY is a regular DOS device driver that overrides system CON (provides IOCTL to DOS' CON device) - FD-DISPLAY is a TSR, implements only the 2Fh / AD00h backdoor > * NLSFUNC (with optional COUNTRY support, but only if not listed in > config.sys yet?) Implements the logic behind 21h/6602h to change the codepage globally. > * MODE versus MODECON versus different configurations whether or not > COUNTRY= is set? MODE CON CP or MODE xxx CP is the DOS standard way to call IOCTL on the device xxx. Thus, could be used to change the codepage of the device xxx, but also for some other codepage aware functionality, such as loading codepage tables, etc. As FreeDOS DISPLAY is not a true device driver, for CON it must issue the 2Fh / AD00h backdoor, and thus MODECON was created. This functionality was included into FD MODE, thus MODECON is deprecated and must no longer be used. MODE xxx CP PREPARE is the way to load a codepage from certain CPI/CPX file (using IOCTL write from device xxx, or int 2Fh / AD00h for FD-DISPLAY) MODE xxx CP SELECT is the not recommended way to change the codepage for device xxx (using generic IOCTL from device xxx, or int 2Fh / AD00h for FD-DISPLAY). It leaves the system inconsistent: codepage should be changed for kernel and ALL the devices at the same time (21h/6602h), in other words, CHCP. > * CHCP (internal command to FreeCOM) A simple call to 21h/6602h. > * KEYB (and CPI/CPX files) The keyboard part of the CON extension. It really makes BIOS be codepage aware on keyboards. You miss PRINTER.SYS (if we had any), which would be the PRN extension. I haven't ever seen extensions to COMx devices, but I guess they should be (if they exist) device-dependent. > * EDIT 0.9a prints its version and DFLAT banner at every invocation. in the background. If it causes problems, I have annotated to create a switch to turn it off. Aitor -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hello, 2011/6/29 Bernd Blaauw : > I remember DISPLAY 2.0 being troublesome with regard to UMBs, but that > was years ago. It is not that it is "trobulesome" with regards to UMBs, but that you hardly ever have so much room in UMBs to load it. DISPLAY allows you to have a maximum of 5 codepages prepared in memory to be changed, and that is a bit less than 64 KB. After loading, in the commandline you usually only make room for 1 or 2 codepages (last parameter): DISPLAY CON=(EGA,437,1) and you barely use 11KB, but you don't know beforehard, thus DOS needs to reserve the whole of 64 KB just in case. Most modern versions use XMS and take lesser convenctional memory. >> Isn't MODECON deprecated / unnecessary?? > Guess so, but that's what my entire help request is about. Confirmed. Eric introduced MODECON into MODE some versions ago. > Did I mention hating CuteMouse 2.1b4's cursor/pointer refreshing speed > in EDIT ? Like 5 times per second instead of once every 2 seconds or so :( There's a similar bug filled into EDIT that I marked as "not reproduced", because I was never able to reproduce it, but I never tried CTMOUSE now that you mention it. So in the end it may end up being a CTMOUSE bug (or misconfiguration)? Aitor -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hello, 2011/6/30 Rugxulo : >> I remember DISPLAY 2.0 being troublesome with regard to UMBs, but that >> was years ago. > > It still needs a lot of unnecessary UMB room free to load there, e.g. > 64 kb or some fairly high amount. And you may even have to explicitly > mention it. I forget exactly and always (I think) loaded it low. Well, > I'd have to check If only I could assume that there's ALWAYS XMS ;))) Ok, I'm revealing something about the next version (if I happen to find some spare time for it): There'll be a DISPLAYX.COM file that will refuse to load if there's no XMS. But if there is, then the maximally needed RAM will be of about 10-11 KB, thus the UMB trouble is gone. Could it be made even smaller? I have ideas to do so, but not so much motivation: - if I can asume everyone has a VGA card and stays in text mode - if I can asume that (J)EMM386 has the ROM= option implemented - ... >> NLSFUNC seems to be able to take COUNTRY.SYS file as an argument/parameter > > Yes, but it's hardcoded to a specific DISPLAY version, I think. Like I > said, I never heavily used it (COUNTRY + NLSFUNC) since it lacked > support for 853 anyways. Yes. The payload for being DISPLAY a TSR and not a device driver is that MODE and NLSFUNC are FD-DISPLAY specific (and tied to versions whenever int 2FH changed). I intended to turn it into a device driver once it is stable, but I don't really know if people prefer a TSR or device driver. * EDIT 0.9a prints its version and DFLAT banner at every invocation. >>> Recompile? :-) Or just include a different editor (I'd cram TDE, if >>> possible, or EZEDIT if not). >> Pretty stuck at using EDIT as a baseline replacement of MS EDIT. Other >> programs always welcome as extension. > > Well, the 64 kb file limit was a bit of a put-off for me, personally. > Maybe good for average use, I guess (just not my favorite preference). If only I could asume that there is ALWAYS a DPMI... ;))) Well, from the above you see how much one would need a 386+ and VGA card as a minimum. Would be nice to know how many real FreeDOS users do not meet any of these two requirements. Aitor -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Aitor, Rugxulo, >> It still needs a lot of unnecessary UMB room free to load there, e.g. >> 64 kb or some fairly high amount. And you may even have to explicitly >> mention it. I forget exactly and always (I think) loaded it low. Well, >> I'd have to check > > If only I could assume that there's ALWAYS XMS ;))) As far as I remember, the main problem was that you did not want to require DOS 4.0 or newer and therefore first allocated MANY buffers, then reducing them. With DOS 4.0 or newer, can simply check at run-time whether the user-selected amount of buffers will fit into the available memory, even for device drivers :-) > Could it be made even smaller? I have ideas to do so, but not so much > motivation: > - if I can asume everyone has a VGA card and stays in text mode You cannot assume that, but you could reload fonts from disk after the user returns to text mode. Would of course need some extra care to avoid doing that at the wrong moment but I guess reentrancy is less of an issue as you hook int 10, not int 21. > - if I can asume that (J)EMM386 has the ROM= option implemented Evil idea but effective for real mode BIOSes. For VESA VBE 3 or similar VGA BIOSes, the actually used copy might be in higher memory around 3-4 GB but that is just a guess of me here. >>> Pretty stuck at using EDIT as a baseline replacement of MS EDIT. >>> Other programs always welcome as extension. >> >> Well, the 64 kb file limit was a bit of a put-off for me, personally. >> Maybe good for average use, I guess (just not my favorite preference). > > If only I could asume that there is ALWAYS a DPMI... ;))) There already are TDE, SETEDIT and others for 386 systems, so I would keep EDIT free of that. You could swap buffers of EDIT to XMS when XMS is available (detect at run-time). Regards, Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Op 10-7-2011 10:14, Aitor Santamaría schreef: > Hi Bernd, >> * EDIT 0.9a prints its version and DFLAT banner at every invocation. > in the background. If it causes problems, I have annotated to create a > switch to turn it off. Programs usually don't print any banners or version output unless they themselves already fill half the screen with output. Try opening/editing/closing the same file about 10 times and you'll have a background full of banners/versions. I can't recall *any* other EDIT version reporting its version unless by "/?" or perhaps when starting an empty file. Also going to run UPX (--best --8086) over it to reduce filesize:) > Aitor Bernd -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi, On 7/10/11, Bernd Blaauw wrote: > > Also going to run UPX (--best --8086) over it to reduce filesize:) "--ultra-brute --lzma --8086" is optimal. But LZMA is a lot slower to unpack on really ancient machines, hence why it's not default for dos/mz. Heck, I think there's even (undocumented?) "--small" (but I can't remember if it makes a difference with dos/mz, surely not much anyways [few bytes]). -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi, On 7/10/11, Eric Auer wrote: > Pretty stuck at using EDIT as a baseline replacement of MS EDIT. Other programs always welcome as extension. >>> >>> Well, the 64 kb file limit was a bit of a put-off for me, personally. >>> Maybe good for average use, I guess (just not my favorite preference). >> >> If only I could asume that there is ALWAYS a DPMI... ;))) > > There already are TDE, SETEDIT and others for 386 systems, > so I would keep EDIT free of that. You could swap buffers > of EDIT to XMS when XMS is available (detect at run-time). Don't forget InfoPad (included with CC386), it uses (modified) DFlat also, so maybe it could be adapted to (additionally) make EDIT386. You know what can edit arbitrary-sized files? sed !!! (My favorite!) Maybe that should be included in FreeDOS 1.1 by default! ;-)) http://lvogel.free.fr/sed.htm -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
On Sun, 10 Jul 2011, Bernd Blaauw wrote: > I can't recall *any* other EDIT version reporting its version unless by > "/?" or perhaps when starting an empty file. Which is the exact behavior of the QBASIC editor used in MS-DOS 5 and 6 (and PC DOS 5.x). Personally, I'd dispense with that - as MS also did with the second, standalone version of their editor (win9x, win2k/xp). -uso. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Eric, 2011/7/10 Eric Auer : > > Hi Aitor, Rugxulo, > >>> It still needs a lot of unnecessary UMB room free to load there, e.g. >>> 64 kb or some fairly high amount. And you may even have to explicitly >>> mention it. I forget exactly and always (I think) loaded it low. Well, >>> I'd have to check >> >> If only I could assume that there's ALWAYS XMS ;))) > > As far as I remember, the main problem was that you did not want > to require DOS 4.0 or newer and therefore first allocated MANY > buffers, then reducing them. With DOS 4.0 or newer, can simply > check at run-time whether the user-selected amount of buffers > will fit into the available memory, even for device drivers :-) You remember wrong. It's simply that if the reallocate call fails, DISPLAY won't load at all, and that is not desirable. >> Could it be made even smaller? I have ideas to do so, but not so much >> motivation: >> - if I can asume everyone has a VGA card and stays in text mode > > You cannot assume that, but you could reload fonts from disk > after the user returns to text mode. Would of course need some > extra care to avoid doing that at the wrong moment but I guess > reentrancy is less of an issue as you hook int 10, not int 21. Change codepage can be called anytime. I can't just assume the disk/file will be there to reload. Anyway Eric, I won't discuss anymore about this. Be it public or private, it is boring to be talking about the same issues once and once again. If instead of talking you send me some code that works the way it is expected, I may merge it into the sources. Pretty stuck at using EDIT as a baseline replacement of MS EDIT. Other programs always welcome as extension. >>> >>> Well, the 64 kb file limit was a bit of a put-off for me, personally. >>> Maybe good for average use, I guess (just not my favorite preference). >> >> If only I could asume that there is ALWAYS a DPMI... ;))) > > There already are TDE, SETEDIT and others for 386 systems, > so I would keep EDIT free of that. You could swap buffers > of EDIT to XMS when XMS is available (detect at run-time). I know. But it's a lot more complex ;) Aitor -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Aitor, It still needs a lot of unnecessary UMB room free to load there, e.g. 64 kb or some fairly high amount. And you may even have to explicitly mention it. I forget exactly and always (I think) loaded it low. Well, I'd have to check >>> >>> If only I could assume that there's ALWAYS XMS ;))) >> >> As far as I remember, the main problem was that you did not want >> to require DOS 4.0 or newer and therefore first allocated MANY >> buffers, then reducing them. With DOS 4.0 or newer, can simply >> check at run-time whether the user-selected amount of buffers >> will fit into the available memory, even for device drivers :-) > > You remember wrong. > It's simply that if the reallocate call fails, DISPLAY won't load at > all, and that is not desirable. At the moment, DISPLAY will fail to load into any normal-sized UMB which means people will avoid using DISPLAY at all, which is even less desirable than a failure to load it when you try to load it into a too small USB. In the latter case, you can still reduce the number of buffers or make a bit more space to load DISPLAY into an USB at the next boot. When DISPLAY always starts with huge initial heap size, there is no workaround possibly beyond not using it... That said, a possible fallback could be to allocate low memory ONLY if the reallocation call fails. Then you neither have to start with huge initial heap nor have to abort loading either. > Change codepage can be called anytime. I can't just assume the > disk/file will be there to reload. It could be a command line option to enable this - saving RAM at the expense of a limited risk of change codepage calls later. Actually if XMS is available, buffering there will avoid a risk. > If instead of talking you send me some code that works the way it is > expected, I may merge it into the sources. Such code would fail to load DISPLAY at all if the user wants too many buffers and tries to load DISPLAY into a too small UMB (unless the low memory fallback is implemented) so it is in a way a matter of taste how to fail under RAM shortage. My personal opinion is that most people will only need SMALL numbers of buffers, so you could have a fixed allocation for that. Then only explicitly selecting many buffers will have the risk of failed reallocation calls and can be documented. >> so I would keep EDIT free of that. You could swap buffers >> of EDIT to XMS when XMS is available (detect at run-time). > > I know. But it's a lot more complex ;) I know ;-) Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hello, 2011/7/10 Eric Auer : > > Hi Aitor, > > It still needs a lot of unnecessary UMB room free to load there, e.g. > 64 kb or some fairly high amount. And you may even have to explicitly > mention it. I forget exactly and always (I think) loaded it low. Well, > I'd have to check If only I could assume that there's ALWAYS XMS ;))) >>> >>> As far as I remember, the main problem was that you did not want >>> to require DOS 4.0 or newer and therefore first allocated MANY >>> buffers, then reducing them. With DOS 4.0 or newer, can simply >>> check at run-time whether the user-selected amount of buffers >>> will fit into the available memory, even for device drivers :-) >> >> You remember wrong. >> It's simply that if the reallocate call fails, DISPLAY won't load at >> all, and that is not desirable. > > At the moment, DISPLAY will fail to load into any normal-sized UMB > which means people will avoid using DISPLAY at all, which is even > less desirable than a failure to load it when you try to load it > into a too small USB. In the latter case, you can still reduce the We all understood in the firs place. > number of buffers or make a bit more space to load DISPLAY into an > blah, blah as I said, I'm tired of talking about this with you again and again and again... > That said, a possible fallback could be to allocate low memory ONLY > if the reallocation call fails. Then you neither have to start with > huge initial heap nor have to abort loading either. That is what LOADHIGH is supposed to do. Aitor -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Op 10-7-2011 16:07, Aitor Santamaría schreef: > Hello, > This NLS stuff is doing my head in, even before trying to automate it in configuration scripts.. CONFIG.SYS: COUNTRY=31,858,C:\FDOS\BIN\COUNTRY.SYS NLS.BAT / AUTOEXEC.BAT: = NLSFUNC C:\FDOS\BIN\COUNTRY.SYS DISPLAY CON=(EGA,858,1) MODE CON CP PREP=((858) C:\FDOS\CPI\EGA.CPX) MODE CON CP SEL=858 KEYB US,858,C:\FDOS\BIN\KEYBOARD.SYS /NOHI CHCP 858 1) Is above correct? If not, how should it be? 2) Why's KEYB 2.0 crashing under JEMMEX? (see below #1) 3) Why's KEYB 2.0 crashing when clean booting? (see below #2) 4) Why's NLSFUNC 0.4 not throwing errorlevel 1 or so when already installed? 5) DISPLAY seems to be able to be loaded lots of time in a row? 6) Why's CHCP choking? Expected it to work in 2040 as I think it worked in 2035 or 2037 or even 2039. Might be due to one of earlier loaded tools (be it NLSFUNC, DISPLAY or MODE) ? 7) Isn't CHCP supposed to be replacing MODE CON CP SEL ? 8) How do I get an euro sign from keyboard? Thought using 858 instead of 850 would allow this, keyboard has a sign above the "5". 9) I think Rugxulo mentioned something about KEYB/KEYBOARD.SYS in some earlier mail? http://www.columbia.edu/~em36/wpdos/eurodos.html seems like a fun site to read up on things Bernd C:\>nls x y FreeDOS NLSFUNC ver. 0.4 NLSFUNC is already installed FreeDOS DISPLAY ver. 0.13b Buffers allocated: 000 in TPA, 001 in XMS Uncompressing and loading UPXed CPI (CPX) file :-). MODE select codepage 858 function completed FreeDOS KEYB 2.0 (pre4) - (c) Aitor Santamar¡a Merino - GNU GPL 2.0 Keyboard layout: C:\FDOS\BIN\KEYBOARD.SYS:US [858] JemmEx: exception 06 occured at CS:EIP=0BA1:150C, ERRC= SS:ESP=11C6:1D3E EBP=2046 EFL=00033206 CR0=8011 CR2= EAX= EBX=0001 ECX=000A EDX=000A ESI=1D34 EDI=08AE DS=1104 ES=0BA1 FS= GS= [CS:IP]=0F 00 00 A0 A0 05 03 07 Press ESC to abort program unimplemented internal dos function INT2F/122b unimplemented internal dos function INT2F/122d unimplemented internal dos function INT2F/122b unimplemented internal dos function INT2F/122d unimplemented internal dos function INT2F/122b unimplemented internal dos function INT2F/122d unimplemented internal dos function INT2F/122b unimplemented internal dos function INT2F/122d Failed to change current code page. nls x y @echo off if "%1"=="" goto end set charname=CON nlsfunc C:\FDOS\BIN\COUNTRY.SYS >> %charname% DISPLAY CON=(EGA,858,1) >> %charname% MODE CON CP PREP=((858) C:\FDOS\CPI\EGA.CPX) >> %charname% MODE CON CP SEL=858 >> %charname% if "%2"=="" goto chcp KEYB US,858,C:\FDOS\BIN\KEYBOARD.SYS /NOHI >> %charname% goto chcp :chcp CHCP 858 >> %charname% set charname= scrdump /A > out.txt echo. >> out.txt echo %0 %1 %2 %3 %4 %5 %6 %7 %8 %9 >> out.txt echo. >> out.txt if exist %0 set /e charname=truename %0 if exist %0.bat set /e charname=truename %0.bat type %charname% >> out.txt set charname= goto end :end either version 2, or (at your option) any later version. C: HD1, Pri[ 1], CHS=0-1-1, start= 0 MB, size= 101 MB FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00] XMS driver not found. C:\>nls x y FreeDOS NLSFUNC ver. 0.4 FreeDOS DISPLAY ver. 0.13b Buffers allocated: 001 in TPA, 000 in XMS Uncompressing and loading UPXed CPI (CPX) file :-). MODE select codepage 858 function completed FreeDOS KEYB 2.0 (pre4) - (c) Aitor Santamar¡a Merino - GNU GPL 2.0 Keyboard layout: C:\FDOS\BIN\KEYBOARD.SYS:US [858] Invalid Opcode at 150C 2ADC 7246 4129 0004 1800 4325 5C3A 633B 5C3A 6466 73 6F unimplemented internal dos function INT2F/122b unimplemented internal dos function INT2F/122d unimplemented internal dos function INT2F/122b unimplemented internal dos function INT2F/122d unimplemented internal dos function INT2F/122b unimplemented internal dos function INT2F/122d unimplemented internal dos function INT2F/122b unimplemented internal dos function INT2F/122d Failed to change current code page. nls x y -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hello, > This NLS stuff is doing my head in, even before trying to automate it in > configuration scripts.. > > CONFIG.SYS: > > COUNTRY=31,858,C:\FDOS\BIN\COUNTRY.SYS > > NLS.BAT / AUTOEXEC.BAT: > = > NLSFUNC C:\FDOS\BIN\COUNTRY.SYS > DISPLAY CON=(EGA,858,1) > MODE CON CP PREP=((858) C:\FDOS\CPI\EGA.CPX) > MODE CON CP SEL=858 > KEYB US,858,C:\FDOS\BIN\KEYBOARD.SYS /NOHI > CHCP 858 > > > 1) Is above correct? If not, how should it be? MODE CON CP SEL=858 is redundant with CHCP 858. The correct one in this case is CHCP, which changes the codepage globally (MODE CON CP SEL would only change it for the CONSOLE). > 2) Why's KEYB 2.0 crashing under JEMMEX? (see below #1) > 3) Why's KEYB 2.0 crashing when clean booting? (see below #2) I captured a couple of bugs within KEYB 2.0 final, but my question is: why are you using the Pre4, instead of the 2.0 FINAL? I am a bit pressed for time this week, then will be off till august. If I happen to find time for the 2.01 release, I'll let you know, to see if it works better for you. > 4) Why's NLSFUNC 0.4 not throwing errorlevel 1 or so when already installed? This one I don't know (I don't know its implementation details) > 5) DISPLAY seems to be able to be loaded lots of time in a row? You mean that you can load it twice? In theory, you could load it to work with different hardware. In practice, you never have (e.g.) an VGA card and an EGA card at the same time. If that bothers you, use /C. > 6) Why's CHCP choking? Expected it to work in 2040 as I think it worked > in 2035 or 2037 or even 2039. Might be due to one of earlier loaded > tools (be it NLSFUNC, DISPLAY or MODE) ? I don't know. Unfortunately, due to DISPLAY being a TSR, both MODE and NLSFUNC should be tuned with it. If the NLSFUNC version you are using is not liked by DISPLAY, then you can replace CHCP with MODE CON CP SELECT, which is not very good, because kernel will not know about the codepage change (and you could have problems with turning filenames into the uppercase, and storing them in FAT). > 7) Isn't CHCP supposed to be replacing MODE CON CP SEL ? Yes. Even doing MORE than MODE CON CP SEL. It would be the replacement for MODE any_driver CP SEL MODE kernel CP SEL ;) > 8) How do I get an euro sign from keyboard? Thought using 858 instead of > 850 would allow this, keyboard has a sign above the "5". I don't know, but Henrique may be able to tell me (or find out by watching US.KEY in the sources from the layout packs). > 9) I think Rugxulo mentioned something about KEYB/KEYBOARD.SYS in some > earlier mail? ¿? Aitor -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Op 13-7-2011 23:15, Aitor Santamaría schreef: > Hello, > MODE CON CP SEL=858 > is redundant with > CHCP 858. > > The correct one in this case is CHCP, which changes the codepage > globally (MODE CON CP SEL would only change it for the CONSOLE). Thanks. I'll use CHCP if I get it working, otherwise MODE. >> 2) Why's KEYB 2.0 crashing under JEMMEX? (see below #1) >> 3) Why's KEYB 2.0 crashing when clean booting? (see below #2) > > I captured a couple of bugs within KEYB 2.0 final, but my question is: > why are you using the Pre4, instead of the 2.0 FINAL? > I am a bit pressed for time this week, then will be off till august. > If I happen to find time for the 2.01 release, I'll let you know, to > see if it works better for you. Got a link to 2.0-final? Can't even recall how I obtained this one, must been from FreeDOS 1.0 likely. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/display/ lists 0.13 , http://www.freedos.org/software/?prog=display also. > You mean that you can load it twice? > In theory, you could load it to work with different hardware. In > practice, you never have (e.g.) an VGA card and an EGA card at the > same time. > If that bothers you, use /C. I'll have a look, thanks for pointing this out. Bernd -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Op 13-7-2011 23:26, Bernd Blaauw schreef: > Got a link to 2.0-final? Can't even recall how I obtained this one, must > been from FreeDOS 1.0 likely. > > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/display/ > lists 0.13 , > http://www.freedos.org/software/?prog=display also. hm am I confusing DISPLAY and KEYB once again?..oh well, nevermind my previous mail thus. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Op 13-7-2011 23:37, Bernd Blaauw schreef: > hm am I confusing DISPLAY and KEYB once again?..oh well, nevermind my > previous mail thus. Time to end my monologue: updating KEYB to 2.00-final, same issues apply (under kernel 2040). -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Bernd, Country=31 (Kingdom of the Netherlands), ok... Codepage 858 (usable by dutch keyboards, ok)... Well, COUNTRY= is alright. I can't say anything about NLSFUNC. You'll have to reach Eduardo Casino for that. Sorry. :( DISPLAY is alright, so is MODE. KEYB US (Ok, I learned elsewhere in the web that dutch users commonly use the regular US-101 keyboard instead of the dutch one)... CHCP 858 (I didn't even know that there was CHCP for FreeDOS) I just don't know about that /NOHI parameter. :( Henrique Em 13/07/2011 16:58, Bernd Blaauw escreveu: > Op 10-7-2011 16:07, Aitor Santamaría schreef: >> Hello, >> > This NLS stuff is doing my head in, even before trying to automate it in > configuration scripts.. > > CONFIG.SYS: > > COUNTRY=31,858,C:\FDOS\BIN\COUNTRY.SYS > > NLS.BAT / AUTOEXEC.BAT: > = > NLSFUNC C:\FDOS\BIN\COUNTRY.SYS > DISPLAY CON=(EGA,858,1) > MODE CON CP PREP=((858) C:\FDOS\CPI\EGA.CPX) > MODE CON CP SEL=858 > KEYB US,858,C:\FDOS\BIN\KEYBOARD.SYS /NOHI > CHCP 858 > > > 1) Is above correct? If not, how should it be? Yes, it is - I just don't know about /NOHI. :( > 5) DISPLAY seems to be able to be loaded lots of time in a row? If you feel you'll need room for more than a codepage, I suggest you just run DISPLAY CON=(EGA,,6) so that have room for 6 (maximum number). If you underestimated your needs and just created room for 1 codepage, you can always rerun DISPLAY. > 8) How do I get an euro sign from keyboard? Thought using 858 instead of > 850 would allow this, keyboard has a sign above the "5". + <5> and + both do the trick. Henrique -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Ok, that's on me. I found 2-3 bugs that I have already patched (almost), I just have to test a bit, then pack it all. If I don't happen to find time to do it fully, I may distribute two files (the source and binary) to some people, in case it works better for you and it is required for 1.1 in the next days and someone can do me the favour (the rest shouldn't change, maybe the readme and such). Aitor 2011/7/13 Bernd Blaauw : > Op 13-7-2011 23:37, Bernd Blaauw schreef: >> hm am I confusing DISPLAY and KEYB once again?..oh well, nevermind my >> previous mail thus. > > Time to end my monologue: updating KEYB to 2.00-final, same issues apply > (under kernel 2040). > > -- > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi, On 7/13/11, Aitor Santamaría wrote: > >> 2) Why's KEYB 2.0 crashing under JEMMEX? (see below #1) >> 3) Why's KEYB 2.0 crashing when clean booting? (see below #2) > >> 9) I think Rugxulo mentioned something about KEYB/KEYBOARD.SYS in some >> earlier mail? > > ¿? Heh. All I know is that when I tried a few months ago, it seemed the KEY*.SYS files from 2009 choked on KEYB, but those older ones (2.5?) from 2006 worked fine. That may?? be what you're experiencing. I did (locally only, barely) update my silly i18n-DOS floppy disk with latest stuff (kernel, country, sys, mined, uide ... barely fits!), so maybe I'll reboot and try it again later "just in case"! (Probably better to wait until August when Aitor is free, heh.) -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Op 14-7-2011 1:59, Rugxulo schreef: > All I know is that when I tried a few months ago, it seemed the > KEY*.SYS files from 2009 choked on KEYB, but those older ones (2.5?) > from 2006 worked fine. That may?? be what you're experiencing. Could be. I tried FD1.0's KEYBOARD.SYS but that made no difference either. > I did (locally only, barely) update my silly i18n-DOS floppy disk with > latest stuff (kernel, country, sys, mined, uide ... barely fits!), so > maybe I'll reboot and try it again later "just in case"! (Probably > better to wait until August when Aitor is free, heh.) Running out of space even after UPX? nice work :) I'm not in any rush with a final release of FreeDOS 1.1, as it's holiday time right now and quite a few people aren't around or lack time. Releasing another test ISO is my first priority, but I keep running into issues, especially the graphical menus by PowerBatch. Done: "simple" FreeDOS 1.1 bootdisk (1.44MB). 386+ though. Done: integrating INSTALL v4.01. Can't continue till INSTALL has the feature of switching to destination directory after succesfully completing. run install through "X:\SETUP now". -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi again, On 7/13/11, Bernd Blaauw wrote: > Op 14-7-2011 1:59, Rugxulo schreef: > >> All I know is that when I tried a few months ago, it seemed the >> KEY*.SYS files from 2009 choked on KEYB, but those older ones (2.5?) >> from 2006 worked fine. That may?? be what you're experiencing. > > Could be. I tried FD1.0's KEYBOARD.SYS but that made no difference either. Well, I briefly tested my disk, everything worked fine (at least with minimal, 853 / DISPLAY + KEYB only, stuff). But I wasn't using raw or EMM386, only XMS (via XMGR). >> I did (locally only, barely) update my silly i18n-DOS floppy disk with >> latest stuff (kernel, country, sys, mined, uide ... barely fits!), so >> maybe I'll reboot and try it again later "just in case"! (Probably >> better to wait until August when Aitor is free, heh.) > > Running out of space even after UPX? nice work :) Mined increased a bit, and --ultra-brute is slow (72 passes for a 2+ MB file, blech). So I had to remove a very very tiny bit of other cruft (luckily nothing important). Perhaps I should've recompiled Mined -Os, but I didn't (probably not worth it). EDIT: Wha, he's still using PMODSTUB? Heh, oh well. That's 8 kb wasted right there, oops! > I'm not in any rush with a final release of FreeDOS 1.1, as it's holiday > time right now and quite a few people aren't around or lack time. Okay, though I don't know what holiday it could be. (All I can think of is Bastille Day, and I'm pretty sure that's not it!) US and CA already had theirs in the past two weeks, so I guess FR etc. gotta live it up too! ;-) > Releasing another test ISO is my first priority, but I keep running into > issues, especially the graphical menus by PowerBatch. I know this is dumb advice, but I suggest to backup your config files and heavily simplify (no devload, lh, or anything tricky) to isolate the problem. > Done: "simple" FreeDOS 1.1 bootdisk (1.44MB). 386+ though. Good (and 386+ is fine, let others manually install, we'll help!). > Done: integrating INSTALL v4.01. Can't continue till INSTALL has the > feature of switching to destination directory after succesfully completing. >run install through "X:\SETUP now". Wait until Jim has some free time (weekend?). Maybe by then Aitor can help too. Nice to see FD 1.1 in the works! ;-) -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Bernd, 2011/7/13 Bernd Blaauw : > 4) Why's NLSFUNC 0.4 not throwing errorlevel 1 or so when already installed? Because it is harmless. Is it really necessary to treat that case in a different manner than a successful installation? If it is, I'll look into that, it is trivial to modify. > 6) Why's CHCP choking? Expected it to work in 2040 as I think it worked > in 2035 or 2037 or even 2039. Might be due to one of earlier loaded > tools (be it NLSFUNC, DISPLAY or MODE) ? Nope. INT2F/122b and INT2f/122d are not implemented in kernel 2040 (they were in 2039) Don't use NLSFUNC with kernel 2040. Eduardo. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Op 15-7-2011 0:42, Eduardo Casino schreef: > Hi Bernd, hello Eduardo, good to see you're around :) > Because it is harmless. Is it really necessary to treat that case in a > different manner than a successful installation? If it is, I'll look > into that, it is trivial to modify. it's not really necessary, was just looking at a way to branch from a "hey I've already run this part earlier and it's not necessary to run it a 2nd time". > Nope. INT2F/122b and INT2f/122d are not implemented in kernel 2040 > (they were in 2039) Don't use NLSFUNC with kernel 2040. Ouch. Good to know, I'll take this into account. NLSFUNC seemed to work though initially, it's only CHCP that generates the errors. However maybe it explains andy KEYB or DISPLAY difficulties. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi, On 7/14/11, Bernd Blaauw wrote: > Op 15-7-2011 0:42, Eduardo Casino schreef: > >> Nope. INT2F/122b and INT2f/122d are not implemented in kernel 2040 >> (they were in 2039) Don't use NLSFUNC with kernel 2040. > > Ouch. Good to know, I'll take this into account. > NLSFUNC seemed to work though initially, it's only CHCP that generates > the errors. However maybe it explains andy KEYB or DISPLAY difficulties. Eek. Um, anybody want to tell us why 2039 has it but 2040 doesn't?? Certainly lacking NLSFUNC support can't be good, can it? :-/ -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
2011/7/15 Rugxulo : > Eek. Um, anybody want to tell us why 2039 has it but 2040 doesn't?? > Certainly lacking NLSFUNC support can't be good, can it? :-/ 2039 was part of the UNSTABLE series, along with 2035 and 2037 and had a lot of experimental features, but also had the unstable tag for a reason ;-) 2040 seems to be based on the stable series and I suppose that the idea is to have a solid kernel base and then carefully backport features as needed. As the author of NLSFUNC, I don't think it should be a priority now. Most of the job can be done with MODE commands. Eduardo. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi!
>> Eek. Um, anybody want to tell us why 2039 has it but 2040 doesn't??
>> Certainly lacking NLSFUNC support can't be good, can it? :-/
>
> 2039 was part of the UNSTABLE series, along with 2035 and 2037 and had
> a lot of experimental features, but also had the unstable tag for a
> reason ;-)
>
> 2040 seems to be based on the stable series and I suppose...
I disagree about that. I have the impression that 2039 was
based on 2038 stable but because changes were rather large,
2040 is a service release for it, explanation being this:
The history.txt of FreeDOS kernel 2040 lacks a detailed
description of 2037 unstable, so it seems that 2038 and
2039 and 2040 are ALL considered to be stable, with some
backports of code from unstable from time to time :-)
So in short, I do not know what broke int 2f.122b and 122d
or whether it was removed deliberately. The changelog says:
- only 2040 has the subversion commit 1567 by Bart:
> * r1567 drivers/rdpcclk.asm,kernel/{asmsupt,entry,irqstack,kernel,
> nls_hc}.asm, kernel/makefile:
> Remove useless END from nls_hc.asm, add explicit byte
> overrides for older versions of NASM for more compact code,
> and adjust silent relocation segments.
- already 2039 has this update by Bart:
> * r1491 hdr/debug.h, kernel/{init-mod.h,kernel/int2f.asm,nls.c,prf.c,
> proto.h}, sys/{fdkrncfg.c,sys.c}: Use near pointers for printf()s
> where possible. Problematic is only the case where SS!=DS (which
> happens sometimes in resident code), in which case va_list/va_arg
> need to use FAR pointers. DS!=DGROUP never works, so I corrected
> that for NLS_DEBUG, by setting DS in int2f.asm.
- also, Bart ported country sys support from unstable into 2039:
> * r1430 hdr/nls.h, kernel/{config.c, init-mod.h, inthndlr.c, intr.asm,
> kernel/nls.c, kernel/nls_hc.asm, kernel/proto.h}:
> Ported COUNTRY.SYS support from the unstable branch.
> Simple country support is kept: COUNTRY=31 will look for country.sys
> but if it does not exist, not complain and load the built-in info.
So based on the changelog, I would assume that:
- the unstable branch supports country.sys in kernel 2037
- the stable branch supports country.sys in kernel 2039 and 2040
Maybe we have some regression error here. I also wonder why
there seem to be CHKDSK problems with FAT16 or 16-bit kernel
2040, while it actually wants to fix FAT problems from 2039,
could that be another regression bug?
Eric
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on "Lean Startup
Secrets Revealed." This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
> So in short, I do not know what broke int 2f.122b and 122d > or whether it was removed deliberately. The changelog says: Definitely, they are not implemented. > - the unstable branch supports country.sys in kernel 2037 > > - the stable branch supports country.sys in kernel 2039 and 2040 Supporting country.sys and nlsfunc are completely different things. Country.sys support means that the kernel loads the country-specific tables from an external file vs. having them harcoded. Nlsfunc support means that int 2f.122b and 122d must be implemented. Eduardo. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
Hi Eduardo, inthndlr.c int2F_12_handler should implement this... >> So in short, I do not know what broke int 2f.122b and 122d >> or whether it was removed deliberately. The changelog says: > > Definitely, they are not implemented. > Supporting country.sys and nlsfunc are completely different things. True, but I found nothing about specifically nlsfunc in the changelog, so I would rather assume that if 2040 lacks this functionality, 2039 must also lack it. http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/kernel/inthndlr.c?view=log says that the stable inthndlr.c did not change for more than 2 years either, while kernel 2039 is from 8/2009. In other words, the last change in nlsfunc support was from BEFORE we saw kernel 2039, there are no 2039 versus 2040 differences. The stable branch is completely missing the 12/2005 (!) patch from you which implements int 2f.122b and 2f.122d support for NLSFUNC. You can see the differences here: http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/branches/UNSTABLE/kernel/inthndlr.c?r1=1160&r2=1163 The same as a patch in unified diff style can be viewed here: http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/branches/UNSTABLE/kernel/inthndlr.c?r1=1160&r2=1163&view=patch Note that this was the latest change in unstable inthndlr.c. There were few other fixes in unstable after that: A country sys bugfix (8/2006, 1261), the port of a SYS feature from the stable SYS to unstable 3.6c, better config sys read error handling (2/2006, 1177), support for floppyless systems in initdisk (2/2006 1179), a FAT32 bugfix in fattab.c (7/2006, 1253) and a QB (qbasic) 4.0 compatibility fix (8/2006, 1259) in memmgr.c because QB does a double-free... As you can see, UNSTABLE got discontinued almost 5 years ago but apparently some features got overlooked when porting all goodies from unstable into stable. I wonder which those are! Eric PS: The last "stable equals unstable" moment was around 2035a ca 6 years ago, revision 1117 afair, but I think unstable 2037 has far MORE than the following that could be ported to stable: http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/branches/UNSTABLE/docs/history.txt?r1=1103&r2=1164&sortby=date Maybe unstable split earlier or has an incomplete history.txt? -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] confused by NLS-settings
On Jul 15, 2011 7:41 AM, "Eric Auer" wrote: > > > Hi Eduardo, > > inthndlr.c int2F_12_handler should implement this... > > >> So in short, I do not know what broke int 2f.122b and 122d > >> or whether it was removed deliberately. The changelog says: > > > > Definitely, they are not implemented. > > > Supporting country.sys and nlsfunc are completely different things. > > True, but I found nothing about specifically nlsfunc in the > changelog, so I would rather assume that if 2040 lacks this > functionality, 2039 must also lack it. > > http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/kernel/inthndlr.c?view=log > > says that the stable inthndlr.c did not change for more than > 2 years either, while kernel 2039 is from 8/2009. In other > words, the last change in nlsfunc support was from BEFORE we > saw kernel 2039, there are no 2039 versus 2040 differences. > > The stable branch is completely missing the 12/2005 (!) patch > from you which implements int 2f.122b and 2f.122d support for > NLSFUNC. You can see the differences here: > > http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/branches/UNSTABLE/kernel/inthndlr.c?r1=1160&r2=1163 > I will look into updating the kernel this weekend so will be in 2041 (which will be released at the end of July) Jeremy -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
