On 13/10/2021 21:41, E. Auer wrote:
I would not call KSSF experimental, I would
just call it rarely used, because most users
do have XMS drivers loaded :-)
The kswap documentation starts with exactly these words:
"This technique is an experimental implementation (...)"
Then, the documentation
Hi! While this has nothing to do with MKEYB,
Tom is absolutely right about command.com:
The more common version of FreeCOM uses XMS
to swap, which is faster and available on
almost every computer of 2021 FreeDOS fans.
But there also is the alternate KSSF style
swapping without XMS, which works
On 13/10/2021 11:49, tom ehlert wrote:
I'm 100% certain that MSDOS didn't generate € characters in any
codepage. this should end the story of €'s.
As explained by others numerous times, the display-talks-to-keyb
mechanism is much wider than the one euro symbol.
1'st: 'problems' is the plura
Hallo Herr Mateusz Viste,
am Mittwoch, 13. Oktober 2021 um 09:15 schrieben Sie:
> On 12/10/2021 22:49, E. Auer wrote:
>> So at the risk of repeating the obvious: While it is possible to
>> construct some problems to justify your desired powerful solution,
>> this feels extremely over-designed fro
On 12/10/2021 22:49, E. Auer wrote:
So at the risk of repeating the obvious: While it is possible to
construct some problems to justify your desired powerful solution,
this feels extremely over-designed from my view as Non-US DOS user.
As far as I understand, this is not about designing some ne
Hi Bret,
When you don't like the message, you shoot the messenger? What we're
talking about here is a much larger issue than the Euro symbol -- the
Euro symbol is just a specific example we can use to discuss the
larger issue.
I disagree. It is not unusual that text displays with weird char
> how would MKEYB detect that code point 213 represents dotless i or
> €, or what the correct code point for € is in the new selected
> codepage? and how about äÄáàâÁÀÂ?
The same way it knows that Code Point 213 is the Euro symbol in Code Page 858
-- by the programmer (you) doing the research and
>> under
>> what circumstances this is relevant so we can reproduce the problem
>> and it's solution.
> We've already showed you the problem and how to fix it. With
> MKEYB, the Euro character is not generated correctly unless the Code
> Page is one where the Euro symbol is ASCII 213. This is t
> Only highly desirable to those who don't use screen readers.
>
> Using a graphical mode but simulating a text mode would not work for
> anyone using a screen reader, since there's no possible way for the
> screen reader to "read" the graphical screen.
Actually, there is a way. I've never used a
On 10/11/2021 3:43 PM, Aitor Santamaría wrote:
By definition, anything above 127 is not ASCII, so it will depend
on the codepage. Still, it is extremely rare that people use more
than one codepage on the same system AND have identical characters
with different byte values depending
On Mon, 11 Oct 2021 at 22:25, Aitor Santamaría wrote:
>
> Yeah, good to clarify. It does work (with either FD-KEYB or MKEYB).
>
> The question in discussion here is: if you later want to change to, say,
> codepage 850:
> (a) with FD-KEYB, you issue KEYB UK,850,,C:\DOS\KEYBOARD.SYS (no reboot)
>
Hi,
On Mon, 11 Oct 2021 at 22:18, Liam Proven wrote:
> A question:
>
> Does the old MS-style
>
> [
> [CONFIG.SYS]
>
> country=044,437,c:\dos\country.sys
>
> [AUTOEXEC.BAT]
>
> keyb uk,437,c:\dos\keyboard.sys
> ]
>
> ... config still work? If not, would it work if the files were copied
> from MS-
On Mon, 11 Oct 2021 at 21:19, E. Auer wrote:
>
> By definition, anything above 127 is not ASCII, so it will depend
> on the codepage. Still, it is extremely rare that people use more
> than one codepage on the same system AND have identical characters
> with different byte values depending on whic
> send a keyboard code �
That doesn't always work work. Let me use a Star Trek analogy (I hope most
people can relate to this).
Let's say someone in the Enterprise wants to get down to a planet that the Star
Ship is circling. There are two ways they can do this. One is to use the
Transport
Hello Eric,
On Mon, 11 Oct 2021 at 21:19, E. Auer wrote:
> > Again, you're misunderstanding the problem. You shouldn't just
> > automatically generate an ASCII 213 no matter what the Code Page is --
> > you should only generate an ASCII 213 when that's the Euro character
> > on the Code Page cu
Hi!
now they will generate 213 with AltGr+E, whatever the codepage. with
a proper codepage, this will look like €.
Again, you're misunderstanding the problem. You shouldn't just
automatically generate an ASCII 213 no matter what the Code Page is --
you should only generate an ASCII 213 when
>> So you made up your own GR mapping that is different than everybody
>> else's (there is a "Tom's custom GR keyboard layout")?
> of course not.
Exactly. This was me responding to you saying there were no standards, but you
followed a standard (whether de facto or explicitly documented, still
Hi,
On Sat, 9 Oct 2021 at 20:02, tom ehlert wrote:
> > I'm afraid they are. Because when a user presses the key (or key
> > combination) to produce Á, what the user expects is to see Á on the
> > screen, and not just send a scancode where you may or may not be
>
> send a keyboard code Á
>
What
Hallo Herr Aitor Santamaría,
am Samstag, 9. Oktober 2021 um 19:01 schrieben Sie:
>>> codepage is a display thing, essentially it's the table how to
>>> convert 8-bit bytes into a visable character set, and mostly
>>> unrelated to the way the keyboard driver converts scancodes into
>>> bytes.
Hello,
On Fri, 8 Oct 2021 at 12:18, tom ehlert wrote:
>
> >> codepage is a display thing, essentially it's the table how to
> >> convert 8-bit bytes into a visable character set, and mostly
> >> unrelated to the way the keyboard driver converts scancodes into
> >> bytes.
>
> > The Code Page and
Hallo Herr Bret Johnson,
> So you made up your own GR mapping that is different than everybody
> else's (there is a "Tom's custom GR keyboard layout")?
of course not.
> Going back to the KEYB - Code Page relationship, I just ran a
> little "Euro test" to see how MEKYB and FD-KEYB handle the Euro
> it's not uncommon for germans to use US-ASCII keyboards (QWERTY).
> other use german keyboards (QWERTZ).
Yes -- lots of countries have multiple keyboard layouts. Even in the US with a
standard QWERTY layout, you can use a keyboard driver that implements it as
straight US or as US-Internation
On 08/10/2021 12:17, tom ehlert wrote:
it's not uncommon for germans to use US-ASCII keyboards (QWERTY).
other use german keyboards (QWERTZ).
in both cases the codepage is 437 (BIOS default) or 858 (with €), but
Y and Z are swapped.
the same is probably true for french keyboards.
French peop
>> codepage is a display thing, essentially it's the table how to
>> convert 8-bit bytes into a visable character set, and mostly
>> unrelated to the way the keyboard driver converts scancodes into
>> bytes.
> The Code Page and the Keyboard layout are not unrelated at all -- -- they are
> HIGHL
> the user told you to type ASCII 13. why don't you 'type' 0x13 using
> INT16, AH=05h? use scancode 0x02 and send complains to me?
I'm not actually "complaining" about MKEYB since KEYB is available and does
things "correctly" -- so there's no need for me to use MKEYB. In fact, as a
user, I liv
> On 07/10/2021 18:47, tom ehlert wrote:
>> were these 2 layouts dynamically switchable (and actually
>> switched)
> They were actually not switchable, mainly due to their implementation:
> CP852 was provided by "mode con cp" through MS-DOS, while the Mazovia
> codepage was usually loaded through
On 07/10/2021 18:47, tom ehlert wrote:
were these 2 layouts dynamically switchable (and actually
switched)
They were actually not switchable, mainly due to their implementation:
CP852 was provided by "mode con cp" through MS-DOS, while the Mazovia
codepage was usually loaded through a custom
> Plus, you can have situations where there is not a unique set of
> ASCII/scan code combinations. E.g., ASCII 13 (Carriage Return) can
> be generated by Enter, Grey Enter (on the NumPad), Ctrl-M, Alt-013,
> and maybe other ways too. If the user tells me to "type" an ASCII 13, which
> key(s) d
> codepage is a display thing, essentially it's the table how to
> convert 8-bit bytes into a visable character set, and mostly
> unrelated to the way the keyboard driver converts scancodes into
> bytes.
The Code Page and the Keyboard layout are not unrelated at all -- they are
HIGHLY related. M
Hallo Herr Mateusz Viste,
am Donnerstag, 7. Oktober 2021 um 17:00 schrieben Sie:
> On 07/10/2021 15:43, tom ehlert wrote:
>>> DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to
>>> inform KEYB so it can change its mapping.
>> please provide an example where this is necessary AND plau
On 07/10/2021 15:43, tom ehlert wrote:
DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to
inform KEYB so it can change its mapping.
please provide an example where this is necessary AND plausible.
In Poland, there were a few codepages used during the DOS era. The two
main ones we
>> how should a KEYB scancode->keycode driver react to copdepage
>> changes, and how are these communictated?
> Well, first of all the keyboard driver should detect the current
> Code Page on installation and not just assume one.
codepage is a display thing, essentially it's the table how to con
32 matches
Mail list logo
