Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop

[Jim Hall via Freedos-devel]

roytam wrote:
[..]
> and as discussion in
> http://www.bttr-software.de/forum/board_entry.php?id=21061, FreeDOS
> can boot on Book8088 once FreeDOS' LBA support is disabled. This may
> because of XT-IDE BIOS and/or Xi8088 BIOS handling when Int 13h,AH=41h
> running twice by FreeDOS kernel.
>


That matches what Eric shared at this morning's virtual get-together
(and reshared in the "recap" thread) that there's a bug in XT-IDE's
firmware where if you check for LBA more than once, it hangs.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop

[roytam--- via Freedos-devel]

perditionc--- via Freedos-devel  wrote:
>
> On Sun, Feb 4, 2024, 7:39 AM roytam--- via Freedos-devel 
>  wrote:
>>
>> Hello,
>>
>> perditionc--- via Freedos-devel  wrote:
>> >
>> > On Sun, Feb 4, 2024, 6:32 AM Eric Auer via Freedos-devel 
>> >  wrote:
>> >>
>> >>
>> >> Hi Jim,
>> >>
>> >> > I'm glad you're bringing this conversation back to freedos-devel ..
>> >> > because this is a good place to discuss FreeDOS things.
>> >>
>> >> In related news, the dosemu2 people also find the problem interesting.
>> >>
>> ...
>>
>> You don't need a real Book8088 for testing. 86Box "Xi8088" machine
>> with XT-IDE(CHS=1006/16/63) can reproduce this bug.
>>
>> >
>> > Jeremy
>> >
>>
>> Regards,
>> Roy
>
>
> Thank you.  I will try that out, I need to test the cpu check logic anyway.   
> (It was more my excuse to get one :-) as my 808x hasn't been powered on in so 
> long I'm afraid it might need some work beyond the hard drive which died long 
> ago)

and as discussion in
http://www.bttr-software.de/forum/board_entry.php?id=21061, FreeDOS
can boot on Book8088 once FreeDOS' LBA support is disabled. This may
because of XT-IDE BIOS and/or Xi8088 BIOS handling when Int 13h,AH=41h
running twice by FreeDOS kernel.

>
> Jeremy
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Gregory Pietsch via Freedos-devel]

Believe me, I've had a few headaches over the years regarding NLS. This led to 
the myriad of ways to do NLS in Edlin. Anyway, all the strings that would need 
to be translated are #defines in msgs.h, and I included a simple filter program 
to generate msgs.h files from the NLS files. I don't know if NLS was done the 
right way from the start (POSIX sus4, anyone?) but you shouldn't have to put a 
hundred FreeDOS programmers into a room and get 101 ways of doing NLS in a 
program.

Edlin is supposed to be TINY, and I've turned into the guardian of bloat. I've 
tried to make it so that someone who is not in the priesthood could easily 
compile the thing with the right compiler, and I've tried to be broad about the 
compiler to use. Instead of tight 80x86 assembler, I made it portable as hell. 
It runs on Linux! It runs on Windows! It runs on Homer Simpson's brain! 
(Maybe...) Someone compiled it on a smartphone! Now I'm ranting

Gregory

