| Title |
Phindows Known Limitations, Gotchas and "Why can't I's" |
| Ref. No. |
QNX.000009518 |
| Category(ies) |
Configuration |
| Issue |
1: Phindows command-line parsing is not POSIX-standard,and is not tolerant of whitespace.
2: When run as a service via phrelay, a Photon application's base window options are not honoured. In particular, the decision to reject resize, maximize and exit requests is not passed to Phindows.
3: What is the range of characters that can cause the Phindows "divide by zero" error?
4: Phindows showing output from a process that's no longer live on the QNX server node.
5: Voyager running inside of Phindows crashes phrelay.
6: When phindows is updating the, mouse is dead, it is not possible to remotely stop the process!
7: Why can't I use <alt><tab> to switch windows on the Photon console within a Phindows session?
8: Dragging a window within a phindows session partially offscreen will mess up the display when the window is dragged back onscreen.
9: How do I get support for multiple "windows" in a single Phindows session?
10: If you set the Value XOR flags in a RTProgress widget it will not display properly over phditto/phindows.
11: How do I setup a PDM icon to act as a jump gate to a phindows session on a fixed win32 hostname (or IP address number)?
12: XOR drawing doesn't work under Phindows.
13: Programs used in Phindows don't recognize the ^[ sequence of keys to produce a character -- but this does work in Photon.
14: Using the Voyager browser over a Phindows link, an animated GIF was not animating.
15: Phindows 1.20 always starts on console 1, but the Ctrl-Alt-N code seems to think it's still on the same console that is was on when phindows last exited.
16: Phindows doesn't support ALT-Gr (greater than arrow) keys.
17: Phindows 1.20 crashed with a divide by zero error.
18: Why doesn't the cursor I see in my Phindows session match the one seen when I'm in a native Photon session?
19: Problems seeing the result of Photon PmMem*() functions through a Phindows 1.12 interface,although this was no problem with the Photon app. when run locally. Instance -- the example code from the help entry on PmMemCreateMC.
20: Using escape keys and other terminal-specific sequences in phindows 1.20.
21: How can I cut and paste between phindows and NT?
22: Phindows not refreshing correctly when overlapped by W95 dialogue windows.
23: National keyboards/characters are not what phindows expects.
24: Can I run phrelay in daemon mode to avoid the need for inetd on an embedded system?
25: Using qnx_spawn() seems to fail when the Photon program is viewed over Phindows.
26: vedit sessions started from PhAB and pterm's display garbage.
27: Reducing the Phindows window to less than the size of the Photon taskbar can cause Phindows to crash.
|
| Solution |
Issue 1: Phindows command-line parsing is not POSIX-standard, and is not tolerant of whitespace.
The phindows.hlp page gives the impression that spaces between the options and the associated argument are allowed (e.g. phindows.exe -t 1.2.3.4), but this doesn't appear to be the case.
Strictly speaking, phindows.exe is a MS-Windows application which is not POSIX, however the argument parsing could stand to be a little more tolerant of whitespace. This is on the todo list for a version of Phindows after 1.20.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 2: When run as a service via phrelay, a Photon application's base window options are not honoured. In particular, the decision to reject resize, maximize and exit requests is not passed to Phindows.
The problem here is that Phindows is designed to move a Photon _desktop_ onto a Windows Desktop. Running a single application as a service allows a single application to be run instead of an entire desktop, but the amount of window manager interaction is still pretty well limited to what you can do to a desktop. The individual Window Manager functionality is still handled on the Photon machine by a local PWM process with only limited "remote" capabilities (Window Title and size primarily).
What you are asking for is in "general" beyond the scope of Photon to handle. However, adding a few more "remote" capabilities (like window resize/minmax/close buttons) is not completely out of the question keeping in mind that the Windows client is NOT a window manager, but is simply the remote graphical extension of a local window manager. This could be considered in a future (post 1.21) version of Photon.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 3: What is the range of characters that can cause the Phindows "divide by zero" error?
For full details of the original issue (a bug in PtTerminal that cause a pterm to issue an invalid draw command), see the issue "Phindows 1.20 crashed with a divide by zero error".
In fact it's not a range of characters -- it's just a set of ISO 8859-1 characters that can't be displayed using the PC character set. Here's the full list:
0xA9 COPYRIGHT SIGN
0xAE REGISTERED SIGN
0xB3 SUPERSCRIPT THREE
0xB9 SUPERSCRIPT ONE
0xBE VULGAR FRACTION THREE QUARTERS
0xD0 LATIN CAPITAL LETTER ETH
0xDD LATIN CAPITAL LETTER Y WITH ACUTE
0xDE LATIN CAPITAL LETTER THORN
0xF0 LATIN SMALL LETTER ETH
0xFD LATIN SMALL LETTER Y WITH ACUTE
0xFE LATIN SMALL LETTER THORN
Note as well that pterm was fixed in Photon 1.13 to avoid this problem.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 4: Phindows showing output from a process that's no longer live on the QNX server node.
phrelay on the QNX server node will indeed cache a data stream, so you can easily go on for several minutes before the data was all drained away in such a situation.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 5: Voyager running inside of Phindows crashes phrelay.
There is a known bug with the way the Photon 1.13 release of phrelay dealt with large images in its cache. This will be fixed for a patch of Photon.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 6: When phindows is updating, the mouse is dead, it is not possible to remotely stop the process!
This matches the behaviour one gets with the W95 TCPIP stack, which preempts mouse events. If you are using W95, it would be worth trying a commercial TCPIP stack -- certainly the W95 one has a bit of a dubious reputation for fragility under heavy loads.
As a general note, avoid "continuous graphics" (e.g. animations) in a display you know will be viewed via Phindows, since MS Windows seems to give priority to servicing the inbound TCP/IP traffic ahead of keyboard/mouse events.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 7: Why can't I use <alt><tab> to switch windows on the Photon console within a Phindows session?
W95/NT consumes <alt><tab>, and there's nothing we can do to change that. There are a few things you can do to work around this when setting up your Phindows session:
a) put your windows on separate consoles. You can then use <CTRL><ALT><number of console> to take you to the active window on that console. So, if I was on virtual console 1, and needed to see console 9, CTRL-ALT-9 would take me there.
b) <CTRL><ALT><TAB> will achieve the same effect, but this requires you to reconfigure pterm to pass along the ALT key rather than consume it itself.
To do this, right-click within a pterm to bring up the pterm configuration menu. Choose "Properties" and then set the "Alt keys" toggle button. See "Configuring pterm" in the Photon User's Guide section on the Terminal Window for more details.
c) Using "kiosk mode" will pass more "more" native (MS) keystrokes through to the remote (QNX) end.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 8: Dragging a window within a phindows session partially offscreen will mess up the display when the window is dragged back onscreen.
This is another symptom of the blitting issue. See the response to issue "phindows not refreshing correctly when overlapped by W95 dialogue windows" for more details of the problem and why there is no workaround. Note that this behaviour is an intentional tradeoff.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 9: How do I get support for multiple "windows" in a single Phindows session?
The short answer is you cannot have this. The reason is that Phindows connects to a normal Photon session, and Photon itself has no concept "exporting" the window management functions that would be required. This is true both for multiple window support, and also the broader question of making a Phindows session act (and interact) in real time like a native Win95 "window".
For this to happen, there would need to be a lot of changes to Photon (essentially popping up each Window onto an entirely new video screen independant of the base application's screen, then managing the Window operations like move, resize, title, etc. by sending commands to the remote client instead of handling them locally). Requiring the remote window manager to be in the loop may cause some unpleasant side effects especially if the turn around time across the communications link is large. Furthermore, Photon programs which assume they can get results quickly would start to fail.
No such complete redesign of Photon is in the cards at the moment.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 10: If you set the Value XOR flags in a RTProgress widget it will not display properly over phditto/phindows.
See the response to the topic "XOR drawing doesn't work under Phindows". (f.12)
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 11: How do I setup a PDM icon to act as a jump gate to a phindows session on a fixed win32 hostname (or IP address number)?
Unfortunately, you cannot do this. Here's why: when Phindows is started, it gets a different photon device name of //<server node number>/dev/ph$$, where $$ is the Process ID on the QNX server node. It seems like one could use the -n option to connect to an existing Photon session, since Phindows normally has a Photon session of its own, right?
However, phrelay doesn't allow you to name the device to which you will connect. It only allows dittoing an existing session called /dev/photon, or the creation of a new session with "-n <//node number>/dev/ph+"
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 12: XOR drawing doesn't work under Phindows.
If you are using a "high" or "true" colour display on the MS box, then the XOR will not work as you expect it to, because of the bits that wind up being XOR'ed. There's not really anything we can do about this.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 13: Programs used in Phindows don't recognize the ^[ sequence of keys to produce a character -- but this does work in Photon.
Phindows cannot be "sure" that the keystrokes you are typing (^[) are really "supposed" to be an ASCII character, since the '[' key is not usually a base key on most keyboards around the world. If it KNEW absolutley that the keyboard was a full U.S. keyboard, and it wanted to "snoop" inside the raw keyboard data stream, it could probably figure out that you had typed ^[ and that that was supposed to generate and ASCII control character.
We have tried to make phindows use the Windows95/NT international keyboard neutral facilities to avoid unexpected/incorrect behaviour on non-US keyboards. The six control codes which do not use A-Z are "difficult" to make work on most non-US keyboards without intimate knowledge of the keyboard driver and OS version...
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 14: Using the Voyager browser over a Phindows link, an animated GIF was not animating.
Phindows doesn't support animated GIF's.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 15: Phindows 1.20 always starts on console 1, but the Ctrl-Alt-N code seems to think it's still on the same console that is was on when phindows last exited.
Sequence:
o start Phindows with -n//47/dev/photon, and it starts on console 1
o go to phindows console 2 (i.e., Ctrl-Alt-2)
o exit phindows and then restart -- console 1 is displayed
o press Ctrl-Alt-2 --- console 2 is NOT displayed, console 1 remains on the phindows display.
With the current (1.20) version of phindows, there is a known problem with the "unlock" of phindows. It doesn't draw when the console being switched to matches the current console of the user being dittoed. This will be resolved in a future release.
Workaround: View another console (even the current one, i.e., Ctrl-Alt-1)) and then press Ctrl-Alt-2.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 16: Phindows doesn't support ALT-Gr (greater than arrow) keys
Phindows 1.10 does not support these keys, Phindows 1.20 does.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 17: Phindows 1.20 crashed with a divide by zero error.
Behaviour:
cat'ing a file that contained ANSI colour escape sequences in a pterm viewed through Phindows 1.20 gave a divide by zero error on a Windows95 box. The same crash would often also happen when a directory was cat'ed.
MS Windows error message:
PHINDOWS caused a divide error in module PHINDOWS.EXE at 0137:00407c2a.
How we found out:
We determined which character was crashing Phindows by with a test program that put the character string to std. out. On the photon side, we
a) ran the program in a pterm
b) covered the first pterm with a second one. Then, on the Phindows side, we
c) moved the Phindows console to see the second, covering, pterm
d) slowly uncover the first pterm by moving the second pterm to the right until Phindows crashed; this told us what column the problem character was on. Back in Photon, we covered that column with a third pterm.Then, after restarting Phindows, we
e) slowly moved the third pterm down until Phindows crashed again (It was octal 263)
What was going wrong:
There's a bug in the Photon 1.12 PtTerminal that causes pterm to generate an invalid draw command, and Phindows doesn't handle it well. pterm has been fixed for Photon 1.13, and a future (post 1.20) version of Phindows will be as well.
Behind the scenes:
The invalid draw stream given by pterm has been fixed, but it is possible for your Photon applications to have a similar effect by attempting to use "wide characters" which have by their very nature a large number of embedded NULLs.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 18: Why doesn't the cursor I see in my Phindows session match the one seen when I'm in a native Photon session?
1) When using the Help icon of PDM through Phindows, you don't get the expected "question mark" cursor, but rather an "up arrow".
2) Photon gives the "no input" cursor (circle with a line through it), but Phindows uses the "hourglass" cursor.
The standard MS cursor set doesn't match the Photon one. We substitute the best available match. For instance, the uparrow is the best standin for the question mark in that was noticeably non-standard, and has a clear indication of where it points.
Note that we can only use the standard set, but some MS apps. will add their own cursors. We don't do this because drawing our own (genuine Photon) cursors pixel by pixel would slow down performance unacceptably.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 19: Problems seeing the result of Photon PmMem*() functions through a Phindows 1.12 interface, although this was no problem with the Photon app. when run locally. Instance -- the example code from the help entry on PmMemCreateMC
Either avoid the use of shared memory ( use malloc() instead ) or set the "tag" member of the PhImage structure that you provide to the Pm functions. PhRelay doesn't forward shared images unless they have a tag.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 20: Using escape keys and other terminal-specific sequences in phindows 1.20.
phindows does its best to map keys from Windows into QNX/Photon codes while letting Windows perform all the local keyboard translations. There are problems in generating codes for ^^ ^] ^ and ^_ in an "international-keyboard-friendly" manner (on many keyboards these keys are combinations of many shift/Alt keys).
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 21: How can I cut and paste between phindows and NT?
There is no easy way. One could link the filesystems together with SMBFsys or NFS, then cut and/or past to/from a local MS editor which is reading /writing a QNX file.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 22: Phindows not refreshing correctly when overlapped by W95 dialogue windows
Reason: Any "force_front" application can cause this (the Alt-tab dialog of Windows is an example. The "problem" is that phindows does not (cannot?) know if it is the "foreground" window or not. For performance reasons, phindows "really wants" to turn Photon blit operations into native blit operations (such as when scrolling in pterm). Unfortunately, if phindows is partially covered be a force-front window, the portion of the screen which "should have" been exposed instead of copied is not known to Phindows. This will result in some rather odd looking screen displays.
phindows attempts to deal with the high-runner case by disabling native blits and turning ALL blit operations into exposes (which works but is slower) whenever some other window has the focus. However, a force-front pop-up is "invisible" to Phindows and escapes notice, resulting in a messed-up display
There isn't any good solution for this (other than ALWAYS disabling native blitting) which has unacceptable performance in the "normal" cases....
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 23: National keyboards/characters are not what phindows expects
NT 4.0 allows you to define keyboards for each application; you'll need to define a US keyboard for phindows
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 24: Can I run phrelay in daemon mode to avoid the need for inetd on an embedded system?
No, unfortunately not. You do need something to take the role of inetd. You could write your own tiny inetd that did nothing but listen on the phrelay socket, and launch phrelay. Below is a slab of debug code taken from the current "tinkering" (April 1999) version of phrelay that does pretty much this. It should give you enough of a head start to get you going.
******************* sample begins ************************
int sock,on,len,msgsock;
struct sockaddr_in saddr,peername;
garry_opt = 0;
if ((sock = socket(AF_INET, SOCK_STREAM, 0)) <0) {
exit(1);
}
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *) &on, sizeof(on));
saddr.sin_family = AF_INET;
addr.sin_addr.s_addr = INADDR_ANY;
#define PHRELAY_PORT 4868
saddr.sin_port = htons(PHRELAY_PORT);
if (bind(sock, (struct sockaddr *)&saddr, sizeof(saddr)) <0) {
exit(1);
}
if (listen(sock, 5) <0) {
exit(1);
}
len = sizeof(peername);
if ((msgsock = accept(sock,(struct sockaddr *)&peername, &len)) <0) {
exit(1);
}
close(sock);
setsockopt(msgsock, SOL_SOCKET, SO_KEEPALIVE, (char *) &on, sizeof(on));
dup2(msgsock,0);
dup2(msgsock,1);
******************** sample ends **************************
Note that instead of the dup, you'd want to set msgsock as stdin stdout and exec phrelay. Be warned that this is not guaranteed or supported code, but merely a basis for your own development.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 25: A PhAB application which spawns another photon application with qnx_spawn() works well when seen via Photon, or via phditto, but the child application does not appear if the program is run via Phindows. The message "Ap: Unable to locate photon" 1appears in the pterm window from the application started.
The problem is that the PHOTON environment variable it not being passed to the new app. When it's undefined, the library defaults to /dev/photon -- but that's not what the Photon device normally is when you're running Phindows. In general, it's a good idea to let a child process inherit any environment variables that you have no reason to change or unset.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 26: We have a number of developers connected to a QNX server via Phindows. Recently we installed Phab on the server and one developer started working on an application using Phab in his Phindows session. After a couple of hours something happened such that vedit sessions started from Phab display garbage. Likewise, any new pterm started on any Phindows session has a screwed up shell, i.e. it doesn't interept the keystrokes correctly and displays "define header for application - AppBuilder 1.13" on the pterm. The text also turn green like it's under vedit control.
vedit is the culprit. It's a known problem that vedit sometimes refuses to terminate if you close the pterm (or the telnet session) that it's running in.
As a result, you have a pty that looks unused (i.e. nobody has its master side open) but has the vedit running on it. Next time someone opens a new pterm (or a new telnet session), it may re-use that pty and start a new shell (or a new vedit) in it -- and you end up with two programs trying to read from the same terminal. And there's a good chance that one of them is not yours... That's not only an inconvenience, but also a potential security hole.
The workaround is: never use the Close button on pterm's window frame if there's a vedit running in the pterm. Instead, exit from vedit using Alt-X or the File menu. It's a good habit anyway -- closing a pterm is a rather brutal way of terminating the application running in it, quite like using slay.
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Issue 27: Reducing the Phindows window to less than the size of the Photon taskbar can cause Phindows to crash.
This does happen, but it's a side effect of a limitation in the MS architecture, not with Phindows per se. The problem is that Photon (on the server node) is sending an ongoing series of draw events to phrelay/Phindows. When the Phindows window (as managed by W95 or NT) is below a certain size, these events cause a task exception (or "crash"). If the MS API were such that Phindows got hold of the event before the MS window manager, we could perhaps do something about it at the Phindows level. Unfortunately, MS gets the event first with the results described.
The other approach would be to have phrelay throw away Photon events while the Phindows window is below a certain size. This approach, unfortunately, wouldn't work because it would but Phindows out of synch with Photon, with bad results.
There is a ray of hope, however, in an undocumented (and unsupported) option to phindows.exe. You can use the "-f" option to "fix" the size of the Phindows 1.20 window. Users will be able to minimize the window, but not change its size by dragging with the mouse. This limits their options, but will prevent Phindows from crashing.
Consideration is being given to documenting the option for the next version of Phindows, and do whatever testing is necessary to ensure that "-f" is a release-quality option. |
|
