You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(60) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(280) |
Feb
(411) |
Mar
(455) |
Apr
(367) |
May
(125) |
Jun
(155) |
Jul
(266) |
Aug
(131) |
Sep
(223) |
Oct
(76) |
Nov
(103) |
Dec
(132) |
| 2005 |
Jan
(70) |
Feb
(113) |
Mar
(57) |
Apr
(38) |
May
(110) |
Jun
(74) |
Jul
(365) |
Aug
(198) |
Sep
(116) |
Oct
(119) |
Nov
(184) |
Dec
(55) |
| 2006 |
Jan
(97) |
Feb
(70) |
Mar
(51) |
Apr
(16) |
May
(46) |
Jun
(176) |
Jul
(305) |
Aug
(427) |
Sep
(223) |
Oct
(121) |
Nov
(112) |
Dec
(48) |
| 2007 |
Jan
(16) |
Feb
(19) |
Mar
(67) |
Apr
(69) |
May
(48) |
Jun
(35) |
Jul
(26) |
Aug
(44) |
Sep
(33) |
Oct
(86) |
Nov
(15) |
Dec
(28) |
| 2008 |
Jan
(120) |
Feb
(7) |
Mar
(76) |
Apr
(47) |
May
(41) |
Jun
(24) |
Jul
(25) |
Aug
(34) |
Sep
(58) |
Oct
(7) |
Nov
(16) |
Dec
(40) |
| 2009 |
Jan
(17) |
Feb
(53) |
Mar
(121) |
Apr
(69) |
May
(28) |
Jun
(39) |
Jul
(12) |
Aug
(22) |
Sep
(25) |
Oct
(15) |
Nov
(53) |
Dec
(9) |
| 2010 |
Jan
(10) |
Feb
(30) |
Mar
(10) |
Apr
(44) |
May
(36) |
Jun
(14) |
Jul
(21) |
Aug
(19) |
Sep
(1) |
Oct
(6) |
Nov
(22) |
Dec
(11) |
| 2011 |
Jan
(10) |
Feb
(45) |
Mar
(6) |
Apr
(7) |
May
(38) |
Jun
(40) |
Jul
(248) |
Aug
(150) |
Sep
(124) |
Oct
(40) |
Nov
(36) |
Dec
(57) |
| 2012 |
Jan
(64) |
Feb
(22) |
Mar
(14) |
Apr
(20) |
May
(54) |
Jun
(27) |
Jul
(36) |
Aug
(63) |
Sep
(11) |
Oct
(4) |
Nov
(13) |
Dec
(33) |
| 2013 |
Jan
(49) |
Feb
(36) |
Mar
(8) |
Apr
(17) |
May
(34) |
Jun
(24) |
Jul
(45) |
Aug
(4) |
Sep
(14) |
Oct
(8) |
Nov
(3) |
Dec
(16) |
| 2014 |
Jan
(32) |
Feb
(10) |
Mar
(41) |
Apr
(35) |
May
(23) |
Jun
(9) |
Jul
(110) |
Aug
(9) |
Sep
(12) |
Oct
(6) |
Nov
(16) |
Dec
(77) |
| 2015 |
Jan
(249) |
Feb
(9) |
Mar
(95) |
Apr
(28) |
May
(126) |
Jun
(151) |
Jul
(11) |
Aug
(35) |
Sep
(258) |
Oct
(198) |
Nov
(123) |
Dec
(186) |
| 2016 |
Jan
(166) |
Feb
(100) |
Mar
(11) |
Apr
(4) |
May
(24) |
Jun
(13) |
Jul
(34) |
Aug
(18) |
Sep
(8) |
Oct
(49) |
Nov
(69) |
Dec
(33) |
| 2017 |
Jan
(20) |
Feb
(29) |
Mar
(2) |
Apr
(4) |
May
(33) |
Jun
(32) |
Jul
(16) |
Aug
(8) |
Sep
|
Oct
(67) |
Nov
(39) |
Dec
(4) |
| 2018 |
Jan
(29) |
Feb
(42) |
Mar
(2) |
Apr
(5) |
May
(13) |
Jun
(24) |
Jul
(160) |
Aug
(76) |
Sep
(64) |
Oct
(42) |
Nov
(47) |
Dec
(32) |
| 2019 |
Jan
(33) |
Feb
(29) |
Mar
(36) |
Apr
(11) |
May
(11) |
Jun
(18) |
Jul
(20) |
Aug
(11) |
Sep
(7) |
Oct
(16) |
Nov
(3) |
Dec
(20) |
| 2020 |
Jan
(10) |
Feb
|
Mar
(10) |
Apr
(13) |
May
(53) |
Jun
(26) |
Jul
(8) |
Aug
(20) |
Sep
(8) |
Oct
(60) |
Nov
(93) |
Dec
(119) |
| 2021 |
Jan
(20) |
Feb
(54) |
Mar
(26) |
Apr
(17) |
May
(200) |
Jun
(231) |
Jul
(124) |
Aug
(100) |
Sep
(25) |
Oct
(18) |
Nov
(17) |
Dec
(93) |
| 2022 |
Jan
(129) |
Feb
(59) |
Mar
(58) |
Apr
(70) |
May
(39) |
Jun
(22) |
Jul
(83) |
Aug
(110) |
Sep
(65) |
Oct
(80) |
Nov
(42) |
Dec
(19) |
| 2023 |
Jan
(145) |
Feb
(118) |
Mar
(179) |
Apr
(76) |
May
(46) |
Jun
(67) |
Jul
(76) |
Aug
(69) |
Sep
(31) |
Oct
(52) |
Nov
(82) |
Dec
(46) |
| 2024 |
Jan
(51) |
Feb
(97) |
Mar
(50) |
Apr
(51) |
May
(150) |
Jun
(96) |
Jul
(117) |
Aug
(87) |
Sep
(106) |
Oct
(102) |
Nov
(153) |
Dec
(158) |
| 2025 |
Jan
(255) |
Feb
(302) |
Mar
(185) |
Apr
(98) |
May
(176) |
Jun
(51) |
Jul
(12) |
Aug
(46) |
Sep
(17) |
Oct
(78) |
Nov
(6) |
Dec
|
|
From: <je...@sh...> - 2025-11-06 00:34:40
|
Then I had to correct something I sent... > On Nov 5, 2025, at 7:26 PM, je...@sh... wrote: > > I replied to both... > >> On Nov 5, 2025, at 2:20 PM, Bernd Böckmann via Freedos-devel <fre...@li...> wrote: >> >> Anyone willing to respond to the following Gitlab issue? >> >> https://gitlab.com/FreeDOS/issue-reporting/-/issues/75 >> >> For those without permission to read it, user wil...@gm... <mailto:wil...@gm...> reported: >> >>> I had to reinstall Windows to fix the issue >>> On Wed, 5 Nov 2025, 8:36 pm WILLIAM MACKIE, wil...@gm... wrote: >>>> I tried to install the USB full version and it just bricked my Acer you have to fix the bug because the USB full version also has numerous amounts of errors when it comes to booting the setup >> >> No further details given... >> > > It is unfortunate you had a bad experience installing FreeDOS. We will need more information than you have provided to attempt to remedy any issues with OS or its installation. What "bug" are referring to, when does it occur, what should it do and what does it actually do? > > You also mention errors booting the setup. Are you referring to the booting the install media or the booting the installed FreeDOS from the hard drive. What are the errors you received? Without some additional information we will be unable to assist or fix any of the issues you mentioned. > >> --- >> >> Another one: >> >> https://gitlab.com/FreeDOS/issue-reporting/-/issues/74 >> >> Joshua Hudson wrote on this: >> >>> I encountered what looks like packaging error on the FreeDOS Lite USB distribution >>> For some reason, FREEDOS\BIN has a ZIP.EXE but not an UNZIP.EXE. This makes it really hard to restore a single missing or damaged file. Note that ZIP.EXE can't unzip archives. >>> It would make a lot more sense if it had UNZIP.EXE but not ZIP.EXE but I don't think space is that much of an issue that it can't just have both. I'm guessing ZIP is there for a reason. >> >> In my opinion he is right on this. If there is a ZIP, there should also be an UNZIP. >> >> Bernd >> > > Unlike the Large USB and LiveCD, only FreeDOS BASE and programs required by the installer are present on the LITE USB image. Neither ZIP nor UNZIP are part of FreeDOS BASE. ZIP is only present on the LITE USB because when the installer is run in advanced mode, it has the option to create a compressed ZIP backup of any existing DOS system files before installing FreeDOS. However, I agree that it could be useful in recovering files from such a compressed backup. So, it is possible a version of UNZIP may be included on the LITE USB in the future. I misspoke in my previous reply... Actually, ZIP and UNZIP are installed with FreeDOS BASE. But only packages which may be needed by the installer are extracted on the LITE USB. ZIP's executable is present because it can be used by the installer. UNZIP is not used by the installer. > >> >> >> _______________________________________________ >> Freedos-devel mailing list >> Fre...@li... <mailto:Fre...@li...> >> https://lists.sourceforge.net/lists/listinfo/freedos-devel <https://lists.sourceforge.net/lists/listinfo/freedos-devel> |
|
From: <je...@sh...> - 2025-11-06 00:26:48
|
I replied to both... > On Nov 5, 2025, at 2:20 PM, Bernd Böckmann via Freedos-devel <fre...@li...> wrote: > > Anyone willing to respond to the following Gitlab issue? > > https://gitlab.com/FreeDOS/issue-reporting/-/issues/75 > > For those without permission to read it, user wil...@gm... <mailto:wil...@gm...> reported: > >> I had to reinstall Windows to fix the issue >> On Wed, 5 Nov 2025, 8:36 pm WILLIAM MACKIE, wil...@gm... wrote: >>> I tried to install the USB full version and it just bricked my Acer you have to fix the bug because the USB full version also has numerous amounts of errors when it comes to booting the setup > > No further details given... > It is unfortunate you had a bad experience installing FreeDOS. We will need more information than you have provided to attempt to remedy any issues with OS or its installation. What "bug" are referring to, when does it occur, what should it do and what does it actually do? You also mention errors booting the setup. Are you referring to the booting the install media or the booting the installed FreeDOS from the hard drive. What are the errors you received? Without some additional information we will be unable to assist or fix any of the issues you mentioned. > --- > > Another one: > > https://gitlab.com/FreeDOS/issue-reporting/-/issues/74 > > Joshua Hudson wrote on this: > >> I encountered what looks like packaging error on the FreeDOS Lite USB distribution >> For some reason, FREEDOS\BIN has a ZIP.EXE but not an UNZIP.EXE. This makes it really hard to restore a single missing or damaged file. Note that ZIP.EXE can't unzip archives. >> It would make a lot more sense if it had UNZIP.EXE but not ZIP.EXE but I don't think space is that much of an issue that it can't just have both. I'm guessing ZIP is there for a reason. > > In my opinion he is right on this. If there is a ZIP, there should also be an UNZIP. > > Bernd > Unlike the Large USB and LiveCD, only FreeDOS BASE and programs required by the installer are present on the LITE USB image. Neither ZIP nor UNZIP are part of FreeDOS BASE. ZIP is only present on the LITE USB because when the installer is run in advanced mode, it has the option to create a compressed ZIP backup of any existing DOS system files before installing FreeDOS. However, I agree that it could be useful in recovering files from such a compressed backup. So, it is possible a version of UNZIP may be included on the LITE USB in the future. > > > _______________________________________________ > Freedos-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-devel |
|
From: Bernd B. <ber...@bo...> - 2025-11-05 19:21:19
|
Anyone willing to respond to the following Gitlab issue? https://gitlab.com/FreeDOS/issue-reporting/-/issues/75 For those without permission to read it, user wil...@gm... <mailto:wil...@gm...> reported: > I had to reinstall Windows to fix the issue > On Wed, 5 Nov 2025, 8:36 pm WILLIAM MACKIE, wil...@gm... wrote: >> I tried to install the USB full version and it just bricked my Acer you have to fix the bug because the USB full version also has numerous amounts of errors when it comes to booting the setup No further details given... --- Another one: https://gitlab.com/FreeDOS/issue-reporting/-/issues/74 Joshua Hudson wrote on this: > I encountered what looks like packaging error on the FreeDOS Lite USB distribution > For some reason, FREEDOS\BIN has a ZIP.EXE but not an UNZIP.EXE. This makes it really hard to restore a single missing or damaged file. Note that ZIP.EXE can't unzip archives. > It would make a lot more sense if it had UNZIP.EXE but not ZIP.EXE but I don't think space is that much of an issue that it can't just have both. I'm guessing ZIP is there for a reason. In my opinion he is right on this. If there is a ZIP, there should also be an UNZIP. Bernd |
|
From: Jim H. <jh...@fr...> - 2025-11-02 20:36:03
|
We scheduled the next FreeDOS virtual get-together for Sunday, November 16 (11am-noon, US/Central). See you then! On Sun, Nov 2, 2025 at 2:24 PM Victoria Crenshaw <sp...@jo...> wrote: > > i wanna talk to you guys! <3 > > > i wanna see how the program i worked is working i need some feed back xD > |
|
From: Victoria C. <sp...@jo...> - 2025-11-02 20:24:06
|
i wanna talk to you guys! <3 i wanna see how the program i worked is working i need some feed back xD |
|
From: <je...@sh...> - 2025-11-02 00:06:11
|
Usually, I get this up early in the day on the 1st. But, I was very busy all day today. The FreeDOS Interim Test Build T2511 for November is now available for download at: https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/> Changes since T2510: 2025-11-01 19:15:50 project_FDI [unstable] (Shidel): temporarily added FDNPKG16 to Full install for testing 2025-10-27 23:17:47 fdnpkg16 (Shidel): updated to v0.99.8249 2025-10-27 23:08:47 vsbhda (Shidel): updated to v1.8 2025-10-27 21:23:40 htmlhelp (Bernd Boeckmann): update HTMLHELP to v5.3.8 and update help files 2025-10-11 04:05:01 nasm (Shidel): updated to 3.01 2025-10-11 04:01:05 nasm (Shidel): updated to 3.00 2025-10-11 03:57:49 nasm (Shidel): updated to 3.0.0 2025-10-09 16:52:03 project_FD-NLS (Shidel): report update 2025-10-09 16:32:41 project_FD-NLS (Shidel): compute: corrected AI translations 2025-10-09 16:29:28 project_FD-NLS (Shidel): corrected directory for FDNPKG16 translations 2025-10-09 15:50:05 himemx (Shidel): updated to v3.39 2025-10-09 06:29:08 project_FD-NLS (Shidel): added FDNPKG16 translations 2025-10-09 04:29:30 fdnpkg16 (Shidel): version 0.99.8244 2025-10-09 04:24:22 fdnpkg16 (Shidel): Initial commit 2025-10-01 06:07:46 blkdrop (Shidel): NLS: from W.Spiegl, AI translations 2025-10-01 05:57:41 choice (Shidel): NLS: from W.Spiegl, AI translations |
|
From: <je...@sh...> - 2025-10-27 16:14:45
|
> On Oct 27, 2025, at 11:43 AM, Jose Senna via Freedos-devel <fre...@li...> wrote: > > Jerome Shidel said: >> Does anyone object to using PB as the two >> letter language code for Portuguese-Brazil? > > The only objection I can think of is that in > Brazil we speak Portuguese. The difference > is in display codepages and keyboard layouts. > So, why not use "codepage" and "keyboard" > configuration options instead of "language" While a language translation relies on having the correct codepage setting, the reverse is not true and they are not synonymous with each other. Numerous language use codepages 850 or 858. However, their languages are very different. Also, there are codepages above 999 that would require a 4 digit file extension. Like country codes and regions, keyboard layouts are also separate. Since they are separate, there is nothing to prevent a user from configuring things as they wish. For example, you could live in Italy, using the Dutch language with a Swedish keyboard. > This would be less confusing to users of > nonstandard keyboard/display combinations > and to those using the same combination for > more than one language (as I am doing now, > typing English in an ABNT2 (Brazilian) > keyboard. > It would depart from Microsoft's DOS > practice, but how important is this now ? While I have never used a version of MS-DOS not in English, my understanding is that it did not support changing the language of the installed system. Therefore, while you could possibly customize some aspects related to your needs, it did not support changing the language or having multiple translation files. You could only install for the language you wanted and that was that. So, being able to change languages through settings at a later date already deviates from what was available with MS-DOS. |
|
From: Jose S. <jas...@ma...> - 2025-10-27 15:43:27
|
Jerome Shidel said: > Does anyone object to using PB as the two > letter language code for Portuguese-Brazil? The only objection I can think of is that in Brazil we speak Portuguese. The difference is in display codepages and keyboard layouts. So, why not use "codepage" and "keyboard" configuration options instead of "language" This would be less confusing to users of nonstandard keyboard/display combinations and to those using the same combination for more than one language (as I am doing now, typing English in an ABNT2 (Brazilian) keyboard. It would depart from Microsoft's DOS practice, but how important is this now ? |
|
From: <je...@sh...> - 2025-10-27 10:17:01
|
First, lets see if we can resolve one issue… Does anyone object to using PB as the two letter language code for Portuguese-Brazil? It would then be the same length as all other current language codes we use. It will not conflict with any languages in the ISO standard. It at least starts with the same letter as official designation (PT-BR) used in later ISO standards and should be easier for the user to find than things like BX or BZ. > On Oct 26, 2025, at 4:59 PM, tom ehlert via Freedos-devel <fre...@li...> wrote: > > Hallo Herr Fritz Mueller via Freedos-devel, > > am Sonntag, 26. Oktober 2025 um 19:22 schrieben Sie: > >> Hi, >> using the language code for FD NLS ( https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes <https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes> ) will have the following consequences with the file ending: >> >> a) Czechia should use "cs" instead of "cz" ( 4 changes, see: https://shidel.github.io/fd-nls/report.html <https://shidel.github.io/fd-nls/report.html> ) >> b) Denmark should use "da" instead of "dk" (12 changes) >> c) Estonia should use "et" instead of "ee" (3 changes) >> d) Slovenia should use "sl" instead of "si" (2 changes, both .sl already exist) >> e) Brazilian should use "whatever you want, as it is not in ISO 639), instead of "ptb or ptbr" (12 changes). > > You somehow managed to miss that Germany should use "de" instead of “gr" While some programs like FreeCOM use compiled translations and filenames like “finnish.lng”, most of the program translations stored at FD-NLS translation project[1] use external (or tacked onto the executable) NLS files that use the language code as the file extension. I am not aware of any non-source based NLS files which use GR instead of DE for their German. If there were NLS files which used GR as an extension, those would show up on the FD-NLS Status page[2]. Whether or not we decide to leave some existing two letter language codes as-is or change them to be more inline with the ISO standard, we really should provide a list of those codes and languages. With such a table, it becomes less important to what code is actually used. The end user can simply look them up or be pointed to the table when they cannot find the proper code for their language. > Using the country code would have more problems: https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes > a) Esperanto "eo" has no country -> no country code (delete???) > [..] While country codes and regions are just as important as language codes, I think that is a separate issue. Jerome [1] https://github.com/shidel/fd-nls <https://github.com/shidel/fd-nls> [2] https://shidel.github.io/fd-nls/ <https://shidel.github.io/fd-nls/> |
|
From: tom e. <te...@dr...> - 2025-10-26 21:20:56
|
Hallo Herr Fritz Mueller via Freedos-devel, am Sonntag, 26. Oktober 2025 um 19:22 schrieben Sie: > Hi, > using the language code for FD NLS ( https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes ) will have the following consequences with the file ending: > > a) Czechia should use "cs" instead of "cz" ( 4 changes, see: https://shidel.github.io/fd-nls/report.html ) > b) Denmark should use "da" instead of "dk" (12 changes) > c) Estonia should use "et" instead of "ee" (3 changes) > d) Slovenia should use "sl" instead of "si" (2 changes, both .sl already exist) > e) Brazilian should use "whatever you want, as it is not in ISO 639), instead of "ptb or ptbr" (12 changes). You somehow managed to miss that Germany should use "de" instead of "gr" > > Using the country code would have more problems: https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes > a) Esperanto "eo" has no country -> no country code (delete???) > b) Basque "eu" has no country -> no country code (delete???) > c) Japan "ja" would have to use "jp" (1 change) > d) Latin "la" has no country, maybe Italy "it" could be used (1 change) > e) Brazil (?) would have a country (BR) (12 changes) > f) Serbia "sr" would have to use "rs" (4 changes) > g) Sveden "sv" would have to use "se" (more than 50 changes) > h) Ukraine "uk" would have to use "ua" (4 changes) > i) China "zh" would have to use "cn" (1 change) > > Indepent which way you prefer, I think a documentation has to be done (maybe changed). Can anybody tell me where this documentation is? > I hope that this makes decisions for the future of NLS languarges easier. > Any comments? YES. After 40 years of using "GR" changing this to "DE" is a PRETTY FUCKING STUPID IDEA. Upper case intended. Tom |
|
From: <je...@sh...> - 2025-10-26 20:03:53
|
> On Oct 26, 2025, at 2:22 PM, Fritz Mueller via Freedos-devel <fre...@li...> wrote: > > Hi, > using the language code for FD NLS ( https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes <https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes> ) will have the following consequences with the file ending: > > a) Czechia should use "cs" instead of "cz" ( 4 changes, see: https://shidel.github.io/fd-nls/report.html ) > b) Denmark should use "da" instead of "dk" (12 changes) > c) Estonia should use "et" instead of "ee" (3 changes) > d) Slovenia should use "sl" instead of "si" (2 changes, both .sl already exist) Although some users will need to adjust to using a different code for their language, I think “long-term” it would be a good idea to change these. I think it will make it easier for new users to find the appropriate code for their language if those conform to the standard ISO code when possible. > e) Brazilian should use "whatever you want, as it is not in ISO 639), instead of "ptb or ptbr" (12 changes). > > Using the country code would have more problems: https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes > a) Esperanto "eo" has no country -> no country code (delete???) > b) Basque "eu" has no country -> no country code (delete???) > c) Japan "ja" would have to use "jp" (1 change) > d) Latin "la" has no country, maybe Italy "it" could be used (1 change) > e) Brazil (?) would have a country (BR) (12 changes) > f) Serbia "sr" would have to use "rs" (4 changes) > g) Sveden "sv" would have to use "se" (more than 50 changes) > h) Ukraine "uk" would have to use "ua" (4 changes) > i) China "zh" would have to use "cn" (1 change) I feel country codes are a separate issue and should be handled as such. After all, a user could be in country DE and speak language RU. > > Indepent which way you prefer, I think a documentation has to be done (maybe changed). Can anybody tell me where this documentation is? We should try to document these things. I think the best place for that is the Documentation Project in the FreeDOS Archive on GitLab. https://gitlab.com/FreeDOS/docs <https://gitlab.com/FreeDOS/docs> Once a decision is made on these issues, I can likely help create a document and issue a merge request. > I hope that this makes decisions for the future of NLS languarges easier. > Any comments? > Without comments I will start to continue translation with the corrected language abbreviations and use pb for Brazil (if wanted). After a lot of consideration, I think PB makes the most sense when limiting Brazilian Portuguese to only two characters. It is not used by any other language in the ISO language codes. Nor is it used by any country codes. Also unlike other possibilities, when sorting by code, it will be near PT. A user looking for PTB(r) will be much more likely to see PB over things like BX or BZ. > Ah, by the way: the updated FreeDOS htmlhelp (including Bernds updated htmlhelp.exe) 1.1.1 for english and german is available, french and spanish 1.0.8 were only transformed to UTF-8 (ok, some typos corrected) and got the number 1.0.9. It is available here: > > www.bootablecd.de/downloads/freedos/htmlhelp-final-2025-10-15.zip > :-) Jerome |
|
From: Fritz M. <fri...@ma...> - 2025-10-26 18:22:27
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div> <div>using the language code for FD NLS ( <a href="https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes" target="_blank">https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes</a> ) will have the following consequences with the file ending:</div> <div> </div> <div>a) Czechia should use "cs" instead of "cz" ( 4 changes, see: https://shidel.github.io/fd-nls/report.html )</div> <div>b) Denmark should use "da" instead of "dk" (12 changes)</div> <div>c) Estonia should use "et" instead of "ee" (3 changes)</div> <div>d) Slovenia should use "sl" instead of "si" (2 changes, both .sl already exist)</div> <div>e) Brazilian should use "whatever you want, as it is not in ISO 639), instead of "ptb or ptbr" (12 changes).</div> <div> <div>Using the country code would have more problems: https://en.wikipedia.org/wiki/List_of_ISO_3166_country_codes</div> <div>a) Esperanto "eo" has no country -> no country code (delete???)</div> <div>b) Basque "eu" has no country -> no country code (delete???)</div> <div>c) Japan "ja" would have to use "jp" (1 change)</div> <div>d) Latin "la" has no country, maybe Italy "it" could be used (1 change)</div> <div>e) Brazil (?) would have a country (BR) (12 changes)</div> <div>f) Serbia "sr" would have to use "rs" (4 changes)</div> <div>g) Sveden "sv" would have to use "se" (more than 50 changes)</div> <div>h) Ukraine "uk" would have to use "ua" (4 changes)</div> <div>i) China "zh" would have to use "cn" (1 change)</div> <div> </div> <div>Indepent which way you prefer, I think a documentation has to be done (maybe changed). Can anybody tell me where this documentation is?</div> <div> <div>I hope that this makes decisions for the future of NLS languarges easier.</div> <div>Any comments?</div> <div>Without comments I will start to continue translation with the corrected language abbreviations and use pb for Brazil (if wanted).</div> <div> </div> <div> </div> <div>Ah, by the way: the updated FreeDOS htmlhelp (including Bernds updated htmlhelp.exe) 1.1.1 for english and german is available, french and spanish 1.0.8 were only transformed to UTF-8 (ok, some typos corrected) and got the number 1.0.9. It is available here:</div> <div> </div> <div><strong>www.bootablecd.de/downloads/freedos/htmlhelp-final-2025-10-15.zip</strong></div> </div> <div> </div> <div> </div> <div>Willi <div> <div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);"> <div style="margin: 0 0 10.0px 0;"><b>Sent:</b> Thursday, October 09, 2025 at 10:30 AM<br/> <b>From:</b> "Jerome Shidel via Freedos-devel" <fre...@li...><br/> <b>To:</b> "FreeDOS Developers" <fre...@li...><br/> <b>Cc:</b> je...@sh...<br/> <b>Subject:</b> Re: [Freedos-devel] Question about 3-letter language codes</div> <div>As an alternative to BZ, the code PB is also not in use.<br/> <br/> If we do not use PTB, I do not know what tow digit code we should use instead.<br/> <br/> I just think BR should not be used since it is already assigned to a different language in ISO 629-1.<br/> <br/> Since the world has mostly moved to used language_region (like en_US, en_GB), I do not think we need to worry about updates to ISO 639-1 causing new conflicts with any (FreeDOS Only) two character language codes we choose.<br/> <br/> _______________________________________________<br/> Freedos-devel mailing list<br/> Fre...@li...<br/> <a href="https://lists.sourceforge.net/lists/listinfo/freedos-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/freedos-devel</a></div> </div> </div> </div> </div></div></body></html> |
|
From: victoria c. <sp...@jo...> - 2025-10-23 02:25:48
|
https://github.com/sparky4/fdnpkg16/releases/tag/0.99.8249 https://4ch.su/freedos/repos/1.4/html/en/net/fdnpkg16/ from github release page: I merged fdnpkg16 and fdnpkg86 to 1 program that uses httpget externally. Too many issues with them separate and running like before older fdnpkg16 will eat ram and you cannot install hundreds of packages when it eats ram (6400) every time it called httpget(). I just made it so it can call an external simple program. This dose break international support for that particular area. About, fdnpkg86 there is a problem downloading files on my recently acquired Toshiba T1200 system. it just takes too long! Like over 2 hours for it to fail. This should work now on all systems with more than 480+k of ram. If there is issues please contact me asap. my contact is inside the program in the li command just run fdnpkg16 li for my info :D. |
|
From: victoria c. <sp...@jo...> - 2025-10-13 20:28:02
|
So we can test the code thoroughly. also new version dropped. bug fix and translation issue fixed. https://github.com/sparky4/fdnpkg16/releases/tag/0.99.8248b Change log: Added full Danish support, and added an extra function to see available ram for the program. (command fcl)[FDNPKG16 /fcl] Fixed ANOTHER multi package bug. This time it is the removing of multiple packages. http://4ch.mooo.com/freedos/repos/1.4/html/en/net/fdnpkg16/ latest package here or on git hub. Apologies for the very frequent updates. |
|
From: victoria c. <sp...@jo...> - 2025-10-13 20:22:20
|
I again apologize. I keep finding many bugs from a nice qol feature i added. I think i got all edge cases from that code now. https://github.com/sparky4/fdnpkg16/releases/tag/0.99.8248b last version for now until we can fully test it. i am Freezing active development and sticking to bug fixing until we can fully test this program. I will stop for 2 week or until November 1st(unless there is another bug). and will not develop until then. On 10/12/25 7:39 PM, Michael Brutman wrote: > The multiple announcements and versions per week are difficult to keep > track of. > > I would encourage you to work on the code, keep polishing it, > testing it, documenting it, etc. Then after a few weeks make an > announcement or ask for additional testers. > |
|
From: victoria c. <sp...@jo...> - 2025-10-13 20:18:22
|
I will do this for now. <3 I apologize. I keep finding many bugs from a Feature I have implemented. It is because of old left over code. I believe I have fixed it all by now. speaking of i did find another bug. this time with removing more than 1 package. it is mostly old left over code from fdnpkg I just finished 0.99.8248b and i am stopping the adding of new features for now until i see another bug. (i think i got them all I tried most edge cases) As they say in Debian, I am "Freezing" the development until we do full testing. I caught many bugs, and I think i got them all. For now. here is my change log. || <https://github.com/sparky4/fdnpkg16/commit/08425f500dc5783b7d203956a1b4dcfe6d847b2a> Fixed the removing of multiple packages and fixed danish. These multi package manipulation bugs are so many. Because the original code was hard coded to install single packages only. I have to take into account every edge case and I just need to test it all. On 10/12/25 8:31 PM, Jim Hall via Freedos-devel wrote: > On Sun, Oct 12, 2025 at 8:04 PM Michael Brutman via Freedos-devel > <fre...@li...> wrote: >> The multiple announcements and versions per week are difficult >> to keep track of. >> >> I would encourage you to work on the code, keep polishing it, >> testing it, documenting it, etc. Then after a few weeks make >> an announcement or ask for additional testers. > +1 > > Also, I didn't see that there was a link to 0.99.8248a because it was > a reply in a discussion. > > If you have a lot of changes happening, once a week would probably be > okay. That gives folks enough time to try out the new version (and > give feedback) before you release a new one. > > > _______________________________________________ > Freedos-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-devel |
|
From: Jim H. <jh...@fr...> - 2025-10-13 01:32:03
|
On Sun, Oct 12, 2025 at 8:04 PM Michael Brutman via Freedos-devel <fre...@li...> wrote: > > The multiple announcements and versions per week are difficult > to keep track of. > > I would encourage you to work on the code, keep polishing it, > testing it, documenting it, etc. Then after a few weeks make > an announcement or ask for additional testers. +1 Also, I didn't see that there was a link to 0.99.8248a because it was a reply in a discussion. If you have a lot of changes happening, once a week would probably be okay. That gives folks enough time to try out the new version (and give feedback) before you release a new one. |
|
From: Michael B. <mbb...@br...> - 2025-10-13 01:04:03
|
The multiple announcements and versions per week are difficult to keep track of. I would encourage you to work on the code, keep polishing it, testing it, documenting it, etc. Then after a few weeks make an announcement or ask for additional testers. |
|
From: victoria c. <sp...@jo...> - 2025-10-12 18:25:34
|
ok the release is found here https://github.com/sparky4/fdnpkg16/releases/tag/0.99.8248a sorry bout that i hope it looks ok On 10/11/25 3:02 PM, Jim Hall via Freedos-devel wrote: > Hi sparky4! > > I was going to update the news item on the website with this new > version, but I'm having trouble finding version 0.99.8248a on your > GitHub releases page: > https://github.com/sparky4/fdnpkg16/releases > > You don't label these with version numbers, so I'm not sure what > version the "massive amount of mulltipackage bug fixs in this one!" > title actually represents. The GitHub "tag" off to the side suggests > 0.99.8248, but that's not the same as 0.99.8248a in your email > announcement. > > It will help me (and others) to browse your versions in GitHub if you > label them with numbers instead of text. For example, you use these > labels for the last several releases: > https://github.com/sparky4/fdnpkg16/releases > > "massive amount of mulltipackage bug fixs in this one!" > Oct 11 > > "0.99.8246" > Oct 11 > > "fix for list local" > Oct 10 > > "fixed a bug introduced into this version" > Oct 10 > > "0.99.8244c added back the mem check feature! :D" > Oct 10 > > "fix strings up" > Oct 9 > > "translations updates" > Oct 9 > > "fixed string issues again .-. also i tried to implement > farcoreleft... failed xD" > Oct 9 > > > Based on these labels, I would assume that 0.99.8246" is the only > actual "release" on this page, and the others are probably > in-development "snapshots" but not meant as releases. > > Would you mind labeling future releases something like "version > 0.99.83" or "FDNPKG16 ver. 0.99.8301a" if they are meant as "releases" > -- and something like "snapshot (with text description)" if it's an > in-development "snapshot" that's not really meant as a release. I > think that would help me (and others like me) who are trying to find > the version you announce on email lists. That will also make it easier > for me to update the news items on the website with the right version; > since you make more than one "release" in a day, I will know what > release to link to when I update the news items. > > Thanks for all the updates! > > On Sat, Oct 11, 2025 at 12:54 PM victoria crenshaw via Freedos-devel > <fre...@li...> wrote: >> Get it here! >> https://github.com/sparky4/fdnpkg16 >> https://gitlab.com/sparky4/fdnpkg16 >> https://4ch.mooo.com/freedos/repos/1.4/html/en/net/index.html#fdnpkg16 >> >> >> i squashed alot of bugs since 0.99.8244 >> >> multi package update introduced like 50 logic bugs with the loop system. >> >> Most of the bugs is argument processing of argc. and i added lzma >> support back it compiled but i cant test it well >> >> If u see any inconsistencies with multi package manipulation or not >> being similar with single package install like fdnpkg let me know asap >> >> >> >> _______________________________________________ >> Freedos-devel mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freedos-devel > > _______________________________________________ > Freedos-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-devel |
|
From: victoria c. <sp...@jo...> - 2025-10-12 18:21:53
|
On 10/11/25 3:02 PM, Jim Hall via Freedos-devel wrote: > Hi sparky4! > > I was going to update the news item on the website with this new > version, but I'm having trouble finding version 0.99.8248a on your > GitHub releases page: > https://github.com/sparky4/fdnpkg16/releases i must of forgotten to make one let me make it! > You don't label these with version numbers, so I'm not sure what > version the "massive amount of mulltipackage bug fixs in this one!" > title actually represents. The GitHub "tag" off to the side suggests > 0.99.8248, but that's not the same as 0.99.8248a in your email > announcement. yeah it is true > > It will help me (and others) to browse your versions in GitHub if you > label them with numbers instead of text. For example, you use these > labels for the last several releases: > https://github.com/sparky4/fdnpkg16/releases cool i will do this for now > "massive amount of mulltipackage bug fixs in this one!" > Oct 11 > > "0.99.8246" > Oct 11 > > "fix for list local" > Oct 10 > > "fixed a bug introduced into this version" > Oct 10 > > "0.99.8244c added back the mem check feature! :D" > Oct 10 > > "fix strings up" > Oct 9 > > "translations updates" > Oct 9 > > "fixed string issues again .-. also i tried to implement > farcoreleft... failed xD" > Oct 9 > > > Based on these labels, I would assume that 0.99.8246" is the only > actual "release" on this page, and the others are probably > in-development "snapshots" but not meant as releases. 1 moment > > Would you mind labeling future releases something like "version > 0.99.83" or "FDNPKG16 ver. 0.99.8301a" if they are meant as "releases" > -- and something like "snapshot (with text description)" if it's an > in-development "snapshot" that's not really meant as a release. I > think that would help me (and others like me) who are trying to find > the version you announce on email lists. That will also make it easier > for me to update the news items on the website with the right version; > since you make more than one "release" in a day, I will know what > release to link to when I update the news items. > > Thanks for all the updates! cool ill make a new release on git hub from what u suggested here! :D > > On Sat, Oct 11, 2025 at 12:54 PM victoria crenshaw via Freedos-devel > <fre...@li...> wrote: >> Get it here! >> https://github.com/sparky4/fdnpkg16 >> https://gitlab.com/sparky4/fdnpkg16 >> https://4ch.mooo.com/freedos/repos/1.4/html/en/net/index.html#fdnpkg16 >> >> >> i squashed alot of bugs since 0.99.8244 >> >> multi package update introduced like 50 logic bugs with the loop system. >> >> Most of the bugs is argument processing of argc. and i added lzma >> support back it compiled but i cant test it well >> >> If u see any inconsistencies with multi package manipulation or not >> being similar with single package install like fdnpkg let me know asap >> >> >> >> _______________________________________________ >> Freedos-devel mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freedos-devel > > _______________________________________________ > Freedos-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-devel |
|
From: Jim H. <jh...@fr...> - 2025-10-11 20:02:26
|
Hi sparky4! I was going to update the news item on the website with this new version, but I'm having trouble finding version 0.99.8248a on your GitHub releases page: https://github.com/sparky4/fdnpkg16/releases You don't label these with version numbers, so I'm not sure what version the "massive amount of mulltipackage bug fixs in this one!" title actually represents. The GitHub "tag" off to the side suggests 0.99.8248, but that's not the same as 0.99.8248a in your email announcement. It will help me (and others) to browse your versions in GitHub if you label them with numbers instead of text. For example, you use these labels for the last several releases: https://github.com/sparky4/fdnpkg16/releases "massive amount of mulltipackage bug fixs in this one!" Oct 11 "0.99.8246" Oct 11 "fix for list local" Oct 10 "fixed a bug introduced into this version" Oct 10 "0.99.8244c added back the mem check feature! :D" Oct 10 "fix strings up" Oct 9 "translations updates" Oct 9 "fixed string issues again .-. also i tried to implement farcoreleft... failed xD" Oct 9 Based on these labels, I would assume that 0.99.8246" is the only actual "release" on this page, and the others are probably in-development "snapshots" but not meant as releases. Would you mind labeling future releases something like "version 0.99.83" or "FDNPKG16 ver. 0.99.8301a" if they are meant as "releases" -- and something like "snapshot (with text description)" if it's an in-development "snapshot" that's not really meant as a release. I think that would help me (and others like me) who are trying to find the version you announce on email lists. That will also make it easier for me to update the news items on the website with the right version; since you make more than one "release" in a day, I will know what release to link to when I update the news items. Thanks for all the updates! On Sat, Oct 11, 2025 at 12:54 PM victoria crenshaw via Freedos-devel <fre...@li...> wrote: > > Get it here! > https://github.com/sparky4/fdnpkg16 > https://gitlab.com/sparky4/fdnpkg16 > https://4ch.mooo.com/freedos/repos/1.4/html/en/net/index.html#fdnpkg16 > > > i squashed alot of bugs since 0.99.8244 > > multi package update introduced like 50 logic bugs with the loop system. > > Most of the bugs is argument processing of argc. and i added lzma > support back it compiled but i cant test it well > > If u see any inconsistencies with multi package manipulation or not > being similar with single package install like fdnpkg let me know asap > > > > _______________________________________________ > Freedos-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-devel |
|
From: victoria c. <sp...@jo...> - 2025-10-11 17:54:14
|
Get it here! https://github.com/sparky4/fdnpkg16 https://gitlab.com/sparky4/fdnpkg16 https://4ch.mooo.com/freedos/repos/1.4/html/en/net/index.html#fdnpkg16 i squashed alot of bugs since 0.99.8244 multi package update introduced like 50 logic bugs with the loop system. Most of the bugs is argument processing of argc. and i added lzma support back it compiled but i cant test it well If u see any inconsistencies with multi package manipulation or not being similar with single package install like fdnpkg let me know asap |
|
From: Jim H. <jh...@fr...> - 2025-10-10 14:09:44
|
If you program with NASM, you will be interested to know that NASM 3.00 was just released: Website: https://www.nasm.us/ Documentation: https://www.nasm.us/docs/3.00/ Download from: https://www.nasm.us/pub/nasm/releasebuilds/3.00/ I've also mirrored this release at Ibiblio: https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/3.00/ The full list of changes is in the release notes. Here are a few highlights: https://www.nasm.us/docs/3.00/nasmac.html Add new preprocessor functions: %b2hs(), %chr(), %depend(), %find(), %findi(), %hs2b(), %null(), %ord(), %pathsearch(), and %realpath() New preprocessor directive %note to insert a note in the list file New preprocessor directive %iffile and function %isfile() to test for the existence of a file New preprocessor directive %ifdirective to test for the existence of a preprocessor directive Many documentation improvements Note that using $ as a prefix for hexadecimal numbers has been deprecated, and will now issue a warning. |
|
From: Bret J. <bre...@ju...> - 2025-10-10 00:53:26
|
> hi Jerome, > this story goes deeper, e.g. country and country.sys eher there is no country > number for estonia, latvia, lithuania, maybe some former yugoslavian countries. > let us talk about this next week. The problem is FAR deeper than even you're addressing here. In the DOS world, COUNTRY (such as COUNTRY.SYS) doesn't really have anything to do with a Country in the geographical/political sense. Country in DOS is related to alphabetic sorting, number formatting, date/time formatting, etc. It's only very loosely and indirectly related to geography, and Microsoft probably should have called it something other than "Country" back in the early days of DOS. I'm guessing if they had do do it all over again knowing what they do now MS probably wouldn't have called it a "Country". Similarly, Language (including the LANG environment variable) is a relatively new development in DOS and didn't exist at all in the early days. I think MS had a few DOS programs with alternative language translations, but I'm not sure how they decided which ones to use at what times. It was probably some subset or combination of Code Page, Country, and Keyboard Layout, but I'm not sure. Although Country, Language, Code Page, and Keyboard Layout are all inter-related, they are NOT the same thing and should not be conflated or confused. E.g., there seems to be some conflation between Languages and Countries going on. In addition there are now ISO standards for both language and country codes that didn't exist at all back in the early days of DOS, and in some cases even conflict with early DOS usages. There also seems to be some confusion between Languages and Dialects, such as the instance brought up earlier of British and American English where the _overall_ language is fundamentally the same but individual words can have completely different, or at least ambiguous, meanings. You can also throw other English-speaking countries (such as Australia) into the mix and the situation gets even worse. While they are certainly different Countries (at least geographically/politically), I'm not sure I would classify the US, UK, and Australian versions of English as completely different Languages (though some people might disagree with me). The same thing (different Dialects of the same Language) can even happen in local regions (or even families) within the same country. I'm not proposing a solution -- I think it's far too complicated and we're way too far down the road to fix something that I think MS did a bad job of designing way back when and we're still living with the consequences of the mess they left. I just don't want to go down a road where' we're actually worse off than we are now (because I think it's already pretty bad, or at least pretty confusing). |
|
From: victoria c. <sp...@jo...> - 2025-10-09 15:13:42
|
ok i paused development for a bit until i get feed back from someone about features or translations most of the small "updates" i been doing is translation formatting. and machine translating a few things I genuinely dont see any issues right now but only with some translations like Spanish... in fact let me fix that real quick |