> On 02/04/2024 2:55 PM EST Ralf Quint via Freedos-devel 
>  wrote:
> 
>  
> On 2/4/2024 11:32 AM, Jerome Shidel via Freedos-devel wrote:
> > Hi,
> >
> >> On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel 
> >>  wrote:
> >>
> >> On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:
> >>> I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
> >>> problem. You don't have to know a lick of C to recompile it.
> >> Well, part of the problem is that in order to recompile, you need to have 
> >> the compiler (toolchain) installed, which isn't necessarily easy for a 
> >> non-programmer.
> >>
> >>
> >> Ralf
> > I have occasionally compiled edlin to provide an updated version for 
> > FreeDOS.
> >
> > As compile from source goes, EDLIN is not that bad. If I recall correctly, 
> > It just needs our Watcom-C to compile. Plus a little knowledge on options 
> > and such things.
> >
> > In general, it is extremely cumbersome to acquire all the exact required 
> > pieces to accomplish. An fairly often after spending a few hours on trying 
> > to get a successful compile, I will end up giving up. Therefore, I do that 
> > very rarely anymore for almost anything.
> The problem with the whole NLS/i18n thing is that it is not only done 
> with just translating some text extruded from the sources. And 
> recompiling some programs which don't lend themselves well to the whole 
> "kitten" shebang. It would require a lot of testing, which needs to be 
> done by someone with those native language skills (plus some technical 
> knowledge what it is all about). A lot of command line tools might be 
> fairly easy to do, but for anything that is using a more formatted 
> screen output, this also requires to check where things are 
> "overflowing" (for lack of a better term right now)/misalignment...
> And we have a very limited number of people that would have ALL the 
> required skills.
> IMHO, before getting too much wound up with everything that is involved, 
> I think we need to make sure to have a proper English version, for 
> everything,
> >
> > As discussed in the online meeting, it would be nice to include dependency 
> > requirements in the package metadata. This makes me think we could possibly 
> > include the build-dependency requirements as well. Plus a per package 
> > universal build batch. That would be a lot of work and probably require 
> > frequent updating when packages change.
> I see that there would be some effort initially to add that info, but 
> seriously, how much are dependencies as such changing for any given 
> program after that?
> >
> > But on the other hand, it would be very nice if all programs (excluding 
> > those made with commercial compilers like Turbo Pascal) could be built from 
> > source simply by installing the required build packages.
> >
> > This leads me to think, maybe we should go back to the old days when 
> > sources were in their own separate package and not included in the binaries 
> > package.
> >
> That was a move that I have never understood in the first place, as the 
> vast majority of people downloading FreeDOS are likely just interested 
> in getting it running, rather than doing any development. Specially if 
> things aren't as simple anymore as they (mostly) used to be in the days 
> of DOS, too many Linuxisms have crept in, which makes it so much harder 
> for people that are just trying to get back into DOS and haven't done 
> anything programming wise for the last 20-30 years, and then in things 
> like BASIC or Turbo Pascal, which are all "programma  non grata" for a 
> lot of OSS license minded folks...
> 
> 
> Ralf
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Jerome Shidel via Freedos-devel]

Ralf,

> On Feb 4, 2024, at 2:55 PM, Ralf Quint via Freedos-devel 
>  wrote:
> 
> On 2/4/2024 11:32 AM, Jerome Shidel via Freedos-devel wrote:
>> Hi,
>> 
>>> On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel 
>>>  wrote:
>>> 
>>> On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:
 I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
 problem. You don't have to know a lick of C to recompile it.
>>> Well, part of the problem is that in order to recompile, you need to have 
>>> the compiler (toolchain) installed, which isn't necessarily easy for a 
>>> non-programmer.
>>> 
>>> 
>>> Ralf
>> I have occasionally compiled edlin to provide an updated version for FreeDOS.
>> 
>> As compile from source goes, EDLIN is not that bad. If I recall correctly, 
>> It just needs our Watcom-C to compile. Plus a little knowledge on options 
>> and such things.
>> 
>> In general, it is extremely cumbersome to acquire all the exact required 
>> pieces to accomplish. An fairly often after spending a few hours on trying 
>> to get a successful compile, I will end up giving up. Therefore, I do that 
>> very rarely anymore for almost anything.
> The problem with the whole NLS/i18n thing is that it is not only done with 
> just translating some text extruded from the sources. And recompiling some 
> programs which don't lend themselves well to the whole "kitten" shebang. It 
> would require a lot of testing, which needs to be done by someone with those 
> native language skills (plus some technical knowledge what it is all about). 
> A lot of command line tools might be fairly easy to do, but for anything that 
> is using a more formatted screen output, this also requires to check where 
> things are "overflowing" (for lack of a better term right now)/misalignment…

Yup. 

> And we have a very limited number of people that would have ALL the required 
> skills.

Yup. 

> IMHO, before getting too much wound up with everything that is involved, I 
> think we need to make sure to have a proper English version, for everything,

Yup. 

>> 
>> As discussed in the online meeting, it would be nice to include dependency 
>> requirements in the package metadata. This makes me think we could possibly 
>> include the build-dependency requirements as well. Plus a per package 
>> universal build batch. That would be a lot of work and probably require 
>> frequent updating when packages change.
> I see that there would be some effort initially to add that info, but 
> seriously, how much are dependencies as such changing for any given program 
> after that?

For small projects, not usually much changes or very often. 

On the other hand for large projects, sometimes different libraries come and 
go. But generally, the problem with these are based on specific versions of 
libraries. Or, sub-dependency libraries and their versions. 

However, I only extremely rarely make the exception and compile projects we 
distribute from source. So, the problem may not be as bad as I suspect.

