Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Alfredo Fernández Díaz

Pages: 1 [2] 3 4
16
Hi guys, and thank you.
After digging around a bit more, the file is OSO001.msg, and the keys seem to be in the very first message, aka #0. These can be retrieved f.e. with some very simple REXX:
Code: [Select]
/* Get localized equivalents of single confirmation keys and such */
if RxFuncQuery('SysLoadFuncs') then do
  call RxFuncAdd 'SysLoadFuncs','RexxUtil','SysLoadFuncs'
  call SysLoadFuncs
 end
keys = SysGetMessage(0,'OSO001.MSG')
say keys
exit
and naturally you get "Y N A R I" for English, or "S N C R I" for Spanish, and so on.

I got a little worried when I found out the script above yields "Y N A R I" again for Japanese, or "1 2 1 2 3" for Russian, but apparently that is indeed how those work. Trying to format floppies from the command line, which involves this kind of simple confirmation, matches the values contained in the message on a Russian or Japanese system, see screenshots below:

17
Hello,

I seem to recall there is a message file where you can read the localized equivalents of "y" and "n" (for example that would be "j" and "n" --ja/nein-- for German) used in NLV OS/2 systems for stuff like simple confirmations, and such.

Any hints/help/reminders?

Thank you in advance,

18
Hardware / Re: USX keyboard layout
« on: March 28, 2023, 07:49:17 pm »
There are also hints of USY and USZ keyboards in the files that don't seem to actually exist as if someone stopped work suddenly. Or I could be totally wrong...
You are about "USY" and "USZ" keyboards: there is no such thing.
No, I was wrong too -- you were only partially wrong about USY and USZ ;)

There are definitely no such things in KEYBOARD.DCP. However, since keyboard layout is established globally even though VIO and PM sessions use separate definitions of each layout, using different indexing and IDs, there must be a communication mechanism. I.e., if you set the layout from the command line it tells the PM about it, and the other way around (but that is not interesting right now). That is why you were right to look at KEYB.COM and I was wrong to ignore it because I thought you must have found random strings in a binary file. Well, no!

Indeed KEYB contains a table that associates its own VIO layout identifiers as defined in KEYBOARD.DCP with PM keyboard layout indexes. So when you tell KEYB to load say SP, it looks for SP in KEYBOARD.DCP and loads it (SP172, actually) from KEYBOARD.DCP, then looks that up in this internal table, and tells the PM to switch to such-and-such keyboard layout.

A quick look (with keen eyes) to KEYB.COM reveals the following VIO / PM keyboard layout ID associations:

VIO    PM
ar470 28, 27
ar    21, 20
ba    37
be    02
bg    2C, 2D
br274 22
br    1D
by    5B, 5A
ca    3A
cf    03
cz    17
gr    06
de453 3C
de    06
dk    04
ee    3F
gk220 26, 25
gk    24, 23
sp    0E
es    0E
su    0F
fi    0F
fr120 13
fr    05
hr    1A
hu    19
he    1F, 1E
is458 3E
is    1C
ic    1C
it142 14
it    07
la    08
lt    4C
lv    4E
mk    2E, 2F
nl    09
no    0A
pl457 34
pl    1B
po    0B
ro    2B
ru443 35, 36
ru441 32, 33
ru    35, 36
sg    0D
sf    0C
sk    18
sl    2A
sq    38
sr    30, 31
sv    10
th    43
tr440 29
tr    16
ua    5D, 5C
uk168 15
uk    11
usdv  49
usdvl 4A
usdvr 4B
usx   FA
usy   FB
usz   FC
us    12
ux    39


Lo and behold, there are your USX, USY, and USZ! Furthermore, "FA" is indeed the ID of one of the many (150+) available PM keyboard layouts, and a glance at its contents reveals it is actually the USX keyboard layout for PM. (And in case you wondered, all the others are valid associations as well, so this is no coincidence.) Unfortunately, there are no PM keyboard layouts with the IDs FB or FC, just like there are no USY or USZ layouts defined in KEYBOARD.DCP.  :-\

19
Hardware / Re: USX keyboard layout
« on: March 26, 2023, 07:13:15 pm »
It's been like ten years since I last dealt seriously with Japanese OS/2, so sometimes it is hard to remember where you got information on some stuff, or that it is not always in an IBM book that no one has a copy of anymore ;)
Thank you for the pointers for CP932, Alex.

On a different note, please note that "UX" (which you just mentioned) is not the same as "USX", although both keyboard layouts are dubbed "US international". That, as listed in the Keyboard object in System Setup, does not mean USX but UX, so I take UX was the one you meant in your first post on this thread? Anyway, even if their "international" characters are laid out on top of different keys, they're both equivalent in the following aspects:

