VOICE Home Page: http://www.os2voice.org
We scan the Web, Usenet and the OS/2 mailing lists looking for these gems. Have you run across an interesting bit of information about OS/2 or eComStation recently? Please share it with all our readers. Send your tips to firstname.lastname@example.org. If you are interested in joining a particular OS/2 mailing list, check out the VOICE Mailing List page for subscribing instructions for a large variety of existing lists - http://www.os2voice.org/mailinglists.html.
Editor's note: these tips are from OS/2-eComStation users and in some cases can not be verified by myself. Please heed this as a warning that if you are not sure about something, don't do it.
What it does is override the default 0x10000 load address offset compiled into most DLL's. This wastes 64K of linear address space per DLL. However, when the option is off, the loader has to relocate the code when loaded so there's a time cost.
See the ConfigTool database (cfgtool*.zip on Hobbes) for details.
Actually, there is only a single difference between W4 and UNI: Uni has the DosSetThreadAffinity (sp?) API implemented (which allows to associate a thread to a processor), while W4 returns 'invalid function'. This is a method to find out which kernel you have. Of course, since UNI is SMP for a single CPU only--a contradiction in terms, obviously--you won't be able to use this API really; but at least it will allow software which was specifically designed for SMP to run on a single CPU.
The eCSguide installer is not working properly for Java1.3 The java 1.3 runtime and development kit must be installed at the same time. Make a work directory on your hard drive. Copy both \softwarechoice\java13\javainrt.exe and \softwarechoice\java13\javaintk.exe from eCS CD3 to the work directory.
Move to the work drive and directory and run the following commands:
SmartSuite doesn't like a lot of empty space on the drive it's being installed to. I got spacehog from hobbes (http://hobbes.nmsu.edu/pub/os2/util/disk/spacehog.zip), ran space32.exe, and installed with no problems. No need to execmode the programs, no filesystem problems, nada. I suspect that this install problem could show up in many ways.
I recently switched to the SDD(IBM) drivers and everything worked pretty good except that I lost all my icons in the SYSBAR task switcher. Eventually found the CUSTOM feature in the Sysbar Properties(display). Played around with the numbers and got my icons back. Not all numbers give you the icons, you have to test which ones do.
So did mine - beautiful productions - both CW and manual. Unfortunately no longer any SPG support for OS/2. In case there are others with V2 who also only had 7 online tutorials - they can do a search on Hobbes etc. for cworkslesson8.zip (~3MB) which is TECH8.INF - working with image masks.[Editor's note: It is reported that the tutorials available on hobbes are in fact different then the 7 available on the Color Works v2 and are definitely worth downloading.]
<DSOM_eCS> Something like zip warning: new zip file left as: zia00058?
<DSOM_eCS> zip I/O error: Permission denied.
<madodel> Something like that
<DSOM_eCS> zip error: Could not create output file (was replacing the original zip file).
<DSOM_eCS> Yes, I saw that problem too....but that's not a Norman problem....that's a downlevel JFS fix.
<madodel> The zips it creates are fine, they just have weird names and give the error message
<DSOM_eCS> I solved the problem by using JFS0622, removing the JFS volume, creating a new JFS volume and long formatting for JFS.
<DSOM_eCS> Yeah, the zia00058 etc. files are zip temp files....so I guess whether or not they are complete depends on the user's system.
I found the following file on hobbes:
From the readme:
"These are all the TrueType fonts taken from Microsoft's "TrueType core fonts for the web" packages, which are available at http://www.microsoft.com/typography/fontpack/default.htm
I made this package because the fonts on MS's web site are available as a self-extracting Win32 EXE only, which most OS/2 users can't access. So here they are in a simple zip file."
It's common knowledge that IBM Works "won't work" with the Warp 4 convenience pack - even though the suite does work with eCS, which is essentially the same thing.
After installing the CP for Warp 4, running the script ibmwdesk.cmd will recreate the desktop objects and config.sys entries for IBM Works, but the programs will not run.
The reason seems to be that the files ien30pde.dll and fpwrec.dll are missing*. They can be found in \os2\dll in a non-CP warp 4 installation, or in \os2image\fi\bonuspak\ibmworks on the warp 4 CD. I've copied them to \bonuspak\ibmworks rather than <CP_drive>:\os2\dll in order to reduce the risk of conflict. Everything seems to be OK so far...
* I used the nifty program pmdll by Arthur van Beek and Steven Levine to discover this.
One way around this is may be to use OS/2's little known "EXTPROC" command, to specify the "external processor" to run your perl scripts.And Martin Vorlaender added:
You have to rename your perl scripts to be *.cmd files, and insert a line at the start like: EXTPROC W:\MyPath\perl.exe
This will cause OS/2 to invoke W:\MyPath\perl.exe to run the script. HOWEVER the perl interpretter would have to know to ignore the EXPROC line - possibly the OS/2 version does, I've no idea, I don't have it! Type help EXTPROC for more info.
This is similar to Unix's "#!/bin/myshell" thang.
It does. From README.OS2:
Alternately, if you use OS/2-ish shell, like CMD or 4os2, put the following at the start of your perl script:
extproc perl -S -my_optsrename your program to foo.cmd, and start it by typing
foo arg1 arg2 arg3Note that because of stupid OS/2 limitations the full path of the perl script is not available when you use `extproc', thus you are forced to use `-S' perl switch, and your script should be on the `PATH'. As a plus side, if you know a full path to your script, you may still start it with
perl ../../blah/foo.cmd arg1 arg2 arg3(note that the argument `-my_opts' is taken care of by the `extproc' line in your script, see the section on "`extproc' on the first line").
The driver will only recognize the card if it is on PCI bus 0. Some machines have PCI bus 0 and PCI bus 2.[Editor's Note:This tip applies to some other PCI device drivers as well, e.g. those with the Aureal Vortex (8820) chip like the Terratec Xlerate.]
Motherboards with more than 4 PCI slots can have two PCI busses glued together with a PCI to PCI bridge. When the motherboard boots the display of PCI devices will show the bus number in the first column then the device ID and other stuff. (At least the ones I have show that). The first few PCI slots (at least 4) are on bus 0, the AGP slot is on bus 1 and the additional PCI slots are on bus 2.
The OS/2 WinTV drivers will not detect the card on bus 2 (its a bug...) Try moving the card to one of the slots next to the AGP card, they are usually on bus 0.
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org