>> 
>> But on the other hand, it would be very nice if all programs (excluding 
>> those made with commercial compilers like Turbo Pascal) could be built from 
>> source simply by installing the required build packages.
>> 
>> This leads me to think, maybe we should go back to the old days when sources 
>> were in their own separate package and not included in the binaries package.
>> 
> That was a move that I have never understood in the first place, as the vast 
> majority of people downloading FreeDOS are likely just interested in getting 
> it running, rather than doing any development. Specially if things aren't as 
> simple anymore as they (mostly) used to be in the days of DOS, too many 
> Linuxisms have crept in, which makes it so much harder for people that are 
> just trying to get back into DOS and haven't done anything programming wise 
> for the last 20-30 years, and then in things like BASIC or Turbo Pascal, 
> which are all "programma  non grata" for a lot of OSS license minded folks…

Furthermore, if the packages were split back into BIN and SRCS, we could 
provide the sources on a separate media. This could possibly cut the size of 
the release media in half. Maybe even alleviate the need for a BonusCD. 
Possibly just the LiveCD, LegacyCD and a SourcesCD. 

Change back to the split packages would require some tweaking to the installer 
and RBE. Probably FDIMPLES as well. Nothing to difficult. 

The online package repo management software used on ibiblio and fd.lod.bz is 
not designed for it. But, those places could just keep using the combined 
packages until I get around to making the next version of the repository 
management utilities. 


> Ralf

:-)

Jerome


> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net 
> 
> https://lists.sourceforge.net/lists/listinfo/freedos-devel 
> 

[Freedos-devel] HELP.BAT and other OS Batch files

[Jerome Shidel via Freedos-devel]

Hi Jim,

Per our discussion during the online meeting, if you are interested in updating 
some of the included connivence batch files (like HELP.BAT). Their home is at 
GitLab at in the FDHELPER project. https://gitlab.com/FreeDOS/base/fdhelper 


Some of those batch programs (WELCOME and CDROM) support NLS. Eventually, the 
others should be updated with NLS support as well. Anyway, simple changes to 
that text should be pushed to the FD-NLS project so the changes don’t get 
forgotten or accidentally overwritten by old translations. 
https://github.com/shidel/fd-nls 

Side note, the SETLANG.BAT is primarily used for setting the users language for 
the Floppy Edition Installer. However, it also worked nicely to quickly change 
languages when using the LiveCD. More work still needs done with regards to 
that. Also eventually, it would be great to have it switch languages on 
installed systems as well. 

Also, there is a placeholder batch called ONELANG.BAT. I think it would be nice 
to eventual have it support removing all additional languages if the user only 
wants to retain their current language. It could be nice on systems with 
limited storage space. 

:-)

Jerome___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Ralf Quint via Freedos-devel]

On 2/4/2024 11:32 AM, Jerome Shidel via Freedos-devel wrote:

Hi,


On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel 
 wrote:

On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:

I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
problem. You don't have to know a lick of C to recompile it.

Well, part of the problem is that in order to recompile, you need to have the 
compiler (toolchain) installed, which isn't necessarily easy for a 
non-programmer.


Ralf

I have occasionally compiled edlin to provide an updated version for FreeDOS.

As compile from source goes, EDLIN is not that bad. If I recall correctly, It 
just needs our Watcom-C to compile. Plus a little knowledge on options and such 
things.

In general, it is extremely cumbersome to acquire all the exact required pieces 
to accomplish. An fairly often after spending a few hours on trying to get a 
successful compile, I will end up giving up. Therefore, I do that very rarely 
anymore for almost anything.
The problem with the whole NLS/i18n thing is that it is not only done 
with just translating some text extruded from the sources. And 
recompiling some programs which don't lend themselves well to the whole 
"kitten" shebang. It would require a lot of testing, which needs to be 
done by someone with those native language skills (plus some technical 
knowledge what it is all about). A lot of command line tools might be 
fairly easy to do, but for anything that is using a more formatted 
screen output, this also requires to check where things are 
"overflowing" (for lack of a better term right now)/misalignment...
And we have a very limited number of people that would have ALL the 
required skills.
IMHO, before getting too much wound up with everything that is involved, 
I think we need to make sure to have a proper English version, for 
everything,


As discussed in the online meeting, it would be nice to include dependency 
requirements in the package metadata. This makes me think we could possibly 
include the build-dependency requirements as well. Plus a per package universal 
build batch. That would be a lot of work and probably require frequent updating 
when packages change.
I see that there would be some effort initially to add that info, but 
seriously, how much are dependencies as such changing for any given 
program after that?


But on the other hand, it would be very nice if all programs (excluding those 
made with commercial compilers like Turbo Pascal) could be built from source 
simply by installing the required build packages.

This leads me to think, maybe we should go back to the old days when sources 
were in their own separate package and not included in the binaries package.

