Virtual OS/2 International Consumer Education
VOICE Home Page:
October 2002

[Newsletter Index]
[Previous Page] [Next Page]
[Feature Index]

OS/2 Tips

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 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 -

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.

August 25, 2002 - From the news group on the RSJ news server, comes our first tip of the month from Lars Erdmann with suggestions on getting an IDE CDRW drive working with the RSJ CD Writer software.:
If it is a new ATAPI device, you shouldn't worry. You will have a good chance that it will work, you might be forced to fumble with cddrv.inf to set the correct parameters because RSJ sometimes does not detect the drive correctly.

If RSJ does not detect correctly, use "cdatapi" as driver and "RAW-3" for DAO-Mode. If DAO still won't work, try out "CUESHEET" in cddrv.inf. You will also need the SCSI-ID (the ATAPI-ID shows up on bootup and is usually identical to the SCSI id). Also, if you can't figure out the SCSI-ID you can let RSJ do the job (by specifying LOCKCDR.FLT without parameters) and then look onto the "System" tab of the CD-Writer control object. Then you will get an idea how the string is supposed to look like in cddrv.inf.

Here is an example for my CD-RW:

AOPEN "CD-RW CRW2440 " 1.00 "AOPEN CD-RW CRW2440"
N/A cdatapi ATAPI RAW-3
and this is my call in config.sys for LOCKCDR.FLT:

August 27, 2002 - On comp.os.os2.programmer.misc Usenet group comes a tip which resulted from a plea for information on how to control how DLL are loaded. Rich Walsh, a frequently cited source for OS/2 tips, and the author of DragText:
I did a *lot* of testing (and rebooting). Here's what I found:

  1. BEGINLIBPATH won't accept a ".", but it _will_ accept ".\."

  2. You can put "SET BEGINLIBPATH=.\." in config.sys to achieve the desired result when LIBPATHSTRICT=T is in effect. OTOH, putting ".\." in LIBPATH is as ineffective for this purpose as the standard "."

  3. Putting "SET LIBPATHSTRICT=T" in config.sys has no effect. You must turn on this feature in the target process, or in the process from which you will start the target app. In practical terms, you'll have to enter this at a command line, then run the app from that same command line.

    A word of explanation for onlookers: neither BEGIN/ENDLIBPATH nor LIBPATHSTRICT are true environment variables. When BEGIN/ENDLIBPATH were added to the base os, cmd.exe was modified to examine each SET statement entered. If it is "SET BEGINLIBPATH=" or "SET ENDLIBPATH=", cmd.exe calls the DosSetExtLIBPATH() API to set these values in its process. Said values will be inherited by any process it starts.

    Apparently, the base os was also modified so that when these statements appear in config.sys, they are made global and are inherited by all processes. It appears that when LIBPATHSTRICT was added, cmd.exe was again modified but the base os was not. Thus, "SET LIBPATHSTRICT=" works when entered at a command line but not when entered in config.sys.

  4. Until the base os is suitably modified, it seems that the only way to make "LIBPATHSTRICT=T" global (or nearly so) is to create a facility akin to my RWL util which can enter the shell process (pmshell #1) and set it there. Since pmshell is the parent of all processes started after it loads, this would have the desired effect.

In addition, Mikus Grinbergs added the following:
As someone already pointed out, use 'set LIBPATHSTRICT=T'.

It has to be issued from the session that it affects - it will not work if placed in config.sys

My concept (right or wrong) of how it works -- when it is set, OS/2 goes stepping through the effective LIBPATH looking for an occurrence of a DLL with the desired filename. When one is found, it is loaded into memory and "hooked" to the requesting program. However, if memory already contains a DLL with the identical filename and identical __filepath__, then it is that previously-loaded DLL that is "hooked" to the requesting program (thereby avoiding a second load of that identical-path DLL).

Note that having '.;' in BEGINLIBPATH will not be effective with LIBPATHSTRICT -- but having '.\.;' will work.

Also note that existing Odin versions will branch to zero when 'set LIBPATHSTRICT=T' has been specified for the session.

September 5, 2002 - Yet another tip this month from the news group on the RSJ news server, This one concerning erasing CDRW media. Peter Brown suggested:
You could try using the cdrecord/2 package to blank your CDRWs :- >

You will probably need the CDRTools front end which has a link on the same page.

Botka Laszlo responded that this tip was helpful:
I tried cdrecord + audio cd creator. The Fast , All, Last-session Blanking was not successful, the Unclose last session at first complained about some OPC error, but then erased the CDRW. After this I formatted with RSJ, and can use normally. Thanks for the tip.

September 5, 2002 - Someone was looking for Compact Flash reader that works with OS/2 on Usenet group. John Varela recommended the following:

Hot Removable IDE Compact Flash IBM MicroDrive Reader Writer $19.99

I ordered it and the total was $27.49 with shipping. I ordered it on Tuesday, it arrived on Thursday, I installed on Friday, and it works as advertised. The only problem I had (other than my own silly mistakes) was that the unit is so small that the IDE cable couldn't reach it until I relocated my IDE and floppy drives. It appears that IDE extender cables are not readily available.

September 7, 2002 - There are a lot of undocumented CONFIG.SYS entries in OS/2. When I read something about one, even if I can't quite make sense of it, I like to pass it on in case someone who is reading can benefit from it and may find it useful later on. Here is what Trevor Hemsley writes about DLLBASING=:
I have a small program that uses DosQuerySysInfo() to get info from OS/2 about the system. It writes a bunch of stuff to the screen. I ran it before and after DLLBASING=OFF to see the difference and, having removed the lines about timestamps and uptimes, this is the difference
QSV_MAXPRMEM = 274857984
QSV_MAXPRMEM = 339345408
QSV_MAXSHMEM = 240779264
QSV_MAXSHMEM = 309395456
The help for DosQuerySysInfo says:

QSV_TOTAVAILMEM - Maximum number of bytes of memory that can be allocated by all processes in the system.

QSV_MAXPRMEM - Maximum number of bytes of memory that this process can allocate in its private arena.

QSV_MAXSHMEM - Maximum number of bytes of memory that a process can allocate in the shared arena.

[Feature Index]
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: