|
|
||
|
|
|
|
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|
Onder OS/2 Warp draaien vrijwel alle 16 bits Windows programma's. Die ondersteuning was er al in de eerste 32 bits OS/2 versie 2 (1992). Ook biedt OS/2 ondersteuning voor zogenaamde 32 bit subset (Win32s) versie 1.25 Windows programma's.
Maar speciaal voor Windows 95 en 98 en NT geschreven 32 bits Windows programma's draaien niet onder OS/2. Hiervoor zult u Windows 9x of NT moeten booten. Bijvoorbeeld via Virtual PC.
Overigens kunt u wel een poging wagen om via het in 1997 door Sander van Leeuwen opgezette Win32-OS/2 Project, en nu ondergebracht in het ODIN project van OS/2 Netlabs, 32 bits Windows applicaties onder OS/2 aan de praat te krijgen. Even rondneuzen in de Odin Compatible Applications is zeker de moeite waard. Voor de installatie zie de serie Manual installation of Win32-applications using Odin van Herwig Bauernfeind.
Vooralsnog waag ik mij daar nog niet aan. De pogingen van IBM en Lotus om Lotus Smartsuite voor Windows m.b.v. de Open32 bibliotheek van IBM naar OS/2 te porteren leverden een traag (maar wel betrouwbaar) werkende SmartSuite voor OS/2 op. Het was de belangrijkste reden voor mij om mijn Pentium 75 naar de Celeron 400 te upgraden. Daarop loopt het naar tevredenheid, maar veel trager dan onder Windows 95 of 2000. Kunt u over 16 bits applicaties beschikken: bijv. Word voor Windows 6, dan wint u veel aan snelheid en mist u alleen de ondersteuning van lange bestandsnamen. Ze zijn voor de OS/2 en Windows 9x gebruiker zeker nog de moeite waard.
Ik zie daarnaast nog genoeg mogelijkheden met OS/2 applicaties. Met StarOffice 5.1 heb je een zeer bruikbaar (en bovendien gratis) pakket. Via het netwerk heb ik bovendien de beschikking over veel open source Linux X applicaties die het prima onder de snelle Xfree86/OS2 server doen.
Verschillende versies van OS/2 Warp gebruiken verschillende manieren om 16 bits Windows programma's onder OS/2 te draaien (Win-OS/2).
Microsoft en IBM hebben m.b.t. technieken in Windows en OS/2 veel kruislicenties. Dit stamt nog uit de tijd dat zij samen aan OS/2 versie 1.X werkten, de beoogde opvolger van Dos. Zo gebruikt Microsoft door IBM ontwikkelde technieken en IBM bijv. het HPFS van Microsoft. In 1993 kwam aan de samenwerking tussen IBM en Microsoft een eind. IBM verloor het recht om aan de Windows code te sleutelen.
Huidige versies van OS/2 nemen de broncode van Microsoft Windows 3.1, die IBM sedert 1993 van Microsoft in licentie moet nemen, als uitgangspunt. Omdat Windows 3.1 in technische zin geen nieuw besturingssysteem, maar een slechts een grafisch DOS programma is, heeft OS/2 weinig moeite een of meer Windows sessies in Virtual DOS Machines (VDMs) te draaien. Er is slechts een patch (aanpassing) voor nodig en die betreft het geheugenbeheer (zie hieronder).
Sommige OS/2 versie die Windows applicaties draaien hebben als label "for Windows users". Deze versies vereisen dat u over de originele Microsoft Windows 3.1(1) diskettes beschikt. Het gaat om "OS/2 2.11 for Windows" (1993) en"OS/2 Warp 3 for Windows", alias the "Red box " (1994). Ze bevatten geen eigen Win-OS/2 code, om op de voor Windows gebruikers anders dubbele licentiekosten te besparen.
In dit geval kunt u Windows 3.1(1) desgewenst ook onder MS-DOS draaien als u Windows 3x op een FAT16 schijf installeert. De voor Win-OS/2 benodigde bestanden worden door het OS/2 installatie aan de Windows directory toegevoegd en er vinden aanpassingen plaats in de WIN.INI en SYSTEM.INI bestanden.
Onder DOS neemt Windows 3.1 tijdens het laden het geheugenbeheer van de DOS DPMI server over1. Deze wordt geleverd door de stuurprogramma's EMM386.EXE en HIMEM.SYS. D.m.v. een patch ("Warp hooks on Windows") wordt voorkomen dat Windows dit met de DPMI server van de OS/2's VDM (Virtual Dos Machine) probeert te doen. Een zelfstandige DPMI server die aan het fysieke geheugen komt zou de stabiliteit van OS/2 direct ondermijnen. Door onder OS/2 tijdelijk een verandering in de Windows programmacode aan te brengen (dat is wat deze patch doet) draait Windows vervolgens als de Dos toepassing en DPMI client Win-OS/2 i.p.v. als de zelfstandig werkende DPMI server Windows onder Ms-Dos.
OS/2 Warp 4 bevat evenals "OS/2 Warp 3 with Win-OS/2 support (alias the "Blue Box ") een eigen Windows versie. De broncode is die van Windows 3.1, maar de uitvoerbare bestanden zijn door IBM gecompileerd. Ook hier gedraagt Windows zich als een Virtual Dos Machine (VDM) onder OS/2. Deze versie draait alleen onder OS/2 en zal onder MS-DOS weigeren te laden. Vandaar dat Warp deze obligaat in /OS2/MDOS/WINOS2 installeert.
Het voordeel hiervan is dat de voor Win-OS/2 benodigde kwetsbare "on the fly patch" van enige Microsoft Windows systeembestanden achterwege gelaten kan worden. Microsoft hoeft maar een bitje in de Windows broncode te veranderen ("updaten") en de truc zal niet meer werken! IBM kan hier niets tegen doen, want het contract waarmee IBM de mogelijkheid had de Microsoft Windows 3.1 broncode te wijzigen is inmiddels verlopen.
Deze voor OS/2 Warp geoptimaliseerde Windows versie is iets sneller dan de WfWG 3.11 onder Dos (ik heb ze op dezelfde PC gedraaid en de Winbenches vergeleken). Het zou om een 10% snelheidswinst gaan.
Windows programma's draaien onder OS/2 naar wens "seamless" in een venster of in een volledig scherm.
Het Windows Klembord werkt samen met vrijwel alle OS/2 programma's. U kunt dus vrijelijk tussen Windows en OS/2 applicaties knippen en plakken. Dit geldt ook voor tekstmodus programma's (Dos, OS/2) die in een scherm worden uitgevoerd
Zelfs DDD wordt door bepaalde OS/2 programma's ondersteund. Helaas wordt OLE niet door OS/2 programma's ondersteund (dit kan natuurlijk wel tussen bepaalde Windows applicaties onderling).
Zo kunt u met geschikte omgevingsvariabelen via een batch file vanuit Win-OS/2 of MDOS ook OS/2 programma's starten.
Windows 3.1(1) kon maar met 32 MB fysiek geheugen overweg. Het meerdere (fysieke) geheugen werd niet benut.
Maar onder OS/2 kunt u een Windows sessie 64 MB geven. Ook als uw PC niet over 64 MB RAM beschikt kunnen uw Windows programma's hiervan profiteren. Hiervoor moet u Win-OS/2 in een venster draaien met de optie snelladen (fastload) aan.
Om dit extra geheugen in de 16 bits Windows praktijk te kunnen benutten laadt OS/2 tijdens een Win-OS/2 sessie de programmacode van eenmaal geopende Windows DLL's blijvend in het RAM. De eerste bestanden worden al geladen bij het laden van de WPS. Doordat steeds meer DLL's in het geheugen geladen worden neemt het geheugengebruik van een Win-OS/2 sessie toe naarmate u meer applicaties opent en sluit.
De extra geheugenconsumptie is voor OS/2 niet zo'n probleem, omdat niet opgevraagde programmacode zeer efficiënt van het fysieke geheugen naar het wisselbestand wordt verplaatst. Heropent u een Windows applicatie dan wordt de opgevraagde benodigde code uit eerder gebruikte DLLs rechtstreeks uit het wisselbestand in het geheugen geladen. Hierdoor wordt de laadtijd van een Window programma bij de hergebruik aanzienlijk verkort. De DLL bestanden hoeven immers niet steeds weer geopend, van de schijf gelezen en op de juiste plek in het geladen te worden.
Ook OS/2 programma's maken gebruik van OS/2's fameuze geheugenbeheer en laden daarom vaak meteen al veel programmacode in het RAM, wat het laden van deze programma's vertraagt, maar de performance uiteindelijk verbetert.
Vanaf Warp 3 worden zelfs OS/2 systeem DLL's geswapt. Omdat veel gebruikte DLL bestanden aldoor in het (al dan niet virtuele) geheugen geladen zijn, hebt u voor OS/2 en Win-OS/2 programma's geen grote schijf-cache nodig.
Windows 3.1(1) heeft als 16 bits DOS programma twee kritische geheugengebieden van 64 kB, die het het aantal applicaties dat geopend kan worden, drastisch beperken. Het gaat om de zogenaamde systeembronnen: de user heap en system heap. Hoewel u nog over megabytes vrij geheugen kunt beschikken kan Windows klagen over te weinig geheugen ("out of memory") als deze geheugen gebieden uitgeput raken. Het vervelende is bovendien dat als u applicaties sluit deze systeembronnen niet altijd vrijkomen (een probleem dat ook nog onder Windows 9x bestaat trouwens).
Mocht u problemen krijgen met de systeembronnen of met de samenwerking tussen de Windows programma's onderling, dan kunt u meerdere afzonderlijke Win-OS/2 sessies tegelijkertijd draaien. Zo kunt u bijvoorbeeld in de ene sessie op de achtergrond een groot Winword document indexeren en in de andere Windows sessie een Word document bewerken (zonder zandlopers natuurlijk).
|
Windows systeemgeluiden uitzetten |
Om foutmeldingen te voorkomen met een gedeelde geluidskaart zet u in Configuratiescherm /Geluid de Windows Start en Exit geluiden expliciet uit. Dus tada.wav wordt <geen>. Het verwijderen van het vinkje bij Systeemgeluiden activeren is niet voldoende. |
In mijn praktijk zijn meerdere Win-OS/2 sessies zelden nodig. Maar het geeft wel aan dat OS/2 een echt multitasking systeem is dat u in staat stelt om DOS-programma's (Windows 3.1 incluis) onafhankelijk van elkaar te laten draaien.
Sommige Windows programma's (Cleansweep en bepaalde communicatieprogramma's bijv.) gebruiken speciale stuurbestanden die de hardware rechtstreeks aanspreken. Dit is onder OS/2 en NT verboden. Virtual eXtended Drivers (VXDs) zullen daarom onder Win-OS/2 niet lopen. Overigens betekent dit niet altijd dat het programma het zelf niet doet. Als de installatie van de VXD driver optioneel is, zal het programma meestal wel lopen.
Een per abuis in de [386Enh] sectie van SYSTEM.INI vermelde VXD-modemdriver wordt onder Win-OS/2 gewoon niet geladen. OS/2 gebruikt hiervoor zijn eigen stuurbestand VCOM.SYS. Een communicatieprogramma zal het daarmee in mijn ervaring ook redelijk doen (maar altijd minder dan onder DOS). Maar programma's die VXDs taken laten uitvoeren die OS/2 niet kan emuleren (Cleansweeps Install en Usage Monitors bijv.) zult u moeten missen.
Win32s zijn 16 bits (!) systeemcomponenten (onderdeel van de zogenaamde Application Programming Interface, API) voor het 16 bits Windows 3.x. Windows programma's roepen APIs aan om het besturingssysteem veel voorkomende taken te laten verrichten.
De Win32s API werd door Microsoft uitgebracht om de overgang van Windows 3x naar Windows 95 (toen nog Chicago geheten) te vergemakkelijken. Met de broncode van de 16 bits programma's die de Win32s API aanriepen zouden ook 32 bits programma's voor Windows 95 gecompileerd kunnen worden.
Maar tot frustratie van veel software ontwikkelaars veranderde Microsoft de standaard steeds weer voor eigen noden. Dit gaf Microsoft een flinke voorsprong bij het uitbrengen van haar eigen 32 bits applicaties op haar concurrenten. Microsoft veranderde de Win32s API na versie 1.25 bovendien zodanig dat de voor haar geschreven programma's onder Win-OS/2's geheugenbeheer niet meer konden lopen.
Win32s is nog steeds een onderdeel van de 32-bit Application Programming Interface (API) van Win32, de Windows 95/NT API. Maar gezien het tanende aantal Windows 3x gebruikers wordt er nauwelijks nog voor geschreven.
De eens door Microsoft voor Windows 3x uitgebrachte versie 1.25 loopt uitstekend onder Win-OS/2. De versie 1.30 van Win32s die Microsoft momenteel uitbrengt krijgt (niet toevallig) knallende ruzie met Win-OS/2's geheugenbeheer en moet u niet installeren.
Zie verder Win32s programma's installeren
Het installeren van Windows programma's onder OS/2 of Linux is in wezen niet anders dan onder Windows 3.1(1) en 95. Zodra u eenmaal Programmabeheer of een andere Windows shell lopend hebt is het gewoon een kwestie van installatiepogramma's draaien.
Met wat geluk hoeft u de installatie maar onder een OS te doen.
Als u Warp 3 for Windows Users gebruikt is dat voor OS/2 en Windows 3.1(1) onder DOS altijd het geval omdat ze dezelfde Windows directory en ini-bestanden gebruiken. Maar nette Windows programma's die al hun systeem en ini-bestanden in hun eigen directory bewaren zijn helaas uitzondering, en dat maakt dat u 16 bits Windows programma's, die u bijv. onder Windows 95 installeert, opnieuw onder Win-OS/2 moet installeren.
Het is prettig als uw Windows 3.1 applicaties onder ieder OS dezelfde instellingen behouden. Dat bereikt u door de applicaties vanuit ieder OS in dezelfde directory te installeren. Hiermee bespaart u ruimte op de harde schijf bovendien. In mijn praktijk zal dat op een logisch FAT16 station zijn.
Als het programma een ini-bestand in de Windows directory aanmaakt, loont het de moeite om te onderzoeken of het programma het ini-bestand ook in zijn eigen werkdirectory accepteert. Is dat het geval, dan kunt u de door het programma aangemaakte ini-bestand uit de verschillende Windows (systeem) directories halen en doorgaan met slechts een exemplaar in de directory van het programma zelf. Wijzigingen die onder het ene OS in de ini-bestanden worden aangebracht, zullen vervolgens ook onder een ander OS te zien zijn. Het gaat dan om zaken als laatst geopende bestanden, voorkeursinstellingen e.d., kortom zaken die een programma gebruiksvriendelijk maken En als u het programma nu onder een ander OS opent, kunt u doorgaan met waar u gebleven bent.
Als u een programma in het ene OS prettig heeft geconfigureerd, en het nu ook onder een ander OS wilt installeren, moet u er rekening mee houden dat bij herinstallatie de standaardinstellingen doorgaans weer zullen terugkomen. Als voorbeeld noem ik Word for Windows 6 dat bij mij onder Windows 95, Win-OS/2 en Linux (onder Wabi) op dezelfde computer is geïnstalleerd.
In dit geval hernoem ik de bestaande programma directory (bijv. WINWORD in BINWORD) en installeer het programma in WINWORD. Daarna wis ik het nieuw aangemaakte WINWORD en geef BINWORD weer zijn oude naam terug. Hiermee voorkom ik dat door mij aangepaste sjablonen worden overschreven. Uiteindelijk wordt in de WINWORD directory dus niet veranderd. Waar het bij een degelijke installatie om gaat is dat de WINDOWS en WINDOWS/SYSTEM van het nieuwe OS worden aangepast. Word for Windows is een van die programma's die een WINWORD6.INI bestand in zijn eigen directory negeert: Het maakt domweg een nieuwe aan in de Windows directory. Daarom kopieer ik het door mij aangepaste WINWORD6.INI bestand uit de het eerste OS naar de Windows directory van het andere OS.
U moet van hacken houden, maar het blijkt mogelijk om bepaalde Windows programma's (Cleansweep 95, WS-FTP, Free Agent, Virtual Access, bijv.) zowel in de 16 als 32 bits versies met dezelfde voorkeuren te laten lopen. Zo draait mijn Compuserve OLR en nieuwsgroeplezer Virtual Access nu onder W95 32 bits en onder Win-OS/2 en Linux 16 bits (het laatste met Caldera's Wabi). Hiermee voorkom ik dat ik voor elk OS weer een andere OLR moet gebruiken. Dit zijn typisch programma's die in hun *.exe en *.dll bestanden een 16 of 32 hebben staan. Maak voordat u onder Win-OS/2 of Linux een 16 bits versie over een 32-bits versie heen installeert echter altijd een volledige backup van het programma! Beter nog is het in mijn ervaring om de omgekeerde volgorde aan te houden en de 32 bits versie over de 16 bits versie heen te installeren.
Natuurlijk doet u dat altijd met een reservekopie van de installatiedirectory, waarmee u snel de oude situatie kunt herstellen! Dat is op de harddisk zo gebeurd.
Tenslotte: houd in de gaten dat sommige Windows programma's bij de installatie de config.sys (van OS/2!) en de autoexec.bat kunnen veranderen. Controleer die dus altijd.
De in het verleden door Microsoft uitgebrachte Win32sversie 1.25 voor Windows 3x werkt goed onder Win-OS/2. Deze versie is nog op vele OS/2 FTP sites te vinden in /pub/os2/windows e.d.
Maar de versie 1.30 van de Win32s bibliotheek die Microsoft nu voor Windows 3.1 en 3.11 levert loopt niet onder Win-OS/2. Deze versie staat programma's toe om geheugen op te vragen op een manier die met OS/2 onverenigbaar is. Als programma's zo geschreven zijn dat ze van deze extra functies gebruik moeten maken, zullen ze vastlopen.
Maar het grootste deel zal slechts installatieproblemen ondervinden, maar wel onder versie 1.25 lopen. Anderen zullen in een Win32s versie 1.25/1.30 hybride lopen. Een deel loopt gewoon niet.
De kans is groot dat u tegen de verkeerde Win32s versie aanloopt. Want de meeste Windows programma's die na september 1995 uitkwamen waren 32 bits Win32 of 16 bits Win32s versie 1.30 programma's. Daarnaast worden programma's geleverd in een 16 bits Windows 3.1 en een 32 bits Win32 (NT, Windows 95) versie, waarvan de 16 bits versies doorgaans goed lopen onder Win-OS/2 .
Installatieproblemen van Win32s programma's die tijdens de installatie melden dat zij voor de Win32s versie 3.0 geschreven zijn, zou u met Warp 3 voor Windows kunnen ondervangen door tijdelijk onder DOS de versie 1.30 van de Win32s te installeren, daarna de mokkende applicatie, en daarna de 1.30 versie van de Win32s bibliotheek weer vervangen door versie 1.25 die ook onder Win-OS/2 loopt.
Voor een hybride Win32s 1.25/1.30 systeem zijn de volgende Win32s 1.30 version bestanden in de system\win32s map nodig: shell32.dll, comctl32.dll, oleaut32.dll, ole2thk.dll en ole32.dll. De rest draait op versie 1.25.
Onder Win-OS/2 heb u niet de beschikking over veilige uninstallers. Dat is een probleem, omdat de betrouwbaarheid en performance van Windows afneemt naarmate u meer programma's installeert.
Een programma als Cleansweep 95 (dat in de eerste versies zowel in een 16 als 32 bits versies geleverd werd), draait niet betrouwbaar onder Win-OS/2. Ten eerste lopen de door VXD-drivers aangestuurde monitoren niet. Ten tweede is het programma zo gericht op Windows dat het niet op het idee komt dat er ook andere besturingssystemen bestaan, waar het verder geen weet van heeft. Zo scant Cleansweep vrolijk de OS/2 HPFS en Linux Ext2 partities op "unused files" en "vindt" vanuit zijn benepen Windows perspectief natuurlijk vele ongebruikte bestanden.
Toen ik nog een versie van Warp 3 for Windows Users gebruikte draaide ik Cleansweep daarom slechts onder Dos. Ik installeerde grote Windows programma's altijd onder DOS, zodat ik van de install monitor gebruik kon maken. Dat ging redelijk goed, maar Cleansweep herkende bij schoonmaak operaties de door OS/2 toegevoegde systeembestanden niet! Zorg er dus altijd voor dat u voordat u een dergelijk opschoonprogramma draait een backup laat aanmaken. Dit is zelfs aan te bevelen als u alleen Windows draait. De backups kunt u pas ruimen als u een tijdje al uw programma's zonder problemen hebt gebruikt.
Gebruikt u uw uninstaller te heftig, dan loopt u zelfs het gevaar dat Windows niet meer opstarten wil! Omdat Cleansweep backups in *.bud-bestanden zipt, kunt u met iedere unzipper de ontbrekende bestanden ook onder DOS of OS/2 weer terugzetten. Waarschijnlijk heeft Cleansweep zijn eigen zip-bestanden in *.bud veranderd om te voorkomen dat het zijn eigen backups (als unused zips) opruimt.
Iedere installatie van een nieuw Windows programma houdt het risico in dat oude goed werkende DLL's en andere systeembestanden overschreven worden door incompatibele systeembestanden. Hierdoor kunnen hardnekkige vastlopers ontstaan.
Uninstallers bieden hier bij mijn weten geen bescherming tegen. Ze verwijderen, als het goed is, slechts de door programma's toegevoegde bestanden, maar niet de door programma's overschreven bestanden. Als u pech heeft kunt u zelfs een Uninstaller niet meer gebruiken, omdat Win-OS/2 meteen al vastloopt!
Daarom is het verstandig om met een batch de belangrijkste Windows systeembestanden (WIN.INI, SYSTEM.INI, CONTROL.INI, PROGRAM.INI en REG.DAT ) voor iedere installatie van een nieuw Windows programma naar een veilige plaats te kopieren. En maak voor herstel van DLL's en andere essentiele bestanden regelmatig een backup van uw complete Windows directory en subdirectories. Hiermee kunt u altijd terug naar een goed werkend systeem.
Met win(os2) /b maakt Windows een bootlog aan om de ontbrekende bestanden te identificeren. Het bestand heet BOOTLOG.TXT en is te vinden in de Windows directory. Dit werkt ook onder een (dos) venster onder OS/2. Ontbrekende drivers en fonts worden genoemd achter het LoadFail= in het bootlog bestand.
Het grote voordeel van een Dos-venster is dat eventuele Dos-foutmeldingen niet meteen door de Windows GUI overschreven worden. Immers, zodra de Windows de GUI laadt stopt OS/2 het proces en vraagt of u naar volledig scherm wilt overschakelen. De Dos-foutmeldingen zijn dan nog in beeld. Pas als u met Dos (instellingen)/ Volledig scherm naar een full-screen sessie overschakelt kan Windows verder gaan met het aanmaken van het bootlog bestand.
De optie die u onder Windows 95 heeft, om een falend Windows opnieuw te installeren (waardoor de oorspronkelijke systeembestanden worden teruggezet), is niet zo bruikbaar onder Win-OS/2.
Herinstalleert u Win-OS/2 onder Warp 4 dan krijgt u de vrij primitieve Windows desktop te zien waarmee u ooit begon. Daarna moet u vooral de grotere applicaties opnieuw installeren, want de win.ini en system.ini bestanden worden door de herinstallatie overschreven.
Voor Warp for Windows Users is het iets gemakkelijker. Zij moeten eerst Windows 3.1(1) onder DOS over de niet opstartende versie heen installeren en daarna Win-OS/2 herinstalleren onder OS/2.
De Microsoft versie van Windows 3.1(1) neemt in tegenstelling tot de latere OS/2 versie van IBM (Warp with Win-OS/2 support) de win.ini, system.ini en progman.ini instellingen van de oude versie over, zodat zij niet alles opnieuw hoeven te installeren. Mocht u ergens op uw schijf nog een Microsoft versie van Windows 3.1(1) hebben staan, dan kan de IBM versie de instellingen daarvan desgewenst overnemen in \OS2\MDOS\WINOS2. Anders moet u veel opnieuw installeren.
Mocht u Windows wel full-screen aan de praat krijgen, maar niet in een venster, denk dan eerst aan de instellingen van de videodrivers. Ze staan vermeld in de [boot] sectie van system.ini als display.drv=naam.drv en sdisplay.drv=snaam.drv. Display.drv kan in principe een gewone Windows 3.1 driver zijn, maar sdisplay.drv moet specifiek gemaakt zijn voor Win-OS/2. De drivers bevinden zich in de Windows system directory.
Hebt u een probleem met de fastload (Snel laden) optie, maar kunt u programmabeheer wel "seamless" draaien, dan is seamwin4.zip misschien iets voor u. Seamless Win is een 16 bit Windows programma dat een minimaal aantal system resources gebruikt en verder niets doet. In de OS/2 Startup folder zal het wel hetzelfde effect hebben als de fastload optie voor Win-OS/2: de voor Win-OS/2 benodigde programmacode meteen in het geheugen laden.
Vrijwel alle Dos en Win-OS/2 instellingen van het eerste Win-OS/2 programma dat u start worden (gedurende de Win-OS/2 sessie) automatisch overgenomen door de volgende programma's die u onder Win-OS/2 draait. Bij Snel laden gaat het om de Win-OS/2 Instellingen van het object "WIN-OS/2 Instellen". Gebruikt u Seamless Win of Programmabeheer als eerste Win-OS/2 programma dan stelt u ze daar in.
Een programma waar het instellingenblok Standard modus voorschrijft zal niet onder een 3.1 Enhanced Compatibility Win-OS/2 sessie opstarten. Ik zet die instelling standaard op "3.1 Enhanced Compatibility". Ook de ATM instelling kan voor problemen zorgen. Goed werkende of voor bepaalde taken geoptimaliseerde Instellingen kunt u apart opslaan. Zie: Instellingen opslaan in een gecodeerd bestand.
Nog enige locaties om in de gaten te houden bij problemen:
SYSTEM.INI
|
[boot] |
Plaats in de [boot] sectie van os2/mdos/winos2/system.ini: |
|
MAVDMAPPS= |
Hiermee voorkomt u dat Windows zijn eigen spooler gebruikt. De OS/2 spooler is gewoon veel beter. In Control Panel /Printer (configuratiescherm) moet u Use Print Manager uitzetten. |
WIN.INI
|
load= run= |
Een hangende Win-OS/2 kan veroorzaakt worden door achtergrondprogramma's die met load= en run= commando's in de WIN.INI gestart worden. Schakel ze uit door er een puntkomma voor te zetten. Let ook op de Opstarten map van programmabeheer. |
Lange namen op vFAT-schijven : Hoe Win95 en OS/2 met lange namen op FAT16 schijven omgaan.
OS/2 en FAT32 : Hoe Microsoft u het nodeloos moeilijk maakt (en hoe dit te omzeilen)
De laatste Netscape Navigator 4.08 voor Windows 3.1 draait goed onder OS/2, maar veilig is hij niet.
Het Win32-OS/2 project : zelf uw Windows programma's naar OS/2 porteren.
Als u prettig werkende Win-OS/2 instellingen hebt is het handig deze op te slaan. Dat kan met Instellingen / Tab Sessie / Win-OS/2 instellingen / Alle instellingen voor DOS en Win-OS/2 te openen .
in de WIN/OS2 autoexec.bat is Word met een lege map D:\DUMMY-C al tevreden.