ppgrainbow

You guys for got to mention, e-Frontier Poser 7 (2006) which required a 700 MHz processor and 512 MB of memory and nearly up to 2.5 GB of disk space. I bought it from eBay for Christmas under $35 (including shipping) and it was originally sold for $199. What a bargain! Poser 7 was the last release under the e-Frontier name before it was acquired by Smith Micro and it was also the last release that worked under Windows 2000. Updating to Smith Micro Poser 7.0.4 (Service Release 3) had no effect on the system requirements. Prior to that, I had Curious Labs Poser 5 (2003) installed on this computer.. I don't think Smith Micro Poser 8 (2009) and Smith Micro Poser 9 (2011) works with Windows 2000 even with UURollup, due to OS checks and the fact that the product might not even work correctly under Windows 2000, if not at all. Also, Windows 2000 support was dropped when Smith Micro released Poser Pro in 2008.

I had a problem with VPC Share under MS-DOS and used the SHSUCDX driver at the same time, not the MSCDEX driver supplied by Microsoft. I also looked at Ben Armstrong's comment regarding FSHARE and EMM386 and the changes that makes the folder sharing TSR not work at all is not true. I used version 4.95 of the Windows Expanded Memory Manager. As a result, the folder sharing, the MSCDEX CD-ROM driver and EMM386 all work, however this tatic is unsupported and I cannot guarentee that it will work correctly with other alternate memory managers or CD-ROM drivers.

Thank you for pointing these links out. I tried the original version of the SHSUCDX driver by John McCoy and the current version, but it seems that it didn't work. Both current versions? Jack Ellis' latest version v. 3.03F (or the previous one, v. 3.03E) is, IMHO, far superior, to Jason Hood's latest (V. 3.05). They are quite different, nowadays, so it's perfectly possible that one works where the other fails. Then you have Jack Ellis' XMGR. Then there is Japheth's Jemm... If one has time for experimenting (of which I regretably have very little, nowadays), there're many variations to try, before giving up. Now, that said, I'm not familiar with FSHARE to advise you specifically about it. Whatever or not they're different or not, these variants of SHSUCDX CD-ROM driver wouldn't work correctly with the FSHARE driver. So, in order to use the MSCDEX CD-ROM driver, I had to enter this command in the CONFIG.SYS file on line 30: device=c:\dos\emm386.exe noems novcpi i=b100-b7ff i=c600-c7ff i=cc00-cfff i=e600-efff frame=d000 /v The end result is that I earned up to 150 KB of upper memory upon bootup: Windows Expanded Memory Driver Version 4.95 Copyright 1988-1995 Microsoft Corp. EMM386 successfully installed. Expanded memory services unavailable. Total upper memory available . . . . . . 150 KB Largest Upper Memory Block available . . 79 KB Upper memory starting address . . . . . . B100 H EMM386 Active. I had to settle with up to 625 KB available with the largest executable being no more than 596 KB available.

Thank you for pointing these links out. I tried the original version of the SHSUCDX driver by John McCoy and the current version, but it seems that it didn't work. Additionally when I unload the SHSUCDX driver using SHSUCDX /U comment, any attempts to access the folds on the shared folder as a network drive returns an "Invalid function". When Microsoft included FSHARE in its Virtual Machine Additions for DOS (used in Virtual PC 2004), I suspect that it wasn't very stable to begin with and didn't work correctly with either EMM386 or alternate CD-ROM drivers. Is there a way to hex-edit FSHARE to make it work here? I'm starting to run out of options.