That was a move that I have never understood in the first place, as the 
vast majority of people downloading FreeDOS are likely just interested 
in getting it running, rather than doing any development. Specially if 
things aren't as simple anymore as they (mostly) used to be in the days 
of DOS, too many Linuxisms have crept in, which makes it so much harder 
for people that are just trying to get back into DOS and haven't done 
anything programming wise for the last 20-30 years, and then in things 
like BASIC or Turbo Pascal, which are all "programma  non grata" for a 
lot of OSS license minded folks...



Ralf



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Link for today's virtual meeting

[Ralf Quint via Freedos-devel]

On 2/4/2024 11:02 AM, Jim Hall via Freedos-devel wrote:

On Sun, Feb 4, 2024 at 12:40 PM Jerome Shidel via Freedos-devel
 wrote:

Hi Jim,

Interestingly, when you left the online meeting, it kept going at
least for a few seconds until I clicked end-call.

I don’t know if it would have kept going indefinitely.

We will have to try that next time.


That is interesting! I wonder how long it would have kept going? (My
guess: only another minute or two.) You should definitely stay on next
time to see when (if?) it kicks you off.
I think that is just an "artifact" of using a video conferencing in a 
web browser and possibly associated buffering.

1. Willi's HTML Help update. I sent another email to freedos-devel so
everyone could see this announcement. I'll also post an announcement
on the website.
I might have missed this while trying to adjust the settings in Google 
Meet, but what exactly is the problem with AMB?


2. The Book8088 problem. This was an interesting one to me. Bernd
reported that there's a bug in XT-IDE where if you check for LBA more
than once, it hangs. Folks are working on it. It would be *great* to
see follow-up discussion on this topic in freedos-devel.
The general problem that I see here is to have an environment to 
actually test this, which I think might be a bit hard if one doesn't 
actually have one of those devices...


3. Kernel updates from Jeremy. There are a few updates coming,
including Win311 compatibility. Jeremy had planned to make a release
of some kind in December, but got delayed. We were all interested in
trying out the new kernel in the next Monthly Test Build (T2403).
Jeremy plans to share an update on freedos-devel - hopefully soon -
even if it's just a "pre-release" version of the kernel.


(^_^)b

Ralf




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Jerome Shidel via Freedos-devel]

Hi, 

> On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel 
>  wrote:
> 
> On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:
>> I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
>> problem. You don't have to know a lick of C to recompile it.
> 
> Well, part of the problem is that in order to recompile, you need to have the 
> compiler (toolchain) installed, which isn't necessarily easy for a 
> non-programmer.
> 
> 
> Ralf

I have occasionally compiled edlin to provide an updated version for FreeDOS. 

As compile from source goes, EDLIN is not that bad. If I recall correctly, It 
just needs our Watcom-C to compile. Plus a little knowledge on options and such 
things. 

In general, it is extremely cumbersome to acquire all the exact required pieces 
to accomplish. An fairly often after spending a few hours on trying to get a 
successful compile, I will end up giving up. Therefore, I do that very rarely 
anymore for almost anything.

As discussed in the online meeting, it would be nice to include dependency 
requirements in the package metadata. This makes me think we could possibly 
include the build-dependency requirements as well. Plus a per package universal 
build batch. That would be a lot of work and probably require frequent updating 
when packages change. 

But on the other hand, it would be very nice if all programs (excluding those 
made with commercial compilers like Turbo Pascal) could be built from source 
simply by installing the required build packages.

This leads me to think, maybe we should go back to the old days when sources 
were in their own separate package and not included in the binaries package. 

Jerome




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Ralf Quint via Freedos-devel]

On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:

I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
problem. You don't have to know a lick of C to recompile it.


Well, part of the problem is that in order to recompile, you need to 
have the compiler (toolchain) installed, which isn't necessarily easy 
for a non-programmer.



Ralf




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Link for today's virtual meeting

[Jim Hall via Freedos-devel]

On Sun, Feb 4, 2024 at 12:40 PM Jerome Shidel via Freedos-devel
 wrote:
>
> Hi Jim,
>
> Interestingly, when you left the online meeting, it kept going at
> least for a few seconds until I clicked end-call.
>
> I don’t know if it would have kept going indefinitely.
>
> We will have to try that next time.


That is interesting! I wonder how long it would have kept going? (My
guess: only another minute or two.) You should definitely stay on next
time to see when (if?) it kicks you off.

BTW, we had a great conversation today, thanks to everyone who joined:
Willi, Eric, Jerome, Ralf, Jeremy, Bernd, and Omar. We had some
"social time" chat in there too, like learning the MAD programming
language, learning assembly, .. but mostly we focused on these
technical topics:

1. Willi's HTML Help update. I sent another email to freedos-devel so
everyone could see this announcement. I'll also post an announcement
on the website.

