VOICE Home Page: http://www.os2voice.org
Newsletter Index
< Previous Page | Next Page >
Feature Index
|
VOICE Home Page: http://www.os2voice.org |
January 2004
Newsletter Index
|
| By Karl Steinsky © January 2004 |
If you have OS/2 and Windows running on your private PC and you are accessing the internet with Warpzilla/Mozilla it may be interesting for you to read this article. The idea for the following configuration originated when I could not access certain emails, HTML files and downloaded files, because I was not booted to the right (current) operating system where these things have been stored. In other words, the files I could not access had been downloaded by the "neighbor" system. I had tried to implement this idea previously with Netscape Navigator, but I was not able to do so because it has fewer functions. Again, by way of preface: I tested and ran the Warpzilla/Mozilla functions "Navigator (Browser)" and "Email". I believe the other functions will also work but I did not test them.
Note: This works with Firebird and/or Thunderbird too, because we can assume that both products use the same profiles. I tested Thunderbird. But I could not test Firebird because it crashed permanently. So I have to wait for a later version.
For an explanation of concepts the following paragraphs are provided: Shared File System, Profile Files, Specials.
As shown in the configuration flowchart below it is necessary to have a file system which is accessible by both operating systems. In addition Warpzilla/Mozilla are using long file names, a mandatory requirement. The file system which complies to both conditions is the FAT32 file system. This can be provided in two steps. In the first step the connection between the FAT32 partition and OS/2 will be established by assigning a drive letter. In the second step the access method to the FAT32 file system will be provided. More details can be found under Installing Shared File System and internet addresses can be found at the end of this article.
Short note: The new DASD manager allows OS/2 to see each FAT32 partition on the PC like any other partition and can access it by the added FAT32 access software.
The following picture of configuration shows two separate profile directories instead of the preferred single one. The reason is the different addressing scheme of each operation system. Windows does not know HPFS file systems, therefore the letter assignment produces different results depending on the position of the partition. Maybe identical letter assignments could be established, but the consequence would be a total change of the disk configuration. The effort would not be justified by the new configuration. The two profiles have the advantage that the installation of both Mozillas can be independent. I am also not sure if one single shared profile would require identical versions of both Mozillas in both operating systems.
Note: If somebody prefers to create his/her own specific profile path for Mozilla, he/she can use the extracted procedure described at http://www.gemal.dk/archives/000178.html.
As far as I know, it is not possible to update PREFS.JS configuration file directly for address files (abook.map, history.mab) for emails. The opposite is true for the browser, because the file bookmarks.html can reside anywhere on the hard disks. That's bad for the mail side. So we have to select a way where both Mozillas get the same email addresses. This has to be done by copy procedures in both directions. Normally only one operating system can be active and running at the PC. Therefore only one Mozilla attempts to access the files at a time. I decided to implement the copy procedures at system start and at system close down (shutdown) of OS/2 by using REXX scripts which is easy to achive. The procedure uses one script called SYSSTART.cmd, which copies the address files from Windows to OS/2 at OS/2 boot, and another called SYSDOWN.cmd, which copies the (perhaps modified) files back. Both scripts will read a control file which contains the necessary info like paths for both profiles in both operating systems and any number of file names to be copied. In my example the file names are ABOOK.MAB and HISTORY.MAB. More see at Procedure to synchronize Profile Files.
The proper email files, all *.msf files and the filter file rules.dat reside in two so-called "local directories" for "server1" (email receiver) and "server2" (postage slots). According to the rules stored in file rules.dat the emails are stored in those subdirectories (compartments). The names of local directories are kept in the file prefs.js. The existing "local directories" stored there can have identical names in both profiles with the condition that the "server1" name (account name) in both profiles is identical per definition. The same applies to the "server2" definition. How to define it will be shown in Install Shared Email Files.
As already mentioned, it is particularly easy to access a shared bookmark file from both Mozillas and the same is true for a shared download directory. In each Mozilla it is possible to define the bookmark file which both Mozillas can access. Nearly the same applies to a download directory. For more see Install Shared Navigator (Browser) Files.
The "Quick Launch" feature as provided in Windows Mozilla can also be logically realized in Warpzilla. In both cases a copy of Mozilla will be preloaded into main memory. This is done by adding the parameter -turbo at start of Warpzilla. It makes sense to do this at the time of OS/2 system boot. The loaded version will nowhere be indicated on the desktop but the next start will be experienced as quick. To remove the preloaded version again, Warpzilla can be started by using -kill parameter. For the described procedure the -kill parameter is not used, because each Warpzilla task currently running should be killed at OS/2 shutdown by a "Kill" program. At system start the used SYSSTART script first copies the specified files (abook.mab...) from "windows profile" to "OS/2 profile", and then executes then the OS/2 start command for Warpzilla by using -turbo.
Note: If Mozilla version 1.5RC2 is in use or planned and Mozilla is started with -turbo, it may lead to a crash. In this case renaming mozturbo.exe, which resides in Mozilla's directory, to mozturbo.bak will solve the problem. I don't know whether this problem is valid for all versions of 1.5xx.
The OS/2 shutdown procedure mentioned above is a little bit different, because there is no "System shutdown" folder available. You can create an object for the SYSDOWN script with the provided icon, which is added to the desktop and makes it easy to close the system. This REXX script will first terminate all currently running Warpzilla task (windows) by calling one of the selected kill programs. Through that function, the "reserved" files in the path of profile will be released and this enables the REXX script to copy back all defined files. After that the proper shutdown of OS/2 follows. Both programs for killing and shutdown can be downloaded from Hobbes (see reference table). Hobbes has several programs for selection. The two necessary programs in the example have been selected and partially tested by myself and can be downloaded via the links given below. The SYSDOWN script can be changed according to the selected programs. More can be found at Install Specials.
First, download Netlabs's ZIP file containing FAT32 software and Daniela Engert's DASD manager (see references) and decompress it. For better understanding please read the descriptions included. I created and formatted the FAT32 partition using Partition Magic under Windows. Remember that the minimum partition size for a FAT32 partition is 512MB.
This section can be skipped if OS/2 Warp Version 4.5 is in use (LVM). With the following changes in the file CONFIG.SYS the DASD manager will be replaced. The parameter /MP:(*.*) is intended for "removable media" (like ZIP drives) and may be omitted in our case.
BASEDEV=IBMATAPI.FLT REM *************************** REM BASEDEV=OS2DASD.DMD /MP:(*,*) BASEDEV=DANIDASD.DMD /MP:(*,*) REM ***************************
With this modification OS/2 can see any FAT32 partition, which means the partition gets a letter assigned.
In the meantime, FAT32 support has been developed further. The official release is known as FAT32097 and consists of the file FAT32097.ZIP or of the file FAT32097.WPI. The WPI file has to be installed with WarpIN - an option for easy software installation. WarpIN is freeware which can be downloaded from http://www.xworkplace.org. The ZIP file requires manual installation, which is described shortly as follows.
As described in FAT32.INF from the ZIP archive, the following five files (FAT32.IFS, CACHEF32.EXE, F32STAT.EXE,F32PARTS.EXE and F32MON.EXE) have to be copied into the \OS2 directory. And the file UFAT32.DLL has to be copied to OS2\DLL. It will only be called by the CHKDSK program. The CONFIG.SYS file has to be extended by the following statements:
IFS=D:\OS2\HPFS.IFS /CACHE:2048 /CRECL:32 /AUTOCHECK:DFGN REM FAT32 Support --------- Start -------------------------- IFS=D:\OS2\FAT32.IFS /CACHE:2048 CALL=D:\OS2\CACHEF32.EXE /D:1000 /B:500 /M:5000 REM FAT32 Support --------- End ----------------------------
As shown, the two IFS statements will follow immediately the statement for HPFS file system which can be found at beginning of the command list. Both REM statements are used as an eye-catchers. With this change OS/2 is now able to access all FAT32 partitions. In case of error correction it make sense to switch to Windows and run Scandisk. CHKDSK under OS/2 corrects "lost clusters" only.
The two REXX scripts and the control file, contained in the extra ZIP file, are examples for the section which follows. The extra ZIP file can be downloaded, see URL-Addresses.
Tip: In case the profiles in both operating systems have not been newly defined, we will find the OS/2 profile path in the Warpzilla main directory starting with the name:
\Mozilla\Profiles\user\xlm36gfg.slt
with xlm36gfg.slt being a name generated during installation which will be different. For Windows it looks like:
C:\Windows\Application\Mozilla\Profiles\user\QFVU2I46.SLT
As just mentioned for OS/2, the same is valid for QFVU2I46.SLT. As described in the concepts, the script SysStart.cmd is responsible for copying the specified files from the Windows profile to the OS/2 profile. For testing you can set the variable Log_write = 1 in the script, which creates a log file with the name SYSSTART.LOG and contains information about the run. The script expects a parameter naming the control file (path/file name). Here is an example of contents:
MOZ_WIN_PFAD = C:\Windows\Anwend~1\Mozilla\Profiles\T-Online\QFVU2I46.SLT MOZ_OS2_Pfad = G:\Mozilla\Mozilla1\BIN\Mozilla\Profiles\default\xlm36gfg.slt ABOOK.MAB HISTORY.MAB
The keyword MOZ_WIN_PFAD specifies the profile path for Windows system and must be entered as shown. Same is valid for the keyword MOZ_OS2_PFAD which specifies the profile path for OS/2 system. The next lines contain the names of files to be copied. One name per line. The number of lines can be as many as you like starting at line 3. One should keep in mind that file names longer than 8 characters (e.g. downloads.rdf) lead to copy errors, if the Windows partition owns the FAT file system. In this situation, a new profile must be created on a FAT32 partition.
If the test run of SysStart.cmd and the contents of log file indicates "all OK" then you can assign the supplied icon to the script if you like and place it in the System Startup folder.
The script SysDown.cmd performs the opposite of SysStart.cmd and is using the same control file. The log function can also be used as mentioned before. First an adjustment in the REXX script is needed. According to your selection of both programs (kill and shutdown) definitions have to be added or modified. The programs I am using cannot be distributed because there is no known status (free or share). In URL Addresses at the end you will find my selection from Hobbes, which i have partially tested for this article.
Tip: Note the REXX statement SysSleep 3 in SysDown script, which follows the call of the kill program. The "3" indicates the seconds of wait time. It may be possible, depending on number of open Warpzilla windows and PC speed, that the specified wait time is too short or too long. The result could be that copy processes are not done because the files to be copied still have not been freed by Warpzilla or the script SysDown.cmd runs to long. It can be corrected as needed.
The goal of the description is to make as few changes in the configuration as possible.
In the main window of "Warpzilla -mail" you can see in the left part the structure of accounts starting with the account e.g. pop.btx.dtag.de with all of the email folders (Inbox,.....) followed by the account Local Folders with or without email folders which can be added by the user. See next picture.
This structure will reside in the Warpzilla's profile on the partition. The account name pop.btx.dtag.de can be found as subdirectory in the path string \mail\pop.btx.dtag.de starting in the directory of profile. Same is true for Local Folders.
If you attempt to put the account subdirectory (pop.btx.dtag.de) onto a FAT32 partition, you can do it in two steps:
Step 1: creation of the new path onto FAT32 partition, e.g. x:\Mozilla\Emails\, followed by the copy process (XCOPY or file manager) of account directory (pop.btx.dtag.de) with all the contents included. The result is a new email path x:\Mozilla\Emails\pop.btx.dtag.de.
Step 2: Mozilla must be informed about the configuration change, as follow:
In order to make the correction of the email account (pop.btx.dtag.de), display the current definitions as shown at next picture, by clicking the account and View setting for this account (at right part of window)...
In the next picture please click Server Settings below the name of account. (If it is not displayed, then the account name must be clicked first.) Now you can see at the right side of the window just below, the red ellipse, the place Local Directory where the current location is for storing emails received/sent...
Enter here the new email storage x:\Mozilla\Emails\pop.btx.dtag.de, that's all. The figure shows a different specification.
If you would like to also place the account directory Local Folders on the FAT32 partition then you can do it in two steps again:
Step 1: Copy the account directory Local Folders by the copy process (XCOPY or file manager) to x:\Mozilla\Emails\. The result is a new path x:\Mozilla\Emails\pop.btx.dtag.de. If XCOPY will be used, perhaps you should remember that the folder path must be put into quotes because one blank is in the name.
Step 2: Mozilla must be informed about the configuration change, as follows:
Supplying the new path for the Local Directory is done the same way as shown by the following pictures. Click on Local Folders and then on View settings for this account...
Now you can see the current contents for Local directory...
... enter the new path. That's all. The figure shows a different specification. Now you can test. The best is a new start of Warpzilla. This is all you need to do for Warpzilla (OS/2 side).
For Mozilla (Windows side) only the second step is needed. The procedure is the same (except different device declarations). I am sure you will first change the account names according to OS/2, so that it will work correctly and improve the clarity. You will lose the emails kept in Mozilla. Except the email folders will be saved (copied) at another location for renaming. Of course the new names must be different. Now they can be moved into the new email directories and kept as long as needed. Personally, I create a backup before I make any changes, mostly of the complete partitions to make things easy.
Note: The Local Directories entered in the last few windows can also be defined by adding two lines (statements) to the user.js file which will be described next. The statements appear as follows:
user_pref("mail.server.server1.directory", "J:\\Mozilla\\Profiles\\pop.btx.dtag.de");
user_pref("mail.server.server2.directory", "J:\\Mozilla\\Profiles\\Local Folders");The first line defines the shared path of the account for receive/send. The second line specifies the shared path for email slots to which the received and sent emails are distributed and stored according to specified rules.
Browser files of interest and shared used are:
the URL file (bookmark.html)
the directory for download of files (of course it can be changed at any time before downloading)
and perhaps the file maintained by "Download Manager" (downloads.rdf)
The first two points are established by creating a file with the name user.js. For example the file user.js can be created using EPM with the name user.js in the profile path, which contains the prefs.js file, and the following text should be entered...
user_pref("browser.bookmarks.file", "J:\\Mozilla\\Profiles\\bookmarks.html");
user_pref("browser.download.dir", "J:\\Download\\Telekom");... and saved. The first line describes the location of the shared "bookmark.html" file. The second line defines the path of download storage which could also be changed at the beginning of download.
Another way to modify both definitions is to display the configuration by using URL about:config and do the changes at the display. A prerequisite for this is having Mozilla version 1.3 or above.
The user.js file must be supplied for both Warpzilla and Mozilla and be added to both profile directories according to the drive letters. The update for the download manager file belongs to the OS/2 system.
The last point of the list: if the download manager with its own file should be used, then the control file for the copy processing gets the file name of downloads.rdf added as shown...
MOZ_WIN_PFAD = C:\Windows\Anwend~1\Mozilla\Profiles\T-Online\QFVU2I46.SLT MOZ_OS2_Pfad = G:\Mozilla\Mozilla1\BIN\Mozilla\Profiles\default\xlm36gfg.slt ABOOK.MAB HISTORY.MAB DOWNLOADS.RDF
The URL-Addresses contain one program each for killing and shutdown. They have been tested shortly. Both REXX scripts plus an example of a control file are contained in the extra Zip file mozilla_scripts_en.zip. If the proposed examples are used then no additional changes should be needed. The scripts contains comments and remarks in case there are changes necessary.
References:
|
Feature Index
editor@os2voice.org
< Previous Page | Newsletter Index | Next Page >
VOICE Home Page: http://www.os2voice.org