Hello! I'm trying to get the SHSUCDX CD-ROM driver working in MS-DOS 6.22 when running under Microsoft Virtual PC 2004 on the Windows 2000 host machine and I'm running into serious problems trying to get the CD-ROM ISOs to read properly. I click on Capture ISO image from the CD menu and select the Corel Draw 3 CD-ROM ISO from one of the files lying around on one of my hard drives. Now, here's the problem. When I type dir in drive X (that's the CD-ROM drive letter that I assigned it to), only one directory and no files show up. Here's the output: C:\>x: X:\>dir Volume in drive X is D3D1ES_CD2F Directory of X:\ CATALOG <DIR> 11-29-93 7:18p 1 file(s) 0 bytes 0 bytes free X:\> The only problem here is that the contents of the Corel Draw 3 CD-ROM ISO is supposed to show all of the files in that directory. If I don't load FSHARE, all of the contents in that directory get displayed: Volume in drive X is D3D1ES_CD2F Directory of X:\ CATALOG <DIR> 11-29-93 7:18p CDBASED <DIR> 01-24-95 11:24a CDRMEM DLL 16,265 10-25-92 12:00p CDROM INF 26,673 10-25-92 12:00p CDRUI DLL 58,192 10-25-92 12:00p CHART <DIR> 01-24-95 11:24a CLIPART <DIR> 01-24-95 6:12p DDEML DLL 36,864 10-25-92 12:00p DRAW <DIR> 01-24-95 11:24a DRAW INF 60,567 01-25-95 4:29p DRAW MST 47,811 01-24-95 2:38p DRAW2 MST 28,171 01-24-95 1:35p FILTERS <DIR> 01-24-95 11:25a FONTS <DIR> 01-24-95 12:10p LIBRARY <DIR> 01-24-95 11:25a MOSAIC <DIR> 01-24-95 11:36a MOSDDE DLL 7,902 10-25-92 12:00p MSCOMSTF DLL 74,528 10-25-92 12:00p MSCUISTF DLL 252,000 01-24-95 2:34p MSDETECT INC 6,981 10-25-92 12:00p MSDETSTF DLL 24,544 10-25-92 12:00p MSINSSTF DLL 65,440 10-25-92 12:00p MSSHLSTF DLL 13,824 10-25-92 12:00p MSUILSTF DLL 6,144 10-25-92 12:00p NET INF 24,321 10-25-92 12:00p NET LST 724 10-25-92 12:00p NET MST 31,541 10-25-92 12:00p PHOTOPNT <DIR> 01-24-95 11:36a README TXT 27,152 10-25-92 12:00p REDIST <DIR> 01-24-95 11:36a SCANCD EXE 70,148 10-25-92 12:00p SETUP EXE 24,048 10-25-92 12:00p SETUP LST 754 10-25-92 12:00p SETUP2 EXE 5,480 10-25-92 12:00p SETUPAPI INC 38,124 10-25-92 12:00p SHELL DLL 41,600 10-25-92 12:00p SHOW <DIR> 01-24-95 11:36a SPELDICT <DIR> 01-24-95 11:37a TRACE <DIR> 01-24-95 11:37a TRANSLAT INC 6,306 01-25-95 3:41p VER DLL 9,008 10-25-92 12:00p _MSTEST EXE 89,504 10-25-92 12:00p 42 file(s) 1,094,616 bytes 0 bytes free So far, here is what I have in the contents of my CONFIG.SYS file: REM Load the Virtual Machine additions driver. device=c:\dos\vmadd386.sys REM Set common system settings. switches=/f /n files=50 buffers=20 REM Disable old FCBS support. fcbs=1,0 REM Disable DOS STACKS. stacks=0,0 REM Set the LASTDRIVE variable to Z. lastdrive=z REM Set MS-DOS to load hight and use upper memory blocks. dos=high,umb REM Load GRUB4DOS before loading drivers. device=c:\grub\grub.exe --config-file=(hd0,0)//boot/menu.lst REM Load the HIMEM device driver and don't test system memory. devicehigh=c:\dos\himem.sys /numhandles=128 /testmem:off /q REM Load the EMM386 memory manager driver and provide up to REM 115 KB of upper memory by including B000-B777 and CC00-DFFF. device=c:\dos\emm386.exe noems /min=0 /i=b000-b7ff /i=cc00-dfff /v REM Load the DOSMax driver utility. device=c:\max\dosmax.exe N+ P- R- U02 U08 U09 U0A U0B U0C U0D U0E U70 U72 U73 REM Load the Oak CD-ROM driver in high memory. devicehigh /l:2=c:\dos\cdrom.sys /d:vpc REM Load the Installable File System Helper into upper memory. devicehigh /l:1=c:\windows\ifshlp.sys REM Set the size of environmental space for the Command Interpreter REM (COMMAND.COM to 4 KB and load it into high memory. shell=c:\max\shellmax.com /n+ /p- /r- /s- c:\command.com /e:4096 /p And here are the contents of my AUTOEXEC.BAT file: @echo off REM Set the path search for all common apps. path c:\dc21x4;c:\dos;c:\ie;c:\max;c:\ndw;c:\pkzip;c:\popdos;c:\windows path %path%;c:\4dos;c:\deskmate;c:\hxdos\bin;c:\lxpic;c:\wget;d:\stella REM Display the current path at the command prompt. prompt $p$g REM Load the IDLE driver in high memory. lh /l:1,640 idle REM Start the network. lh c:\windows\net start REM Set the following path variables for the directories below. set bin=c:\turboc\bin set dmconfig=c:\deskmate set temp=c:\temp set wattcp.cfg=c:\wattcp REM Start ENVIMAX. envimax REM Load the SHSUCDX CD-ROM driver. lh /l:2 shsucdx /d:vpc /l:x REM Load FSHARE folder sharing utility in high memory. lh fshare REM Load the mouse driver at single speed. lh mouse /1 REM Load the HIDE87 terminate-and-stay resident (TSR) program. hide87 REM Start MS-DOS Shell. dosshell It turns out that Microsoft Virtual PC 2004's FSHARE utility and the SHSUCDX CD-ROM driver are incompatible with each other. I even tried to use a older version of FSHARE from the trial version of Connectix Virtual PC 5.2, but it wasn't much of a help. Here is the complete information on how are the drivers that I have loaded in MS-DOS 6.22 in conventional (base) memory, upper memory and modules using the memory below 1 MB: Conventional (Base) Memory detail: Segment Total Name Type ------- ---------------- ----------- -------- 00000 1,039 (1K) Interrupt Vector 00040 271 (0K) ROM Communication Area 00050 527 (1K) DOS Communication Area 00070 3,152 (3K) IO System Data CON System Device Driver AUX System Device Driver PRN System Device Driver CLOCK$ System Device Driver A: - H: System Device Driver COM1 System Device Driver LPT1 System Device Driver LPT2 System Device Driver LPT3 System Device Driver COM2 System Device Driver COM3 System Device Driver COM4 System Device Driver 00135 5,248 (5K) MSDOS System Data 0027D 6,480 (6K) IO System Data 1,104 (1K) XMSXXXX0 Installed Device=HIMEM 5,328 (5K) EMMQXXX0 Installed Device=EMM386 00412 16 (0K) MSDOS System Program 00413 80 (0K) MSDOS System Program 00418 288 (0K) HIDE87 Environment 0042A 80 (0K) MSDOS -- Free -- 0042F 6,224 (6K) SHSUCDX Program 005B4 336 (0K) HIDE87 Program 005C9 272 (0K) MEM Environment 005DA 88,992 (87K) MEM Program 01B94 542,384 (530K) MSDOS -- Free -- Upper Memory detail: Segment Region Total Name Type ------- ------ ---------------- ----------- -------- 0B15C 1 240 (0K) DOSMAX Program 0B16B 1 3,888 (4K) IO System Data 3,856 (4K) IFS$HLP$ Installed Device=IFSHLP 0B25E 1 2,688 (3K) FILES Program 0B306 1 96 (0K) FCBS Program 0B30C 1 528 (1K) WKBUFFER Program 0B32D 1 2,304 (2K) LASTDRIV Program 0B3BD 1 160 (0K) INSTALL Program 0B3C7 1 208 (0K) IDLE Environment 0B3D4 1 400 (0K) IDLE Program 0B3ED 1 208 (0K) MSDOS -- Free -- 0B3FA 1 1,440 (1K) NDISHLP Program 0B454 1 4,112 (4K) COMMAND Environment 0B555 1 288 (0K) FSHARE Environment 0B567 1 272 (0K) MOUSE Environment 0B578 1 8,752 (9K) MOUSE Program 0B79B 1 1,584 (2K) MSDOS -- Free -- 0C601 2 4,240 (4K) IO System Data 4,208 (4K) VPC Installed Device=CDROM 0C70A 2 3,904 (4K) MSDOS -- Free -- 0CC01 3 2,656 (3K) COMMAND Program 0CCA7 3 400 (0K) PROTMAN Program 0CCC0 3 42,704 (42K) DC21X4 Program 0D72D 3 26,448 (26K) FSHARE Program 0DDA2 3 9,696 (9K) MSDOS -- Free -- Modules using memory below 1 MB: Name Total = Conventional + Upper Memory -------- ---------------- ---------------- ---------------- MSDOS 10,189 (10K) 10,189 (10K) 0 (0K) HIMEM 1,120 (1K) 1,120 (1K) 0 (0K) EMM386 5,488 (5K) 5,488 (5K) 0 (0K) HIDE87 624 (1K) 624 (1K) 0 (0K) SHSUCDX 6,224 (6K) 6,224 (6K) 0 (0K) DOSMAX 240 (0K) 0 (0K) 240 (0K) IFSHLP 3,904 (4K) 0 (0K) 3,904 (4K) FILES 2,688 (3K) 0 (0K) 2,688 (3K) FCBS 96 (0K) 0 (0K) 96 (0K) WKBUFFER 528 (1K) 0 (0K) 528 (1K) LASTDRIV 2,304 (2K) 0 (0K) 2,304 (2K) INSTALL 160 (0K) 0 (0K) 160 (0K) IDLE 608 (1K) 0 (0K) 608 (1K) NDISHLP 1,440 (1K) 0 (0K) 1,440 (1K) COMMAND 6,768 (7K) 0 (0K) 6,768 (7K) FSHARE 26,736 (26K) 0 (0K) 26,736 (26K) MOUSE 9,024 (9K) 0 (0K) 9,024 (9K) CDROM 4,256 (4K) 0 (0K) 4,256 (4K) PROTMAN 400 (0K) 0 (0K) 400 (0K) DC21X4 42,704 (42K) 0 (0K) 42,704 (42K) Free 646,848 (632K) 631,456 (617K) 15,392 (15K) Memory Summary: Type of Memory Total = Used + Free ---------------- ---------- ---------- ---------- Conventional 655,360 23,904 631,456 Upper 117,248 101,856 15,392 Reserved 393,216 393,216 0 Extended (XMS) 65,943,040 312,832 65,630,208 ---------------- ---------- ---------- ---------- Total memory 67,108,864 831,808 66,277,056 Total under 1 MB 772,608 125,760 646,848 Memory accessible using Int 15h 0 (0K) Largest executable program size 631,360 (617K) Largest free upper memory block 9,696 (9K) Available space in High Memory Area 10,608 (10K) MS-DOS is resident in the high memory area. XMS version 3.00; driver version 3.95 I was very lucky enough to squeeze the FSHARE folder sharing utility and the Intel DC21X4 driver into upper memory, leaving out no more than 632 KB of memory (under 1 MB) and the largest executable programme size being no bigger than 617 KB. If I use MS-DOS's MSCDEX driver, it takes up an additional 22 KB of base memory, leaving no more than 610 KB of base memory under 1 MB and 595 KB for the largest executable file. And MEM is reporting that there is 115 KB of upper memory with up to 79 KB available at boot. When all of the device drivers get loaded in high memory, 15 KB of upper memory will be available. Is there an updated version of SHSUCDX or a alternate driver that will correct this issue or a way to fix the errors in the CONFIG.SYS or AUTOEXEC.BAT file so that folder sharing and the CD-ROM driver can work together? The latest version that I have installed is version 3.05 dated 2011-02-11. I'm sorry for posting such a long comment, but I'm not feeling too comfortable to the fact that Microsoft MS-DOS's MSCDEX driver for MS-DOS 6.22 uses no less than 27 KB. Also the NWCDEX driver (from Novell DOS and DR-DOS) is bloated, because it uses no less than 61 KB of upper memory. I'm stumped.