2. The Book8088 problem. This was an interesting one to me. Bernd
reported that there's a bug in XT-IDE where if you check for LBA more
than once, it hangs. Folks are working on it. It would be *great* to
see follow-up discussion on this topic in freedos-devel.

3. Kernel updates from Jeremy. There are a few updates coming,
including Win311 compatibility. Jeremy had planned to make a release
of some kind in December, but got delayed. We were all interested in
trying out the new kernel in the next Monthly Test Build (T2403).
Jeremy plans to share an update on freedos-devel - hopefully soon -
even if it's just a "pre-release" version of the kernel.

4. Bernd is planning some fixes to HTML Help. I'll let Bernd share
details about that here on freedos-devel.


We're planning the next FreeDOS virtual get-together for Sunday, March
10 at the usual time. Unless a technical topic comes up in early
March, the next meeting will be "social time." That's a great
opportunity to get to know other FreeDOS people as more than just an
email address.

Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Gregory Pietsch via Freedos-devel]

I tried to make Edlin portable enough so that multiple toolchains would work on 
it. I normally use Cygwin with GCC and make to compile it, but FreeDOS is a 
DOS, so I tried to make it so that multiple compilers could compile it. Forgive 
my wording here...

Anyway, tweaking config.h should take care of the differences in compilers. 
That file can also be generated through the configure script (as well as the 
makefile), but DOS wants things as simple as they can be. ;-)

The files edlin.en and msgs-en.h in the distro are the English-language 
versions of the catalog and msgs.h, respectively.

If I submitted a set of files for every language and compiler in existence, the 
politics of multiplication would come in, and I would be old and grey (or 
possibly dead from old age) before that project would be completed.

Gregory

> On 02/04/2024 1:32 PM EST Eric Auer  wrote:
> 
>  
> > I made recompiling Edlin easy for non-programmers,
> > so that shouldn't be a problem. You don't have to
> > know a lick of C to recompile it.
> 
> One would still need the toolchain, so it would
> be great if there could be somebody who already
> has it (and does know C, just in case) who would
> volunteer as the "send me your NLS updates for
> EDLIN and I will make sure an updated EDLIN zip
> will get published" person. Or, as said, a CI way.
> 
> Eric
> 
> PS: As mentioned on BTTR in the Book8088 compat thread
> (which found out that SYS CONFIG GLOBALENABLELBASUPPORT=0
> can work around some crash in XT-IDE BIOS!) even seemingly
> easy to use compiles fail in *unexpected* ways, e.g. OW
> 2.0 compiles kernels in Linux, but only 1.9 does in DOS?


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Link for today's virtual meeting

[Jerome Shidel via Freedos-devel]

Hi Jim,

Interestingly, when you left the online meeting, it kept going at least for a 
few seconds until I clicked end-call. 

I don’t know if it would have kept going indefinitely.

We will have to try that next time.

:-)

Jerome

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Eric Auer via Freedos-devel]

I made recompiling Edlin easy for non-programmers,
so that shouldn't be a problem. You don't have to
know a lick of C to recompile it.


One would still need the toolchain, so it would
be great if there could be somebody who already
has it (and does know C, just in case) who would
volunteer as the "send me your NLS updates for
EDLIN and I will make sure an updated EDLIN zip
will get published" person. Or, as said, a CI way.

Eric

PS: As mentioned on BTTR in the Book8088 compat thread
(which found out that SYS CONFIG GLOBALENABLELBASUPPORT=0
can work around some crash in XT-IDE BIOS!) even seemingly
easy to use compiles fail in *unexpected* ways, e.g. OW
2.0 compiles kernels in Linux, but only 1.9 does in DOS?




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Gregory Pietsch via Freedos-devel]

I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
problem. You don't have to know a lick of C to recompile it.

Gregory

> On 02/04/2024 12:59 PM EST Eric Auer via Freedos-devel 
>  wrote:
> 
>  
> Hi!
> 
> > Willi Spiegl said in the meeting that there is no NLS in Edlin. I beg to 
> > differ!
> 
> As with the HTMLHELP versus AMB issue, the problem, as far as
> I have understood Willi, is the lack of a process, possibly
> an automated pipeline, which will take updated translations
> and spread them to the right places. As a non-programmer, he
> would not recompile EDLIN to submit updated translations, so
> we have to figure out whom and how to give the files so the
> updates get published to the right, easy to use places :-)
> 
> Eric
> 
> PS: The same probably applies to CTMOUSE and similar tools
> with compile time translations. Could be put into continuous
> integration pipelines, but then updates are rather rare here.
> 
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Eric Auer via Freedos-devel]

Hi!


Willi Spiegl said in the meeting that there is no NLS in Edlin. I beg to differ!


As with the HTMLHELP versus AMB issue, the problem, as far as
I have understood Willi, is the lack of a process, possibly
an automated pipeline, which will take updated translations
and spread them to the right places. As a non-programmer, he
would not recompile EDLIN to submit updated translations, so
we have to figure out whom and how to give the files so the
updates get published to the right, easy to use places :-)

Eric

PS: The same probably applies to CTMOUSE and similar tools
with compile time translations. Could be put into continuous
integration pipelines, but then updates are rather rare here.




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] NLS in Edlin

[Gregory Pietsch via Freedos-devel]

Willi Spiegl said in the meeting that there is no NLS in Edlin. I beg to differ!
 
There are two different ways of supporting NLS in Edlin. The first (easy) way 
is that in the source code, all the message strings are in a file called 
msgs.h, so by translating the strings, putting the translations in a msgs.h 
file, and recompiling, you have a version of Edlin with translated strings. 
When I discovered how the rest of FreeDOS was doing NLS, I put a small program 
in the Edlin distribution called kit2msgs that translated a message catalog 
into a msgs.h file with a minimum of fuss. So, to translate all the messages to 
German, just download edlin.de from Github, add the three new missing messages, 
use kit2msgs to translate that into a msgs.h file, and compile! WAY TOO EASY! 
 
The second way was to read the message catalogs in real time. There's a file 
called msgscats.h in the Edlin source that uses catgets to get the messages, so 
using that as msgs.h and compiling in catgets.c should also work. This is a bag 
on the side of Edlin, and to keep Edlin as small as possible, I don't recommend 
this way, but it's doable. This needs more debugging, though. I tried to write 
a version of catgets that follows the POSIX specifications and uses the same 
format of files as FreeDOS and fits in with the string functionality that the 
rest of Edlin uses, but I could use some feedback.
 
Hopefully this clarifies things.
 
Gregory (not George) Pietsch___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Re: Updated HTML Help

[Wilhelm Spiegl via Freedos-devel]

 
 go to www.bootablecd.de, click on freedos-hilfe and you can download it.--Diese Nachricht wurde von meinem Android Mobiltelefon mit mail.com Mail gesendet.Am 04.02.24, 18:52 schrieb Jim Hall via Freedos-devel :

  One question I have is: is there a zip file where I can download all
   of HTML Help at once, to view on my local computer? I checked on your
   website starting at
   https://www.bootablecd.de/FreeDOS-Internet-version/help110/
   and I couldn't see a link to a zip file.
   
   
   
   On Sun, Feb 4, 2024 at 11:34 AM Jim Hall  wrote:
   >
   > I didn't see Willi's email to freedos-devel because it was part of an
   > unrelated topic, so I am re-sharing his email under a new thread to
   > raise visibility.
   >
   > Willi wrote:
   > > As english help is completed now, i only have to run final things to reduce size and to look for bugs etc. It would be great if the fd community could REALLY check it.
   > >
   > > www.bootablecd.de/FreeDOS-Internet-version/help110/en/index.htm
   > >
   > > Too avoid at least one bad comment the fish is no longer in blue colour but in grey.
   > > It will not be in htmlhelp or amb.
   > > Could someone PLEASE PLEASE
   > > check if the legal comments are correct?
   > > I simple overtook them. What do I have to modify?
   > > Is everything else correct?
   > > I needed two years to rewrite everything from scratch and have no time to write changes every week from now on as this is the base for at least FOUR other languages.
   > >
   > > And now the bad news:
   > > Mateusz is no longer willing to transform the htm files to amb. I can understand him.
   > > As I cannot program, there are several ways to handle this:
   > > - one of the group writes a checking and transformation tool htm to amb, I can try to ask Mateusz if he gives out the tool he used till now,
   > > - as htmlhelp.exe
   > > Works very good now, we only use htmlhelp and avoid double work
   > > - I will not rewrite hundreds of files to amb manually, this in 5 languages, please keep in mind that we have more than 350 files * 5 languages!
   > > This would need some years
   > > - any other idea?
   
   
   ___
   Freedos-devel mailing list
   Freedos-devel@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/freedos-devel
   
 


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Updated HTML Help

[Jim Hall via Freedos-devel]

One question I have is: is there a zip file where I can download all
of HTML Help at once, to view on my local computer? I checked on your
website starting at
https://www.bootablecd.de/FreeDOS-Internet-version/help110/
and I couldn't see a link to a zip file.



