VOICE Home Page: http://www.os2voice.org

October 2002 [Newsletter Index] [Previous Page] [Next Page] [Feature Index] editor@os2voice.org

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 tips@os2voice.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.

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

and this is my call in config.sys for LOCKCDR.FLT:

BASEDEV=LOCKCDR.FLT -I:"AOPEN CD-RW CRW2440"

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.
   

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.

You could try using the cdrecord/2 package to blank your CDRWs :- > http://www.geocities.com/SiliconValley/Sector/5785/cdrecord/cdrecordmain.htm

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

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.

http://www.mydigitaldiscount.com/display_product.cfm?product_id=25

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.

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

DLLBASING	VALUE
ON	QSV_TOTAVAILMEM = 194945024
OFF	QSV_TOTAVAILMEM = 247840768
ON	QSV_MAXPRMEM = 274857984
OFF	QSV_MAXPRMEM = 339345408
ON	QSV_MAXSHMEM = 240779264
OFF	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]
editor@os2voice.org
[Previous Page] [Newsletter Index] [Next Page]
VOICE Home Page: http://www.os2voice.org