Well...a decision as already been made! I am getting the Fujitsu Stylistic Point 510. So much for the limitations on the Mitsubishi AMiTY VP. Better luck...next Christmas.

Thanks. I don't think that Mitsubishi provided any drivers for Windows 3.1 when used on the AMiTY VP. The original release of Windows 95 and Windows 95 OSR 1 required at least 4 MB of memory. However, Windows 95 would refuse with networking components if the computer had less than 8 MB of memory. Also, later versions of Windows 95 (OSR 2.x) req'd more disk space and twice the amount of memory. The AMiTY VP was released in late 1997 at the time when vendors started to increasingly phase out support for Windows 3.1 when it has a slow processor and supported only one OS. I'm moving closer to getting the Stylistic Point 510 instead of the AMiTY VP for sure.

You can try the Toshiba ones: http://web1.toshiba.ca/support/isg/drivers/archives/files_Archive/Index/display_drivers.htm jaclaz Thanks for the help again. If it doesn't work, I will most likely have to stick with 640 x 480 @ 256 colours with the generic SVGA drivers. As far as I know, the Mitsubishi AMiTY SP M3011 was the last tablet computer to officially support Windows 3.1 as I recall. Also, I have a couple more questions to ask here. 1. How can I get the pen and sound card drivers working after I install Windows 3.1 on the AMiTY VP? 2. Most importantly, how can I transfer files from the Mitsubish AMiTY VP or the Fujitsu Point 510 to this computer?