-The current MCP2/ArcaOS GA DCP only have USX/UX definition tables built for codepages 437, 850, 859, and 1004, and thus not all the characters are available if you use a different one, e.g. CP932.
-On my US ArcaOS test systems with CODEPAGE=850,932 both USX and UX load just fine from the command line with "KEYB US" or USX (but with a warning re: CP932), or if you specify them in your "DEVICE=KBD,XX,?:\OS2\KEYBOARD.DCP" line in config.sys.
-The popup message you get when selecting UX from the Keyboard object is equivalent to the KEYB warning in a command line session CHCPed to CP932. It simply means that you get no translation table to display your characters under CP932, or get one for CP437. It should then be no surprise that you get garbage when you use the keyboard to produce any characters absent from CP932.
-If you take out any USX/UX characters that are absent from CP 932, you get the US 103 keyboard layout with a handful of extra characters on top, so I would say probably not worth the effort to define new DCP tables for USX/UX to cover CP932.

20
Hardware / Re: USX keyboard layout
« on: March 25, 2023, 01:13:57 pm »
OK, I did a simple experiment.

I have attached a file containing all 62 non-7-bit ASCII, single characters that can be typed with the USX layout, leaving combining characters out for the moment being. (You need to view it while using CP1004, so you can see that characters look like their descriptions.) I tried converting it to other popular codepages:

-If you convert it to codepage 850, only both single quotation marks are lost. To be expected, since CP1004 was an extension to CP1004, but not one USX explores in depth.

-If you convert it to codepage 932, only 12 characters survive as double-byte, and I don't know in what health (¬, €, ƒ, £, and ¢ all get converted to the same thing), so I wouldn't hold the greatest expectations for the moment being. Conclusion/question: even if a USX/932 were feasible to build as it stands, would it be worth the hassle just to be able to type 12 more characters than you can type under CP932 using US103?

I would need to have a look at the DCP stuff in a real Japanese system.

21
Hardware / Re: USX keyboard layout
« on: March 25, 2023, 01:42:20 am »
That's strange -- what is your system with CP932 as the secondary codepage?
Not sure what you mean. My CODEPAGE statement is 850,932 if that's what you're asking.
You said usx refuses to load, but it loads in a normal US ArcaOS with codepage=850,932 here, so I thought yours might be something different. I realized later you probably just meant it warned you about the USX/CP932 combo not being present, but forgot what I had written before...

Remember, kids: always try and write your posts in one go ;)
Quote
Quote
[...] a new DCP can be built. The question, though, is what could be put in there? I mean, other than the ¥, which does work already, what other special characters of USX are present in CP932?
Looking through CP932, there seems to be a dozen or so, including most of the combining accents and a few other symbols. However, they're all encoded as double byte characters. I don't know if it's possible to handle that.
An interesting question, and the fact that ¥ does work suggests not all hope needs to be abandoned. AFAICT the character stuff in KBD_SETTRANSTABLE is mostly single byte-based but those are really code points within codepages, rather than raw characters, so I guess the best starting point would be, how many characters are there in CP932? What documentation covers this codepage?

22
Hardware / Re: USX keyboard layout
« on: March 24, 2023, 09:05:23 am »
I know the US International keyboard layout refuses to load on my system because I use codepage 932 (Japanese) as my secondary codepage.

That's strange -- what is your system with CP932 as the secondary codepage?
USX does load here albeit with a translation table for CP437 instead of CP932, which is normal because USX for CP932 is not present in the MCP2 DCP (nor the current one in ArcaOS), see the attached pic.

Quote
I wonder if a modified DCP would allow that...
I am pretty sure it would (here, anyway) so a new DCP can be built. The question, though, is what could be put in there? I mean, other than the ¥, which does work already, what other special characters of USX are present in CP932?

