[Freedos-devel] FreeDOS bug tracker unavailable for 15 min
This was announced on the SourceForge project list. I think this is referring to the Tracker, which we use for the FreeDOS Bug Tracker. Will be down for 15 minutes today: On 2009-01-28, commencing at 17:00 UTC, there will be a scheduled downtime for both developer and project instances of the Trac Hosted App offering of SourceForge.net. The Trac Hosted App should be returned to service after 15 minutes. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Country information in FreeDOS
Hi! I will do some more tests later whether also other country dependend functions (like thousands separator, currency format...) are affected but I suppose these functions don't properly work too. They do - date and number format are country-controlled in apps such as our command.com and our text editor edit :-p Anyway, they are rarely needed - only important ones are these around upcase converting. That depends on what your app does! Many DOS countries mainly use ASCII and maybe a few accented chars, but for example Cyrillic DOS users will definitely enjoy case and collating (sortorder) tables for their charsets... I am using kernel version 2038pre/2036 svn [version Jul 28 2007 compiled Oct 21 2007] This and normal 2036 / 2038 use built-in country info, as said. The unstable / devel kernel 2037, however, handles country data files. You can try that one... As far as I remember, there were no official updates for the 2037 kernel since FreeDOS 1.0, so bugs fixed in the normal kernel since 1.0 will not be fixed in 2037 yet but still it works well enough so you can give it a try. The dynamic loading of Country.sys will be the definitive solution, of course, but it takes much time. It probably does not - while 2037 rewrites much of the whole country handling, you can alledgedly rip out the built-in countries of 2036 / 2038 and throw in the country data file handling of 2037, as long as it is sufficiently bug-free. However, that makes you depend on having a data file around. I would be happy if some developer could COMBINE both styles into one patch for 2038 which ALLOWS data files without FORCING you to use them. In particular, date / time / number formats being available as built-in to those who cannot or do not want to load a country sys data file would be very nice... Can you before it will be done add the hardcoded support also for 042,852 setting? (non Cyrillic east europe) Can you give an exact but ASCII explanation of what has to be changed for that? I mean if you would type the special chars directly in an email, you cannot be sure they will look as intended for everybody on the list. Confusingly, the country definitions of the 2036 / 2038 kernel seem to be not in nls* or nls/* but in config.c for the normal things: German, Dutch, Finnish, Polish, Ukrainian, Russian, Bulgarian, Japanese and Spanish are built-in as far as default codepage number, date format, number format, currency format and currency name are concerned, all indexed by country number... HOWEVER, apparently only ONE codepage can be built-in at a time as far as the OTHER properties are concerned, and only German 850 and American 437 are supported, USA being what you get when you fetch a precompiled kernel. This is what the nls*.* and nls/*.* files do and this is what the 2037 country sys datafile load does much better. In case you were wondering, differences are at how the chars 82, 83, 85, 88 to 8d, 93 to 98, 9b, a0 to a3, c6, d0, d5, e4, e7 and ec are upcased in codepage 850 (some are upcased into their unaccented form by the way). In codepage 437, they are not alphabetic and not upcased. The date, time and currency settings also differ, but as said, those are built-in for several languages while the upcase table and collating tables are only built-in for a single codepage, as is the yes no character (either Y N or J N here). This is because the tables are big and this is why the better solution for sort/upcase country support is indeed loading a country sys data file. I am sure Tom can send you a German upcase precompiled kernel from his collection :-). Then you can check if it works as expected at least for codepage 850. You should also check the 2037 devel / unstable kernel in FreeDOS 1.0, maybe somebody knows the right URL for the zip of exactly that precompiled version? Maybe it is that one... :-) The zip contains 2 kernels (with and without FAT32 support) so just copy one over your kernel dot sys file to switch to unstable. There is also a country sys data file (27 kB!) and a special SYS. Both normal and unstable SYS do work for both kernels, but special SYS has extra experimental features built-in... Give the whole thing a try here: www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/unstablx.zip BTW: Did you add the recent Rayer's fixes into kernel to be it able to boot on cheap notebooks? I reply to that one in a separate thread... Eric -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Rayer fixes - was: Country information in FreeDOS
Hi again, BTW: Did you add the recent Rayer's fixes into kernel to be it able to boot on cheap notebooks? You probably refer to this: mieh tuh! by RayeR 12 Jan 2009 in a thread about 7-Zip 4.62 near the bottom ;-). www.bttr-software.de/forum/board_entry.php?id=5533#p5789 Rugxulo told me about this and together we figured out what exactly Rayer had modified. He had already mailed me about parts of it, but he has not yet explained the rest. So I sent him the mail pasted below, but it seems that he did not react to it yet, maybe on vacation? Eric Forwarded (part of) mail to Rayer about his patches on http://rayer.ic.cz/hardware/evo-t20/fdk2038s.zip ...: ... please do not make that *disable LBA* the default. A simple SYS CONFIG in your BAT files can tune your own copy later. This affects kernel and exeflat sources. Of course I am interested *why* you had to disable LBA for that special computer :-) Next are some patches where I do *not* think it would be useful to add them to the SVN: clean - deletes compile result? (instead of only intermediate files) initdisk - show partn count on error (always shows same if BSS okay) initdisk - start / size printed more wide, why? does it really help? initdisk - reduced parentheses and whitespace a lot, why that?? initdisk - always display if LBA is supported (only for testing?) initdisk - LBA-Transfer error message extended, was that useful? initdisk - added debug dump of all partn w/o using debugprintf?? The last two things might be useful, but I would say the debug dump is so verbose that it should use a separate define, ifdef DEBUG_INITDISK...? I assume the other patches were only left-overs from during your BIOS/LBA/CHS bugfix experiments? Actually was there any real bug? Or just in BIOS? Now the patches which looked *nice* :-)) However, I would like to know *which* of them I already had as bundled diff files and which of them, if any, are already even in SVN...? dosfns, fatfs, proto - IsShareInstalled new lazy check (8/2008?) init-mod - add watcom C to BSS_INIT must-init-explicitly category initdisk - floppy type 6 handling added...? initdisk - DDT should have cyl+1, why? initdisk - too large to handle - message replaced, probably good initdisk - some comments added, drive param debug printf extended initdisk - total_sectors must use ULONG and cyl+1, not cyl...? initdisk - Error reading partition clarified by saying 02Xh hex initdisk - ca 1240/1270 init_readdasd *and DF_DISKCHANGE, DF_NOACCESS? dsk - re-enabled DF_NOACCESS, assuming unknown format bug was old? main - InitializeAllBPBs comment updated main - InitializeAllBPBs if FAT32 then init DBP as FAT32 I would say the InitializeAllBPBs and DF_NOACCESS would need some *testing* Did the patched kernel work at least as good as the unpatched kernel for you, in particular regarding first drive access after boot and regarding the use of FORMAT and similar tools? How about the two cylinder count +1 modifications? I remember we did talk it, but what did you find out? :-) Did you experience any *side effects* from the BSS_INIT change for *Watcom* ? I believe there was also a format *string bug* in some initdisk debug message or similar, is that already fixed in SVN or did I just overlook that your patched kernel has that fix as well? :-). So far my comments on your collected patches and your kernel :-). If you can make a version which has LBA enabled by default again, we should probably ask the people on BTTR and freedos-user to try it and see if it improves or worsens anything for them :-). Then I could start chunking the changes into per-topic ones and start uploading them into SVN as well. Thanks :-) I hope I didn't flood you with too many comments ;-). ... -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Country information in FreeDOS
Hi, after comparing the wikipedia codepage 850 and 852 information, I have the impression that the sort / upcase tables for 852 would differ from the 850 case at the following points: 85, 86, 88, 8a, 8b, 8d, 8f 91, 92, 95 to 98, 9b, 9c, 9d, 9f a4 to a9, ab, ac, ad b7, b8, bd, be d0, d2, d4, d5, d8, dd, de e3 to e8, ea, eb, ee f0, f9 This might be useful to create some 042-852.unf file based on 049-850.unf and then compile the hc and up files somehow (HOW?). By the way, our current nls_hc.asm DIFFERS from our 001-437.hc! asm file, actually compiled into the kernel: segment CONST2 extern _CharMapSrvc:wrt DGROUP hc files, to let the user drop in 001 or 049: segment _DATA extern _CharMapSrvc:wrt TGROUP Of course, you can also edit config.c to get only the date, time, number and currency stuff fixed without fixing the sort and upcase tabs and you can - probably preferred - also use a kernel which supports country sys data files, such as the one from unstablx.zip of 1.0 ... Eric -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