From what you reported it seems to me like he actually replied, saying he doesn't know. I guess everyone is allowed to not know something.... I presume that the issue with Win 3.1 is only that of finding viable drivers for the specific screen/pen, compare with: http://www.vintage-computer.com/vcforum/showthread.php?26914-Windows-for-Pen-for-Compaq-Concerto jaclaz Thanks for the help. I have found information regarding the Mitsubishi Amity VP on the Mitsubishi Mobile PC Technical Information webpage and here's what I found: http://web.archive.org/web/20060110192842/http://www.mitsubishi-mobile.com/support/mobile.htm Mitsubishi states that the AMiTY VP comes with Windows 95 OSR 2.1 installed and can be upgraded to Windows 98. However, Windows 95 OSR 2.1 and Windows 98 chokes with a 810 MB hard drive and only 16 MB of EDO memory! And on this page dated 2004-11-20, the AMiTY VP comes with a Chips and Technology 65548 integrated video chip and a 133 MHz AMD 5x86 processor. Furthermore, I cannot find any C&T 65548 drivers for Windows 3.1, infact. I believe that the C&T 65548 drivers may have never even supported Windows 3.1...so, I will most likely have to use the generic 640 x 480 256 colour driver to run Windows 3.1 on the AMiTY VP. I will have to go to the Vintage Computer Software forum for answers on how to get Windows 3.1 with Pen extensions installed on the AMiTY VP.