On Sun, Feb 4, 2024 at 11:34 AM Jim Hall  wrote:
>
> I didn't see Willi's email to freedos-devel because it was part of an
> unrelated topic, so I am re-sharing his email under a new thread to
> raise visibility.
>
> Willi wrote:
> > As english help is completed now, i only have to run final things to reduce 
> > size and to look for bugs etc. It would be great if the fd community could 
> > REALLY check it.
> >
> > www.bootablecd.de/FreeDOS-Internet-version/help110/en/index.htm
> >
> > Too avoid at least one bad comment the fish is no longer in blue colour but 
> > in grey.
> > It will not be in htmlhelp or amb.
> > Could someone PLEASE PLEASE
> > check if the legal comments are correct?
> > I simple overtook them. What do I have to modify?
> > Is everything else correct?
> > I needed two years to rewrite everything from scratch and have no time to 
> > write changes every week from now on as this is the base for at least FOUR 
> > other languages.
> >
> > And now the bad news:
> > Mateusz is no longer willing to transform the htm files to amb. I can 
> > understand him.
> > As I cannot program, there are several ways to handle this:
> > - one of the group writes a checking and transformation tool htm to amb, I 
> > can try to ask Mateusz if he gives out the tool he used till now,
> > - as htmlhelp.exe
> > Works very good now, we only use htmlhelp and avoid double work
> > - I will not rewrite hundreds of files to amb manually, this in 5 
> > languages, please keep in mind that we have more than 350 files * 5 
> > languages!
> > This would need some years
> > - any other idea?


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Updated HTML Help

[Jim Hall via Freedos-devel]

I didn't see Willi's email to freedos-devel because it was part of an
unrelated topic, so I am re-sharing his email under a new thread to
raise visibility.

Willi wrote:
> As english help is completed now, i only have to run final things to reduce 
> size and to look for bugs etc. It would be great if the fd community could 
> REALLY check it.
>
> www.bootablecd.de/FreeDOS-Internet-version/help110/en/index.htm
>
> Too avoid at least one bad comment the fish is no longer in blue colour but 
> in grey.
> It will not be in htmlhelp or amb.
> Could someone PLEASE PLEASE
> check if the legal comments are correct?
> I simple overtook them. What do I have to modify?
> Is everything else correct?
> I needed two years to rewrite everything from scratch and have no time to 
> write changes every week from now on as this is the base for at least FOUR 
> other languages.
>
> And now the bad news:
> Mateusz is no longer willing to transform the htm files to amb. I can 
> understand him.
> As I cannot program, there are several ways to handle this:
> - one of the group writes a checking and transformation tool htm to amb, I 
> can try to ask Mateusz if he gives out the tool he used till now,
> - as htmlhelp.exe
> Works very good now, we only use htmlhelp and avoid double work
> - I will not rewrite hundreds of files to amb manually, this in 5 languages, 
> please keep in mind that we have more than 350 files * 5 languages!
> This would need some years
> - any other idea?


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Link for today's virtual meeting

[Jim Hall via Freedos-devel]

FreeDOS virtual get-together (technical)

Google Meet joining info

Video call link:

https://meet.google.com/kca-qufs-api


I'll see you there in fifteen minutes!


Or dial: +1 515-318-5132 PIN: 587 730 560#


More phone numbers: https://tel.meet/kca-qufs-api?pin=1068170768202
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Virtual get-together?

[Gregory Pietsch via Freedos-devel]

Isn't there a virtual get-together happening now?___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Link for today's virtual meeting

[Jim Hall via Freedos-devel]

Well, that email didn't get sent out on time ("fifteen minutes") ...
sorry for the delay. Meeting is starting now. :-)

On Sun, Feb 4, 2024 at 10:46 AM Jim Hall  wrote:
>
> FreeDOS virtual get-together (technical)
>
> Google Meet joining info
>
> Video call link:
>
> https://meet.google.com/kca-qufs-api
>
>
> I'll see you there in fifteen minutes!
>
>
> Or dial: +1 515-318-5132 PIN: 587 730 560#
>
>
> More phone numbers: https://tel.meet/kca-qufs-api?pin=1068170768202


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop

[perditionc--- via Freedos-devel]

On Sun, Feb 4, 2024, 7:39 AM roytam--- via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

> Hello,
>
> perditionc--- via Freedos-devel 
> wrote:
> >
> > On Sun, Feb 4, 2024, 6:32 AM Eric Auer via Freedos-devel <
> freedos-devel@lists.sourceforge.net> wrote:
> >>
> >>
> >> Hi Jim,
> >>
> >> > I'm glad you're bringing this conversation back to freedos-devel ..
> >> > because this is a good place to discuss FreeDOS things.
> >>
> >> In related news, the dosemu2 people also find the problem interesting.
> >>
> ...
>
> You don't need a real Book8088 for testing. 86Box "Xi8088" machine
> with XT-IDE(CHS=1006/16/63) can reproduce this bug.
>
> >
> > Jeremy
> >
>
> Regards,
> Roy
>