23
Left/Right Alt+Shift worked well enough for me with PM sessions
[...]
Does anyone know what the system-provided mechanism for switching keyboard layers in VIO sessions is?
OK, self-reply after comparing a Russian system to a "russified" one and fiddling a bit: the switching mechanism is the same hotkey, by default Left Alt + Left Shift to switch from Latin to Russian, and Right Alt + Right Shift to switch from Russian to Latin. Apparently the problem is, it works in VIO sessions only if 866 is the primary system codepage. OTOH it works in PM sessions regardless of CP866 being primary or secondary :(

24
Hi again, and thank you.

Basic system configuration I had covered, but I had forgotten about KLayer/2 -- it works great for text mode sessions too!

Now, for completeness sake...

Nice as KLayer/2 is, I had forgotten about it because I did not really need it -- Left/Right Alt+Shift worked well enough for me with PM sessions, which is all I needed (some 10 years ago). Does anyone know what the system-provided mechanism for switching keyboard layers in VIO sessions is?

25
Hardware / Re: USX keyboard layout
« on: March 22, 2023, 08:31:58 pm »
Hi, in case it's not too late to join the party...

What confused me is that the key in the upper left corner of the keyboard did nothing at a prompt, but it works in word processing programs. There are two missing characters (left and right single quotes) and a few ways of typing characters don't work, but the characters can be typed by other means. So there you have it, the USX keyboard.

The reason why the USX keyboard layout you tried works differently at a prompt and word processing programs (which I assume are PM applications) is because text sessions and PM use different implementations of any given keyboard layout, and it turns out both versions of the MCP2 "USX" differ from the one in the image in different ways:
-The MCP2 / ArcaOS 5.0.7 USX layout has combining- and non-combining versions of the acute accent and dieresis reversed wrt what you can find in the image (key to the left of Enter, with 4 symbols on it).
-Additionally, characters (dead keys) do not work in the VIO implementation, though there is no technical reason for that.

-As an extra, the MCP2 USX yields ƒ for Alt+Gr and ª for AltGr+K both in PM and VIO implementations.

As for the 'missing' left and right single quotes, these characters are present in some OS/2 codepages (f.e Win1252/1004, which Windows defaults to), while not in others (f.e. 850, which OS/2 typically defaults to). So if you try and type them in an OS/2 program you get them if typing while using CP1004, but you get nothing if running under CP850. PM vs VIO is not relevant regarding this, as codepages are the same.

[...] (usx) which is not supported under OS/2. Only US International (ux) can be configured.
This is not completely accurate. You can't configure USX as the system keyboard layout from the Keyboard object like you can do with UX, because it is not listed there, but as Daniel mentioned before, you can do it from a command prompt or f.e. a program object that runs "keyb usx", with the limitations I listed above.

I don't know if ArcaOS ships with support drivers that can handle newer keyboard layouts?
Newer keyboard layouts can be added to OS/2 and thus to ArcaOS, although this is not trivial (but not related to 'drivers' either). Sufficient interest might spark the inclusion of tools to handle such new layouts, though.

There are also hints of USY and USZ keyboards in the files that don't seem to actually exist as if someone stopped work suddenly. Or I could be totally wrong...
You are about "USY" and "USZ" keyboards: there is no such thing. This is the full list of keyboard layouts defined in the MCP2 KEYBOARD.DCP file, with some additional data:

Name/def|available CPs (and layers) by keyboard type; 1 = 100+ keys, 0 = 80+
----------------------------------------------------------------------------
AR 238   1: 437, 850, 864(2); 0: 437, 850, 864(2)
   470   1: 437, 850, 864(2)
BA 234   1: 850, 852
BE 120   1: 437, 850, 859, 1004; 0: 437, 850
BG 442   1: 850, 855(2), 915(2)
BR 274   1: 437, 850, 1004
   275 * 1: 437, 850, 1004
BY 463   1: 850, 866(2), 1125(2), 1131(2)
CA 445   1: 437, 850, 1004
CF 058   1: 850, 863; 0: 850, 863
CZ 243   1: 850, 852
DE 453   1: 437, 850, 1004
DK 159   1: 850, 1004; 0: 850
EE 454   1: 850, 922
FR 120   1: 437, 850, 1004
   189 * 1: 437, 850, 859, 1004; 0: 437, 850
GK 220   1: 437, 813(2), 850, 869(2)
   319 * 1: 437, 813(2), 850, 869(2)
GR 129   1: 437, 850, 1004; 0: 437, 850
HE 212   1: 437, 850, 862(2); 0: 437, 850, 862(2)
HR 234   1: 850, 852
HU 208   1: 850, 852
IS 197 * 1: 850, 861, 1004; 0: 850, 861
   458   1: 850, 1004
IT 141 * 1: 437, 850, 1004; 0: 437, 850
   142   1: 437, 850, 1004
LA 171   1: 437, 850, 1004; 0: 437, 850
LT 456   1: 850, 921(2)
LV 455   1: 850, 921(2)
MK 449   1: 850, 855(2), 915(2)
NL 143   1: 437, 850, 1004; 0: 437, 850
NO 155   1: 850, 865, 1004; 0: 850, 865
PL 214 * 1: 850, 852
   457   1: 850, 852
PO 163   1: 850, 860, 1004; 0: 850, 860
RO 446   1: 850, 852
RU 441   1: 850, 866(2), 1125(2), 1131(2)
   443 * 1: 850, 866(2), 1125(2), 1131(2)
SF 150F  1: 437, 850, 1004; 0: 437, 850
SG 150G  1: 437, 850, 1004; 0: 437, 850
SK 245   1: 850, 852
SL 234   1: 850, 852
SP 172   1: 437, 850, 1004; 0: 437, 850
SQ 452   1: 437, 850
SR 450   1: 850, 855(2), 915(2)
SU 153   1: 437, 850, 859, 1004; 0: 437, 850
SV 153   1: 437, 850, 859, 1004; 0: 437, 850
TH 191   1: 850, 874(2); 0: 850, 874
TR 179 * 1: 850, 857
   440   1: 850, 857
UA 465   1: 850, 866(2), 1125(2)
UK 166 * 1: 437, 850, 1004; 0: 437, 850
   168   1: 437, 850
US 103 * 1: 437, 850, 852, 857, 862, 864, 866, 1004, 1125, 1131; 0: 437, 850
   DV    1: 437, 850, 1004
   DVL   1: 437, 850, 1004
   DVR   1: 437, 850, 1004
   X     1: 437, 850, 859, 1004
UX 103   1: 437, 850, 859, 1004

26
Hi,

I need help from anyone who knows how to use a Russian / Ukrainian keyboard layout (or any other dual-layer one I guess) on OS/2, to type Cyrillic characters on a text mode session.

Just in case you wonder, I have a Russian system, and other OS/2 systems with 866 as the secondary system codepage. If I execute "CHCP 866" as necessary at a command prompt, then execute the attached rexx script, text-mode Cyrillic characters display just fine (see attached screenshot Cyrillic.png).

If I then execute "keyb ru" as necessary, I get the expected messages stating the necessary conversion codepage tables loaded just fine. The problem seems to be that the Russian keyboard starts in English / Latin mode and I can't switch to use the Russian layer of the text mode keyboard layout.

I.e., if I start say "AE" from the same command prompt, typing will get me English / Latin characters in the system editor, but if I press Left Alt + Left Shift I can type Cyrillic characters no problem (see attached capture MoreCyrillic.png), and pressing Right Alt + Right Shift gets me back to Latin mode. Closing AE gets me back to the same prompt window, but sure enough, my Russian keyboard layout stays in Latin mode at the command prompt.

So the problem is, how do I switch between the Latin and Cyrillic layers of the text mode Russian keyboard layout? Does anyone know where the layer switch hotkeys are documented?

Thank you in advance,

27
Events / Re: User Meeting Cologne November, 5th 2022 confirmed
« on: July 09, 2022, 04:02:51 pm »
Whenever the question arises about us not providing enough updates, I answer that with the question:

If we are still working on things, what should we say in a blog post?
A good answer/question that deserves another on its own. If anything absolutely and fatally catastrophic happened, what would you say in a blog post? By definition, nothing. So how would people know what happened? Probably by poking around after a while, starting here -- oh, what a coincidence! ;)