I'm sorry for bumping this thread up, but when I asked bibilophilezen regarding installing Windows 3.1 on the Mitsubishi Amity VP, I received the following replies: Forcing Windows Millennium on the Mitsubishi Amity VP chokes with just 16 MB to 48 MB of memory and infact, it might not even run correctly or not at all with just 16 MB. I just wanted to know if it was possible to install Windows 3.1 and Pen extensions on the Mitsubishi Amity VP and the seller refused to answer. Gah, I have $148.95 left over and I can't believe the frustration that I'm going through on eBay. I can't believe these sellers who have little or no knowledge in computers.

Hey there. I found the Mitsubishi Amity VP being put up for sale on eBay and so far, four units have been sold with six units available. The unit costs $98, plus $15 S&H. You can view the unit here: http://www.ebay.com/itm/Mitsubishi-Amity-tablet-VP-Toshiba-libretto-/200771135900 I'm telling you this and I'm curious. Is it possible to install Windows 3.1 with Pen Computing extensions on the Mitsubishi Amity VP? If so, how can it be done? The Mitsubishi Amity VP has a 133MHz AMD5x86 processor with a 810 MB hard drive, 16 MB EDO RAM (upgradable to 48 MB) and it comes with Windows for Pen Computing v2.0 pre-installed. I'm only interested in it as I'm considering ditching the Toshiba Tecra 720 CDT and the GRiD Convertible 2270 laptop for which the latter hasn't been working for months. I don't know if I am going to get the Ricoh G-1200S instead as the unit will only remain available for less than a day? The unit will go off the list at 6:05:32 PM PST tomorrow night.

If I strip out the two lines in [Path] at the beginning of MSDOS.SYS and keep HostWinBootDrv=C paramenter: WinDir=C:\WINDOWS WinBootDir=C:\WINDOWS Windows 3.0 would boot on a FAT32 partition. However, doing that under Virtual PC causes the screen to go blank when Windows 3.0 is run in 386 Enhanced Mode. I'll probably give it a go and test Windows 3.0 under DOS 7.1 in VMware soon. I tested a ran Windows 3.0 VM with MS-DOS 5.0 and it worked okay without problems. When I ran my experiments, I had to limit RAM to 15MB and enable EMM386. I lowered the RAM to 12 MB and it wasn't too much of a help. I'll try to experiment Windows 3.0 on a FAT 32 partition again soon to see what I can come up with.

Thank you so much for posting all of the info regarding DOS findings and BennyLevel hacks regarding MS-DOS and PC-DOS, os2fan. I really appreciate it!