Thank you.  I will try that out, I need to test the cpu check logic
anyway.   (It was more my excuse to get one :-) as my 808x hasn't been
powered on in so long I'm afraid it might need some work beyond the hard
drive which died long ago)

Jeremy

>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop

[roytam--- via Freedos-devel]

Hello,

perditionc--- via Freedos-devel  wrote:
>
> On Sun, Feb 4, 2024, 6:32 AM Eric Auer via Freedos-devel 
>  wrote:
>>
>>
>> Hi Jim,
>>
>> > I'm glad you're bringing this conversation back to freedos-devel ..
>> > because this is a good place to discuss FreeDOS things.
>>
>> In related news, the dosemu2 people also find the problem interesting.
>>
>> Their discussion mentions that FDPP, a port of the FreeDOS kernel,
>>
>> https://github.com/dosemu2/fdpp
>>
>> fixes plenty of issues listed in our kernel bug lists. So maybe
>> somebody feels like backporting those to FreeDOS. However, as far
>> as I remember, the diff is huge, nothing easily cherry-picked.
>>
>> Regards, Eric
>
>
>
> FDPP is a great project and has done a wonderful job of helping when porting 
> fixes to fd kernel.sys.  If I had more time I'd love to be able to help there 
> more as I see it as the future for DOS as more and more computers are UEFI 
> only.  I ordered a book8088 (hopefully) so i can test directly, but coming 
> from China so at least 2 months before delivery.  Based on what I've read it 
> sounds like the drive is booting using CHS and the disk layout doesn't match 
> what the kernel thinks it is.  That said, that specific spot is where boot 
> time memory corruption usually is noticed and anything the kernel did up to 
> then could be the culprit.   There has been several fixes to the startup 
> (boot code and initialization) that may or may not be related.   (I had hoped 
> to publish an updated kernel over Christmas but that didn't happen because I 
> didn't get all the changes and testing I would like done.  I hope to put out 
> an updated kernel for testing next weekend.)

You don't need a real Book8088 for testing. 86Box "Xi8088" machine
with XT-IDE(CHS=1006/16/63) can reproduce this bug.

>
> Jeremy
>

Regards,
Roy


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop

[perditionc--- via Freedos-devel]

On Sun, Feb 4, 2024, 6:32 AM Eric Auer via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:

>
> Hi Jim,
>
> > I'm glad you're bringing this conversation back to freedos-devel ..
> > because this is a good place to discuss FreeDOS things.
>
> In related news, the dosemu2 people also find the problem interesting.
>
> Their discussion mentions that FDPP, a port of the FreeDOS kernel,
>
> https://github.com/dosemu2/fdpp
>
> fixes plenty of issues listed in our kernel bug lists. So maybe
> somebody feels like backporting those to FreeDOS. However, as far
> as I remember, the diff is huge, nothing easily cherry-picked.
>
> Regards, Eric
>


FDPP is a great project and has done a wonderful job of helping when
porting fixes to fd kernel.sys.  If I had more time I'd love to be able to
help there more as I see it as the future for DOS as more and more
computers are UEFI only.  I ordered a book8088 (hopefully) so i can test
directly, but coming from China so at least 2 months before delivery.
Based on what I've read it sounds like the drive is booting using CHS and
the disk layout doesn't match what the kernel thinks it is.  That said,
that specific spot is where boot time memory corruption usually is noticed
and anything the kernel did up to then could be the culprit.   There has
been several fixes to the startup (boot code and initialization) that may
or may not be related.   (I had hoped to publish an updated kernel over
Christmas but that didn't happen because I didn't get all the changes and
testing I would like done.  I hope to put out an updated kernel for testing
next weekend.)

Jeremy

>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Problem booting FreeDOS on Book8088 PC-XT laptop

[Eric Auer via Freedos-devel]

Hi Jim,


I'm glad you're bringing this conversation back to freedos-devel ..
because this is a good place to discuss FreeDOS things.


In related news, the dosemu2 people also find the problem interesting.

Their discussion mentions that FDPP, a port of the FreeDOS kernel,

https://github.com/dosemu2/fdpp

fixes plenty of issues listed in our kernel bug lists. So maybe
somebody feels like backporting those to FreeDOS. However, as far
as I remember, the diff is huge, nothing easily cherry-picked.

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel