I'm sorry if I had left some points in PC/2 unclear, stated incorrectly or just used the wrong phrases (as a native German speaker). I'm sorry too if there are some bugs left or something that appears to be a bug, unfortunately making bug-free software is very difficult and requires an enormous effort by voluntary beta testers (thanks for all you have contributed!) and me and all possible hardware and software combinations I don't have.
The following tips and tricks are available at the moment:
I thought that decrypting the source code should be faily easy, but it seems I was wrong, I've included a small trace with comments therefore.
For download from Geocites only I have divided PC/2 into 2 parts,
pc2v200.zip and source.zip.
Download both files but ensure that source.zip gets downloaded as
Source.zie (unfortunately Geocities doesn't allow files named *.zie.
If you then unzip pc2v200.zip ensure that the just renamed Source.zie
does not get overwritten (most easily checked by the file size),
pc2v200.zip contains also a file Source.zie for the installation
program not to fail, just in case you don't want to download the source.
I started writing the batch installation under the REXX installed by OS/2 2.0, now using the one of Warp 3 and 4. I got reports that the installation does not run under Object-REXX (the object-oriented dialog of REXX). This can easily be fixed by editing INSTALL.CMD and delete all whitespace characters at the end of line 633 (column 92). You will notice if you have removed everything by either the editor joining the next line (which you should undo) or by beeps.
I don't know why, but somehow EPM added a 0x00 character at that line. Plain REXX doesn't care about that, but Object-REXX does. There exists also Net-REXX (the REXX version supporting JAVA calls), and it can't hurt to edit that line too.
I got reports (and have seen that myself) that seamless WIN-OS2 sessions sometimes draw incorrectly when having activated PC/2's SessionBar. Symptoms are that the menus popped up when accessing the system menu are not drawn at the window, but upwards and left of it. With code changes I have decreased the probability from 1 for every menu invokation to only the first (or at least once in a while), but as I don't know the cause I have no idea how to fix it completely.
Sometimes the WIN-OS2 window also draws over or covers the SessionBar, again this is related to the way WIN-OS2 windows seem to work.
Just to get you an idea why WIN-OS2 windows behave so peculiar some words about
how I think WIN-OS2 windows work (I don't know much about device drivers and the
display driver in detail).
Everything drawn onto PM (the graphical shell of OS/2) is down by the display driver
under control of the GRE (GRaphics Engine). For example GRADDs (GRaphics Adapter
Device Drivers, the new model from Warp 4) just need to know how to do a number
of limited, very primitive operations like e.g. to draw a point, the GRE handles
all the complex operations like e.g. draw a rectangle by calling the limited, very
primitive operations (though the GRADD can offer the GRE to do complex operations
like e.g. scaling instead of the GRE).
Important to note is that the GRE and graphics driver are responsible for everything
that shows up on the display.
Actually, to support seamless WIN-OS2, the GRE is used by 2 subsystems, the GPI (Graphics Programming Interface, used by native OS/2 PM programs) and the GDI (Graphics Device Interface) drivers of seamless WIN-OS2. Important to note is, that a point requested to be drawn on screen can come from a PM or WIN-OS2 window.
PM (Presentation Manager) is a window manager that manages the windows it draws, for example it knows which windows are overlapped and therefore partly need not to be drawn (it does that by cooperating with the GPI and consequently the GRE). Seamless WIN-OS2 windows however operates through their driver directly with the GRE, requireing the GRE somehow to propagate information like overlapping back to PM. Important to note is that a seamless WIN-OS2 window consists of the drawing in the GRE and some information about the window in PM (I call the PM window the PM shadow window and the GRE window the lower GRE window in the source).
If now the PM shadow window and the lower GRE window come out of
sync, for example where a window is located, funny effects (like the problems mentioned
above) occur.
In order to avoid overlapping the SessionBar, PC/2 might have to correct the position
of a window, for PM windows it adjusts that before the window is drawn visibly, however
applying the same technique for seamless WIN-OS2 windows causes just the PM shadow
window to be moved but not the lower GRE window resulting e.g. that the
WIN-OS2 windows sizing border draws outside the window graphics (for exactly that
problem I had to add code that works differently for WIN-OS2 windows and moves the
window after it has drawn, causing redraws which you might be able to notice).
Hopefully you can see that things are very complicated, one point to note is that programs ported with Open32 (like SmartSuite for OS/2) are native PM programs and should behave like any other PM program.
I think because of that complicated things, XFREE-OS/2 has its own graphics fullscreen, because from there it can use its own graphics drivers to operate the hardware directly. Supporting seamless XFREE-OS/2 would either require an emulation layer that maps the XFREE display driver calls to PM/GPI/GRE calls (causing driver rewrites and performance penalties) or to modify the OS/2 display driver to support a native interface from the XFREE display driver (causing problems similar to the ones of WIN-OS2, but delivering a fast seamless integration of XFREE). If I should do that, I would start looking into GRADD programming in the Device Driver Kit, which is freely downloadable from IBM (I wish I had the time to read all that information).
Though it is not likely, PC/2 may hang itself and/or other applications when exiting. This is caused primarily by two reasons (PC/2 is a very low level tool, so I recommend not launching and exiting it just for fun):
I got mail that a rumour says PC/2 won't install with Fixpack 5. I don't have installed any Fixpack (because you ain't fix what isn't broken, but I know definitely from one who has installed and runs PC/2 under FP5 on his ThinkPad.
Generally, I see no point why any Fixpack should prevent PC/2 from installing (installation uses REXX, and interpreted language) or functioning.
PMColor.cmd is just a sample how to change settings when not running PMSHELL but PC/2 as the WPS. All settings personalized with the various WPS objects in the System Setup folder are reflected by changes in the OS2*.INI files. With a little bit REXX you can do it without the WPS running, PMColor.cmd is just a sample how to do that.
I got mail questioning how to undo such changes. Well, making an archive previously may be an overkill, as the easiest way is to temporarily launch the WPS (by starting PMSHELL.EXE) and then use the WPS objects to reconfigure to your preferences.
I do know that chances of getting a background bitmap to be displayed correctly are very limited. PC/2 is using an OS/2 API (named WinSetDesktopBgnd() I think) which worked perfectly up to 2.11 but is broken since Warp 3. I did report this during Warp beta tests, but this flaw doesn't seem to have the priority to be fixed sometime soon (ever :-(.
There are 2 known problems when using PC/2 V2.00 together with NetScape's Communicator/2 4.04 beta.
Both problems have been already addressed by me and corrected for the current code level on my developing environment.
You may also download a preliminary fix for PC/2 V2.00. Though very unlikely, this fix may break other functions or applications, in which case I recommend to restore the saved original module.
After downloading the safest way to install the fix is to restart OS/2 into a command prompt (either by booting with the boot diskettes or via ALT+F1 during the boot blob), save the original PC2Hook.dll, and replace it with the one in the fix archive. Then restart OS/2. If you are experienced enough to replace a DLL in a running system, you may also just exit PC/2, save and replace the PC2Hook.dll and then relaunch PC/2.
The Lotus SmartSuite for Warp 4 1-2-3 will trap immediately when launching at 0001:0003bcde when running with the default configuration from the installation, even when the Titlebar SmartIcons have been disabled (what the SmartSuite README recommends). The fix for that problem is to either disable PC/2's SessionBar completely, or to ensure that it is not positioned at the absolute top or bottom of the screen (you can verify that by maximizing e.g. an EPM window, if the EPM window covers the complete screen, then the SessionBar is neither on top nor bottom of the screen.
The trap is caused as a result of PC/2 trying to query the titlebar text with WinQueryWindowText() of a window currently being repositioning (during WM_ADJUSTWINDOWPOS and WM_WINDOWPOSCHANGED). I think that WinQueryWindowText() which results in a WM_QUERYWINDOWPARAMS message is not correctly processed by Lotus 1-2-3 somehow causing a NULL pointer to be dereferenced.
This problems have been already addressed by me and corrected for the current code level on my developing environment.
You may also download a preliminary fix for PC/2 V2.00. Though very unlikely, this fix may break other functions or applications, in which case I recommend to restore the saved original module.
After downloading the safest way to install the fix is to restart OS/2 into a command prompt (either by booting with the boot diskettes or via ALT+F1 during the boot blob), save the original PC2Hook.dll, and replace it with the one in the fix archive. Then restart OS/2. If you are experienced enough to replace a DLL in a running system, you may also just exit PC/2, save and replace the PC2Hook.dll and then relaunch PC/2.
The Lotus SmartSuite for Warp 4 Approach application will trap at 0001:00000100 immediately after launching when running with the default configuration from the installation, even when the Titlebar SmartIcons have been disabled (what the SmartSuite README recommends).
Unfortunately I haven't yet found where the problem lies, even after trying to regress the code from the current development repository into PC/2 version 2.00 (as with the current code level I can't produce this trap). I currently do not have a fix for this problem, but I hope PC/2 version 2.10 will go into beta testing soon.
Even when not running PC/2 while Approach I noticed peculiar effects, e.g. I can't move AVIO windows (neither with the titlebar nor the move option of the systemmenu).
SmartSuite for Warp 4 seems to be instable even when not running anything else, my POPOPLOG.OS2 is full of various traps of it - and I haven't done more just to launch and terminate the applications! It seems that Lotus has successfully ported their buggy Windows bloatware to OS/2, if there were only more choice on OS/2 I would almost recommend to shoot it onto the moon (though buggy Windows bloatware refers not just to Lotus, it is industry standard now, even 3D games trap like crazy on my system (and gaming is the only thing I have a use for WIN95)).