It is good to hear that you are not dead (you owe me email replies -- will be glad to resend the messages if they got lost), but frankly it would be even better to hear signs of life every once in a while, "Still working hard pushing X/Y/Z <Last update on such-and-such>" would be more than enough for me. I agree that that is still not very informative, though, and thus no need to say it too often. But maybe you could spend literally two minutes on doing that every two months?

Please take this as a constructive criticism, for that is how it is intended -- I am guilty of exactly the same somewhere else, and I (hate to) admit that people are right when I am told so. It is incredible how much a simple, periodic 'still working on it, not quite there yet' spares me when I remember to issue one :)

28
Setup & Installation / Re: Dos and WinOS2
« on: July 09, 2022, 03:36:45 pm »
to buy the maintenance program after expired was more expensive than just purchasing the whole OS again...
I don't know what maintenance program you mean, but that doesn't sound very logical. I know for a fact that the Arca people are extremely honest and serious about their business, so I am sure that if you address them directly and politely to point out any problem with their pricing policies or whatever, you will get it sorted out in no time or, at the very least, an explanation of why things are the way they are that you can disagree with and share here :)

29
Web applications / Re: The MicroWeb DOS web browser
« on: July 09, 2022, 03:21:28 pm »
[...]tcpv21cp.exe TCP/IP v 2.1 Programmer's toolkit CSD
    (1054355 bytes, 10-21-93)

I'm checking how to unscrable the .H_# files. Suggestions?

Having a look at the TCPCSD.BAT inside tcpv21cp.exe, you'll find that it wants to process them using something called "decomp.exe", located in %ETC%\..\BIN (?:\TCPIP\BIN, one would guess). That is not present on MCP2/AOS systems, so I would guess it is yet another relic, er... custom [un]packer from the TCPIP 2.1 days, presumably to be found on ancient enough systems.

30
[...] it is a bit strange, because both printers are PS printers.
Guessing here, but probably one of the PS drivers simply generates simpler, more compatible (and verbose!) PS code with bitmap font replacements and such. Sub-optimal for producing PDFs, but there should be no noticeable difference in output when actually printing at the right resolution.

Pages: 1 [2] 3 4