VOICE Home Page: http://www.os2voice.org
[Previous Page] [Next Page]
Editor's note: these tips are from OS/2 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.
Right-click somewhere on the row of tabs and a context menu showing all notebook pages will pop up.
First from Lorne Sunley, for anyone looking for SES for Warp 3:
If you are running Warp 4, SES is an option on the "Selective Install" program.
If you are running Warp 3 you have to download the SES from the IBM FTP site. The URL is: ftp://ftp.software.ibm.com/ps/products/os2/warp.update.kit/warpses/
Read the warpses.txt file - it has the installation instructions for the SES code that is contained in the security.bbs file. This file is compressed using PACK so you have to use UNPACK to decompress it.
Next from Scott E. Garfinkle:
Don't forget to re-apply FP40 or later if you have Warp 3 (or WSSMP) and put on this update. You need to do this to get the SES updates (warpses is about FP17 level). For Warp 4, you have to (re-)apply FP10 or later after doing Warp 4 selective install of SES.
I have a mixed OS/2 v4 and Win 98 peer to peer network. The OS/2 machine has a scsi adapter with a scsi cd-rom and a scsi scanner attached to it. I can set up sharing on the cd-rom (as a directory) so that the win 98 machine can see and read it. Is there a way to set up sharing on the scanner ?The above was confirmed by Bill Haybyrne:
Sure. Put a SCSI card in the W95 box, set it to a different SCSI ID than
the one in the OS/2 box, and just plug both into the scanner.
No, I'm absolutely serious. I've seen it done! A friend had a SCSI scanner and Zip drive and got tired of swapping the cables back and forth between his PC and his PowerMac... so we just chained out the back of the scanner to the external SCSI drive on the Mac (after setting the Mac's SCSI interface to ID6) and voila! Not only could both machines use the scanner and Zip, but the Mac could see the PC's SCSI drives, and the PC showed two CD-ROMs (when we clicked on the new one, the audio CD in the Mac started playing :)
A few weeks ago I asked a question about sharing a scsi scanner between an OS/2 box and a W98 box. Matt Ion suggested "Put a SCSI card in the W95 box, set it to a different SCSI ID than the one in the OS/2 box, and just plug both into the scanner." I have to confess that his suggestion caused me to fear that too long in the cold clime of the North had finally slowed down Matt's thought processes.Though Julien Pierre offered this caution on the above:
This weekend, perhaps due to too many hot Washington DC summers, I decided to try Matt's suggestion. Absolutely Amazing!!! It worked...exactly as he described.
Thanks, Matt. I guess you can afford to stay in the cold a little longer.
I would only use this method to share read-only DASD SCSI devices. But don't try sharing a SCSI hard drive this way if you intend to write to it, since both computers could be writing to it at the same time and data corruption will likely ensue. This will be particularly bad since each system will maintain its own read/write cache for the filesystem. Disabling all disk caches would help reduce this risk but would still not eliminate it, since you do not control the time when each system does its I/O to write and they could still be writing to the same area, particularly on a file system like FAT. I would put the SCSI disk in "write protect" mode physically via a SCSI jumper before I would even try booting the two systems with the SCSI hard drive shared between both buses.
A scanner is still not entirely safe, since potentially both computers can send commands to it that will produce erratic results. For example, if you start scanning simultaneously from your OS/2 and Win95 system, some screwups will occur, and probably both scans will fail, but beyond a retry nothing bad will happen. Sharing a tape drive would be a similar case as long as the tape is write-protected; although you may damage the drive if multiple computers are sending seek/read commands to the drive at once. Again, don't take the risk of backing up to a tape if the drive is shared.
SCSI CD-ROM/DVD drives and other read-only devices are probably the ideal devices to share, since there shouldn't be any restrictions on what you can do with the drive when it's shared as opposed to hooked to a single machine.
Rule of thumb: any drive letter found at a proper place in a valid WPS object is adjusted by the WPS if the object in question is targeted to another drive letter. Of course this doesn't include data stored in the OS/2 INIs which are *not* WPS objects (some software stores pointers to themselves there).Here's some more on the subject from Buddy Donnelly:
So, the basic operation of moving an existing desktop to another drive letter is *move* the "Desktop" tree from the source drives object to the target one. If the target drive letter doesn't yet exist, create it beforehand. Then reboot to a command line window only (no WPS started!) and issue "XCOPY source: target: /H /O /T /S /E /R /V". This moves the rest of your boot drive to the new target; don't forget to adjust CONFIG.SYS. If required run "SYSINSTX target:" to make the new target drive bootable, You may need to add the new target to your favourite bootmanager as well.
If you need to transplant a desktop to another location, save away \OS2\OS2.INI, \OS2\OS2SYS.INI and the full \Desktop tree including *all* extended attributes. This needs to be done without PM active! Restore the mentioned items to the new target and you're done...
Using these operations I migrated several OS/2 2.1, Warp3 and Warp 4 installations to several new drive letters (D: -> E: -> F: -> ...), changed the underlying hardware and disk drives quite often, cloned existing desktops or full installations to new target drive letters (for testing purposes), and on and on... No magic, just basic WPS features are involved. Ciao
Good stuff (as usual, Dani) and here are a couple of other tiny things to add.
1. All versions of OS/2 appear to support (tolerate) "relative" path locations in CONFIG.SYS. You can, therefore, make 1 CONFIG.SYS that will work the same from any boot drive. For instance, this statement: DEVICE=C:\OS2\BOOT\OS2CDROM.DMD can just as easily be DEVICE=\OS2\BOOT\OS2CDROM.DMD
BASEDEVs of course always point to either the boot-root or \OS2\BOOT on the boot drive.
2. There's a lot of danger in having *multiple* \DESKTOP trees visible to OS/2, and you have to take special care if you run CHECKINI /C on a system with multiple visible desktops. Get the most recent version of WPTOOLS and read the CHECKINI docs for details on the startup parameters to use.
INFOZIP works quite well at packaging the pertinent files for transfer, by the way. In fact, this is a side feature of BOOTSET, to do a quick-and-dirty archive of the important Desktop files and structures.
IBM changed the behavior of one the API's. Now, the resource monitoring has to be turned on explicitly. Before, this was not the case. Check on Hobbes. Someone wrote a small app, which you can put in the startup folder, that will turn on the monitor.
FP14 also breaks Object Navigator details view. You must start ON in icon view or it may hang.
Sure - I have the same preference screen problem. you can get to each tab by doing this:
1) Give focus to cancel button (click on cancel, but don't let go of the mouse button until after you've slide the pointer OFF cancel)
2) hit TAB
3) hit cursor RIGHT
4) you should now see the next preference page
5) repeat from step 1 to see each page
Look at Help-> About plugins, and determine the name of the plugin DLL (NPSWF2.DLL, in this case), then go to x:\NETSCAPE\PROGRAM\PLUGINS and remove that file (move it somewhere else, in case you want to use it again, by simply moving it back into the PLUGINS directory). You can do this with almost all of the plugins (I suspect there are a couple that should not be messed with).
So far, I have not seen any problems with the flash plugin (the DLL is dated 6/29/2000, which is the latest that I have heard about, and is supposed to be the last beta release, but that may have changed). I did have some problems with the first beta, but that is long gone.
From my earlier post:
CID installs needed to explicitly state the inclusion of the
in the install (this keyword was omitted from the sample
with the following:
You will find references to DXCOMP1 in FIBASE.RSP, in the OS2\INSTALL
directory, where the actions for the installation (and prerequisites)
To do that you need to rename the file to "TRACK01.TRK" and copy it to the directory where your CD-VIEW is pointing in the Hard-Drive, and it will work like a charm
MAKEINI OS2.INI LOCK.RC
I assume this is a non-destructive since it doesn't give any warning, but you
may want to backup OS2.INI before you do this.
Note that I have not yet personally confirmed all parts of the (2) method below, since I've taken (1) as my recovery method.
The summary is really simple, for environments including FAT32 which have become unusable ("OS/2 is unable to operate your hard drive") and/or OS/2 is no longer installable, by virtue of using FP13+ FDISK:
(1) use the old (pre-FP10) FDISK to re-create Boot Manager, and stick with OS2DASD.DMD, you don't have to reinstall anything, all pre-existing OS/2 partitions will return to operability, and you'll be able to reinstall OS/2 once again if you need to.I haven't tested (2) for myself yet, as I've taken (1) as my particular recovery method. However in the DaniDASD.DMD environment I believe FAT32.IFS should still assign high letters to FAt32 partitions, which would be for the same FAT32 partitions as are already low lettered by DaniDASD.DMD (through its "virtual volume" method)... but I don't know that for sure.
Your drives will show low letters only for FAT16 and HPFS.
FAT32.IFS will give high drive letters to FAT32 as it always has.
(2) use the new (FP10+) FDISK to create Boot Manager, and install DaniDASD.DMD to your installation diskettes (it will work on both Warp 4 and Warp Connect), along with SET COPYFROMFLOPPY=1. You'll have to do a complete reinstall of all OS/2 partitions and application software, as all partition drive letters will most likely change.
Your drives will show low letters for FAT32 as well as for FAT16 and HPFS. EVERY partition will be given a letter, and FDISK will show this, and Boot Manager menu partition letters will match this.
But if that's what happens, the low lettered drives would still be unusable for read/write, with the high lettered ones from FAT32.IFS being the ones you would use to read/write FAT32.
However again, I haven't confirmed all parts of (2) and its interaction with FAT32.IFS. But it sounds reasonable.
[Previous Page ] [ Index] [Next Page ]
VOICE Home Page: http://www.os2voice.org