I don't use Linux, so can't say from personal experience, but WinUAE under WINE seems to work fine for most people.
Then maybe that's fine for most people. It's not fine for me. It's a workaround, not a solution.
Wine Is Not an Emulator, it just translates API calls.
You're not telling me anything new. It's still the wrong solution for the problem, it's an emulation of Windows API on Linux. What for? Write portable programs in first place. My stuff runs on Windows, Linux, AIX, IRIX, Solaris and probably a couple of other Os'es. Too lazy?
Because it has more features and speed than the other versions of UAE.
Good for you. Doesn't really help. Anyhow, this is a different discussion.
I agree, it would be nice if he supported more platforms (I was disappointed when Win98 support was dropped prematurely)...But no need to punish yourself by avoiding it just because of that.
It's not a matter of "punishment". It is a matter of "why emulation doesn't work for me", which is what the whole thread is about. There's no usable emulator for my platform and my application, that's what I'm claiming, no more no less. I'm not claiming "emulation doesn't work for anyone". It's probably perfectly fine for your use-case, and probably for many others. It isn't for mine. No, you won't convince me to use wine just for that purpose. It's conceptionally the wrong approach to the problem. The right approach is "write portable software".
Your proposed solution IIRC was something along the lines of translating a host scancode into ASCII via the host OS, then translating that ASCII value into a guest scancode. Which would cause all kinds of issues and is about the least clean solution I can imagine.
Once again, should I say again that I did this already? It's not really that much of a problem, and *no*, I'm not saying that you should read "scan codes", nor did I say "ASCII codes". This is not how keyboard input works. The Os'es I work on (and that includes windows, yes) give you enough abstraction information to note "hey, this key has the function of caps lock", and "hey, with the current keymap, this key has a function of Z". It doesn't give you an ASCII code for that matter. So please, try to get a bit more insight into the matter, would you? It is usually a multi-step translation process, from scan-code, to function, to ASCII. There is enough information on the whole line to get enough data to perform a reasonable information.
No, it shouldn't. Eg. with Caps Lock on, typing Shift-A on a PC gives lowercase a (on DOS and Windows at least, not sure about Linux), whereas on an Amiga it gives uppercase A. The correct behaviour when you type this into an Amiga emulator would be to handle it like an Amiga does.
This is not how it works. Again, you're reading something into my words I haven't said. Could you please try to read a little bit about the matter before you argue? For example, get the SDL documentation for starters - that's a nice portable multimedia abstraction library that is very workable. Caps Lock is a function key, that function needs to be mapped. "\" is a text key, here the contents (the text) need to be mapped, not the function. The Os interfaces provide the information to distinguish between the cases.
In fact, even *that* is wrong on xx-UAE: It places the CAPS LOCK function where it expects the key (by scan code) instead of using the lower-level Os abstraction to map the Caps-lock key where it was mapped by the user. I have caps lock and ctrl interchanged, the change is communicated to programs by providing keyboard functions (not ASCII codes) to the program, yet xxx-UAE tries to map by scan-code. That's the wrong approach. As said, there are multiple levels of keyboard translation you need to take into acount. No, it's not trivial, but again, it's not rocket science either. You just have to do your homework correctly.
There are a whole list of standard PC shortcuts, none of them get translated by any Amiga emulator. Eg. Alt-numpad to emit a specific ASCII character, Ctrl-X to cut, Alt-F,X for quit, etc.
Nope, again, that's not how the input layer works.
Surely it's best to be handled at the scancode level, not the ASCII value level...
No, the level a key has to be handled depends on the key, and there's more than ASCII and scancode, really. Scancode is completely wrong, because the user can re-assign keys, and the scan code doesn't get that. ASCII is wrong because some keys do not even generate ASCII. You need a multi-level translation: 1) Get the key function from the Os (not the scan code!). 2) Check whether that function maps to a printable "non-dead" key. 3) If not so, map to the corresponding function key on the host keyboard. For the Amiga, there is no multi-level translation, so just map it to the scancode. 4) If so, get the Amiga keyboard (by GUI configuration, or by a smarter way from AmigaOs through an emulation layer). From there, find the scancode for the key. Send one or multiple scan codes to emulate that key (or keys) to generate the same effect.
This algorithm works, and yes, I had this implemented, though not for xxx-UAE purposes. So please, don't tell me that I've done again the impossible.
It requires a bit work, some inspiration, and the motivation to create a truly working product that is satisfactory. If xxx-UAE doesn't offer that level of functionality, then it might be that the authors didn't know or didn't care, probably because the code was designed for a different purpose. Once again, I do not claim that this is bad or unsatisfactory for anyome. I'm only claiming "it's not good enough for me", maybe because I know what I want and need, and I would even know how to do. Note again that this is something different.
Also, whether or not ISO has endorsed it, it's not a platform-neutral or even OS-neutral standard, as there are Windows keys on it...
I don't think that ISO has anything to say about extra keys with a logo on it, nor about the logo. The keys are usually called "Left Meta" and "Right Meta", and that people put M$ branding on it is just the success of M$ for it.
Well, IIRC there's no way to type the two "international keys" (as present on some Amiga keyboards) on a standard PC keyboard, as they aren't present. (So probably every Amiga emulator fails this test.) Some kind of remapping is thus needed in any event;
"Reasonable remapping" is exactly the purpose of the emulator. It also "maps" the Amiga graphics to the PC graphics, the Amiga CPU to the PC CPU and the Amiga sound to the PC sound. What's so special about keys that you believe that this should not be done? Even if I tell you that it *can* be done?
Look, the simple algorithms currently used for keyboard remapping are probably too simple minded to do their job correctly, so emulation is not satisfactory *for me*.
It seems I have been misunderstood, sorry if my original answer was not clear. One runs the compiler, SAS/C in this case, from within the emulator. (AFAIK SAS/C is still closed source so it wouldn't be feasible to port it to another platform anyway.) Text editing of the source code can be done from the host or the guest, it doesn't make much difference.
More workarounds, then? Ok, let me see, how do I get it into the Amiga... Emulated network card, with emulated ssh connection, probably cvs on the Amiga side... Ok, probably workable, but again, that's probably too much work that could be invested in a better way by fixing up the stupid emulation. It's really not rocket science, it's elementary GUI design. It's the 101 of "making the easy things easy", and "having to create a custom keymap in the host and/or the emulated machine" is not easy, not for the average user.
The list isn't that long. 1) Fix the keyboard, 2) Fix the mouse grab (display a message, use an accepted key) 3) Offer a complete GUI for the configuration options. 4) Fix up the file system emulation and make that complete.
Not much can be done about the emulation speed, that's underdstood. Maybe, if I may make a wish, get the JIT working on AMD64 instead of just i386. 64bit is not exactly a new technology these days. Yes, I can run i386 code on AMD64, don't tell me, I know that. No, it still isn't a good solution. Write portable programs is the solution. Or as portable as you possibly could.