Okay, for some reason, when I tried to run Windows 3.0 on top of MS-DOS 7.1 whatever or not the drive is formatted as a FAT or FAT32 partition, attempting to boot Windows 3.0 or Windows 3.0a throws this error message: If I strip out the two lines in [Path] at the beginning of MSDOS.SYS and keep HostWinBootDrv=C paramenter: WinDir=C:\WINDOWS WinBootDir=C:\WINDOWS Windows 3.0 would boot on a FAT32 partition. However, doing that under Virtual PC causes the screen to go blank when Windows 3.0 is run in 386 Enhanced Mode. I'll probably give it a go and test Windows 3.0 under DOS 7.1 in VMware soon. I tested a ran Windows 3.0 VM with MS-DOS 5.0 and it worked okay without problems.

Thank you for telling me. I really appreciate it! If you have found something that causes the keyboard to not function at all when using MAME or MESS emulator with UURollup, let me know.

I examined the files and did not find any suspicious code. I inserted the 3.0 Version into my Windows 3.1 Setup. I did not see any Current Directory corruption on exit. If the problem exists in 3.0 then it probably occurs elsewhere. I believe so. I'm gonna be doing a test installation of Windows 3.0 in Virtual PC on a 3 GB and 10 GB hard disk partitions in VirtualPC to see if there is any side effects from the "current directory" data corruption.

I would need to find copies of WIN386.EXE for Windows 3.0 and 3.0a before I could answer that. I am not familiar with the 16MB limit. Should I send you a e-mail for the details? In a DOSBox machine, I had to set the memory limit to 64 MB, copy the KRNL286.EXE, KRNL386.EXE and WIN386.EXE files from a Windows 3.1 installation and for some reason...Windows 3.0 would throw me back to DOS. As you're not familiar with the 16 MB limit, I will have to revert the changes until further notice. More about the memory limits at this page: http://support.microsoft.com/kb/84388 A temporary workaround for a Windows 3.0 installation with more than 16 MB of system memory would be to create a RAM disk drive to occupy the amount of memory until the total amount of physical memory is 16 MB of less. 1. If the amount of memory installed is 24 MB, then a 8 MB RAM disk would need to be created. 2. If the amount of memory installed is 32 MB, then a 16 MB RAM disk would need to be created. 3. If the amount of memory installed is 48 MB, then a 32 MB RAM disk would need to be created. 4. If the amount of memory installed is 64 MB, then a 48 MB RAM disk would need to be created and you will have to use a third-party RAM disk driver such as XMSDisk. If you use Microsoft's RAMDRIVE.SYS driver then at least two RAM disk drives, a 32 MB and a 16 MB would be created. I would assume that the Current Directory Fix for Windows 3.0 would involve finding the same pattern and replacing it with the same data as Windows 3.1. If not, you can E-Mail me the two Versions to examine. Fixing the memory limitation probably would involve a significant amount of work. The very limited number of users and the availability of Windows 3.1 makes this unworthwhile. I already have a memory limiter that can set the available memory to anything I want. Alright. I sent you a e-mail so that you can look into the current directory data corruption issue under Windows 3.0 As for Windows 3.0, I honestly agree. PCs that had 16 MB of memory (or more) were not available at the time when Windows 3.0 and Windows 3.0a came out in 1990 and the changes that are required to overcome (break) the 16 MB memory limit under Windows 3.0 would involve more than a significant amount of work, it would require architectural changes that can never be supported under Windows 3.0. Windows 3.1 is capable of addressing up to 64 MB of memory under MS-DOS 4.0 to MS-DOS 6.22 (and MS-DOS 6.3 beta) and up to 512 MB of memory when Windows 3.1 is only run in Standard Mode in MS-DOS 7.0 through 8.0 as well as FreeDOS.

