On Wed, Jul 28, 2021 at 7:15 AM Eric Auer wrote:
>
> COUNTRY=... and COUNTRY.SYS are not undocumented, but your
> choice of words hints at another idea: Do you suggest to
> introduce a TSR to handle string and key translations, to
> be used by FreeDOS apps? I think this would not save enough
>
Jerome Shidel wrote:
> >> At present, only I update the "shipping packages”.
> >
> > On Jul 29, 2021, at 10:16 AM, Eric Auer wrote:
> > Would it help you to have volunteers for the version checks?
>
On Thu, Jul 29, 2021 at 1:01 PM Jerome Shidel wrote:
>
> Version checking might help a little,
Hi Tom,
>> Jack has commented on the topic:
> it would be cool to have his comment forwarded to this list, not only
> a summarized version of it (as far as you understand and think is
> important).
Sure, here is the original comment, after checking back with Jack.
Note that I had put that "64
> THe last major item is documentation, which in my case is
> PRTSCR.DOC. This is currently a 60+ page document which would need
> to be completely translated to all the other languages.
in that case you should translate the documentation first to something
people might read. people might read
On Thu, 29 Jul 2021 21:46:32 +0100
Andrew Bird via Freedos-devel wrote:
> Hi Robert,
>
> On Thu, 29 Jul 2021 21:21:25 +0200
> Robert Riebisch wrote:
>
> > Hi Jim,
> >
> > > What are the blocking issues or bugs in FreeDOS 1.3 RC4? (What remains
> > > to be updated or fixed from RC4?)
>
On 7/27/2021 9:58 PM, Bret Johnson wrote:
i) NLS support: Is there anybody who can tell me if all DOS commands
support [J(a)|Nein] or [O(ui)|N(on)] etc. instead of [Y(es)|N(o)]? If
not, they should do it. As a translator you never know what to do.
That is rather one of the easier parts to
Hi Robert,
On Thu, 29 Jul 2021 21:21:25 +0200
Robert Riebisch wrote:
> Hi Jim,
>
> > What are the blocking issues or bugs in FreeDOS 1.3 RC4? (What remains
> > to be updated or fixed from RC4?)
>
> This COUNTRY.SYS issue is still not fixed after 1.5 years, although I
> provided a patch to
> THe last major item is documentation, which in my case is
> PRTSCR.DOC. This is currently a 60+ page document which would need
> to be completely translated to all the other languages.
in that case you should translate the documentation first to something
people might read. people might read
Hallo Herr Eric Auer,
am Donnerstag, 29. Juli 2021 um 20:06 schrieben Sie:
> Hi Bret,
>>> any idea how reliable/wide distributed this is?
>> It seems to be fairly widely distributed. I just tested in a few
>> places. It's present in an old HP laptop (I think it's about 7 years
>> old now).
Hi Jim,
> What are the blocking issues or bugs in FreeDOS 1.3 RC4? (What remains
> to be updated or fixed from RC4?)
This COUNTRY.SYS issue is still not fixed after 1.5 years, although I
provided a patch to the list
You're obviously more familiar with what happens with non-English users than I
am, so we'll use your recommendations and not worry about option-letters or
documentation, at least for now. But I will still need to decide on how to
compile and distribute things (separate executables, a single
On Thu, 29 Jul 2021, thraex wrote:
There's a saying in French, something like "The best is the enemy of
good".
As "Perfect is the enemy of good enough", it is almost a mantra in my
circles.
-uso.
___
Freedos-devel mailing list
Hi Bret,
>> any idea how reliable/wide distributed this is?
> It seems to be fairly widely distributed. I just tested in a few
> places. It's present in an old HP laptop (I think it's about 7 years
> old now). It's also present in VMWare Player and QEMU, but not in
> DOSBox-X.
> I also
On 29.07.2021 17:44, Bret Johnson wrote:
> While it should be relatively easy to write this output in another
Indeed, looks like fairly doable :)
> language, the options themselves are mnemonic to make it easier to
> remember them (which is why I have some words capitalized in the
>
Hi Eric,
> On Jul 29, 2021, at 10:16 AM, Eric Auer wrote:
> [..]
> Whether you want to spend 10 of your precious 640 kB to
> speed up floppy I/O depends on whether you use floppies.
Not the only reason.. But, it is one of the reasons it is not
run automatically in the installed systems config
> DOS programs with source code? They include a free software
> license (as > in freedom)? You have your translator for
> French and Turkish. I can do the l10n if you do the i18n
> part :-)
Well, thanks for volunteering, but what I actually have in mind may be far more
than you're willing to
Hi Jerome,
> I never said performance was not important. Only, there are more
> important things for the installer that come first. Among those
> are things like stability, portability, flexibility and others.
> Improving performance is near or at the bottom of the list.
I would definitely not
> any idea how reliable/wide distributed this is?
It seems to be fairly widely distributed. I just tested in a few places. It's
present in an old HP laptop (I think it's about 7 years old now). It's also
present in VMWare Player and QEMU, but not in DOSBox-X.
I also have it implemented in
On Thu, Jul 29, 2021, 9:02 AM tom ehlert wrote:
> with the changes below the kernel no longer splits disk transfers
> on disks that report via int13/48 'DMA boundary errors are handled
> transparently'
>
> ...
>
>
> changes:
>
>
with the changes below the kernel no longer splits disk transfers
on disks that report via int13/48 'DMA boundary errors are handled
transparently'
VirtualBox does not support DMA boundary crossing
VMWarePlayer does, and
COPY c:\KERNEL.SYS c:\BLA
results in
>> there is no INT 13nwith a large (32 bit) address.
>INT 13 can actually handle 64-bit addresses, both for LBA sector numbers and
>memory addresses. Refer to INT 13.4x in RBIL.
>From DOS, though, you probably wouldn't want to use 64-bit flat memory
>addresses, but 64-bit LBA numbers are
21 matches
Mail list logo