I would need to find copies of WIN386.EXE for Windows 3.0 and 3.0a before I could answer that. I am not familiar with the 16MB limit. Should I send you a e-mail for the details? In a DOSBox machine, I had to set the memory limit to 64 MB, copy the KRNL286.EXE, KRNL386.EXE and WIN386.EXE files from a Windows 3.1 installation and for some reason...Windows 3.0 would throw me back to DOS. As you're not familiar with the 16 MB limit, I will have to revert the changes until further notice. More about the memory limits at this page: http://support.microsoft.com/kb/84388 A temporary workaround for a Windows 3.0 installation with more than 16 MB of system memory would be to create a RAM disk drive to occupy the amount of memory until the total amount of physical memory is 16 MB of less. 1. If the amount of memory installed is 24 MB, then a 8 MB RAM disk would need to be created. 2. If the amount of memory installed is 32 MB, then a 16 MB RAM disk would need to be created. 3. If the amount of memory installed is 48 MB, then a 32 MB RAM disk would need to be created. 4. If the amount of memory installed is 64 MB, then a 48 MB RAM disk would need to be created and you will have to use a third-party RAM disk driver such as XMSDisk. If you use Microsoft's RAMDRIVE.SYS driver then at least two RAM disk drives, a 32 MB and a 16 MB would be created.

How can WIN386.EXE in Windows 3.0 and Windows 3.0a be patched too? Also, is there a patch to overcome the 16 MB physical limit in Windows 3.0/3.0a or is this by design? If so, which of the files in Windows 3.0 would you have to patch up?

Thanks for telling me. I really appreciate it! ^^ I can't wait to see Silverlight working again.

Thank you for telling me. I noticed that according to this forum thread, data corruption will eventually occur if you attempt to write to the current directory pointer. I found that a better solution would be to use a hex editor to patch WIN386.EXE found in the \WINDOWS\SYSTEM directory to see if it fixes the directory corruption bug or not: In Windows 3.1, edit the following: In Windows 3.11, edit the following: I myself used the hex editor to patch those files and placed them in separate directories on a 1.44 MB diskette image: 1. For WIN386.EXE used in Windows 3.1, the size of the file is 544,789 bytes (532 KB) and it's placed in the \WIN.310 directory. 2. For WIN386.EXE used in Windows for Workgroups 3.111, the size of the file is 577,557 (564 KB) and it's placed in the \WFW.311 directory. The patch made hasn't been tested on Windows for Workgroups 3.1 and Windows 3.11. The directory corruption fix will not work in Windows 3.0 as I don't think that there is a fix to this issue. Users who want to run Windows 3.0 on a FAT32 partition under FreeDOS, MS-DOS 7.1 or MS-DOS 8.0 will have to use a partition of 2 GB or smaller.

Oh really? I didn't know that. The bug turns out to be harmless after all. Is there a direct link to the patch to fix this bug? If so, let me know. I'll probably look for the patch online.

I agree. It's fun to use the Wayback Machine to grab old updates before Microsoft pull it from their servers.

It's one of these reasons why Microsoft has been removing links to service packs of old OSes as they've been out of support for years. It's always a good thing for websites to grab the links of critical files for that outdated OS before Microsoft takes them down.

Windows 3 trashes the Current Directory entry upon exit if the drive is formatted to FAT32. Really? How did you know that? I resized the virtual hard disk using VHD resizer from 3 GB to 10 GB, booted up Windows 3.1 on a FAT32 partition in Virtual PC and it did not immediately trash the \WINDOWS directory. But when I started up Windows 3.1 again and exited it, it dropped me back to C:\WINDOWS, I typed in the contents of the \WINDOWS directory and got this: C:\WINDOWS>dir Volume in drive C has no label Volume Serial Number is 2443-1BEE Directory of C:\WINDOWS File not found 9,971.55 MB free C:\WINDOWS> Upon exiting Windows 3.1 on a FAT32 partition, all of the contents of the \WINDOWS directory are gone. I've noticed that this only occurs if Windows 3.x is started from the \WINDOWS directory. SCANDISK refuses to detect any data corruption residing in the \WINDOWS directory when the hard disk gets scanned. Windows 3.0 and Windows 3.1 will end up corrupting the current directory pointer in the drive table entries in MS-DOS 7.1 and MS-DOS 8 respectively. For this reason, Windows 3.x will not properly support hard disk and other media larger than 7.8 GB (or partitions larger than 2 GB on a FAT or FAT 32 partition) without a high probably of data corruption. Hard disk and other media larger than 7.8 GB were not available at the time when Windows 3.0 and Windows 3.1 were released. And the changes that would be required to support hard disks larger than 7.8 GB (and partitions larger than 2 GB) would require architectural changes that will never be supported on Windows 3.x. The only way to fix this is to either run SCANDISK or press CTRL+ALT+DELETE to reboot and the bug should go away.