ppgrainbow

That's the case when I tried to extract it using 7-zip, it didn't work. It looks like that Roy might have made a boo-boo when he made the GIT 2012-06-05 build of Qemu 1.1 and Neozeed (who is in the process of getting his PC rebuilt) hasn't had the time yet to make the official build of Qemu 1.1 for Windows yet. Also, when you hit the CTRL+ALT+2 keys to enter the Qemu Console, it reports it as version 1.1.50. Something is not right. Furthermore, networking hasn't even been working properly since Qemu 1.0.1 either. Let's just hope that problems in Qemu 1.1 gets fixed soon.

On this desktop PC, I currently have Win2k SP4 with UURollup v9b and on the laptop PC that I'm using, I have Windows 95 OSR2. I still have the GRiD 2270 laptop, it has Windows 3.1 w/pen extensions, but it's not working right now, because the battery pack stopped holding a charge.

Okay, I recently installed the tomasz86's UURollup v9b for Win2k and when I attempt to use some of the features, Qemu 1.1 crashes. When I entered "qemu -m 16" (the feature to adjust the memory size to 16 MB for a guest session) or when enter this command "qemu-img create c:\test.img 20M", qemu-img crashes. DrWatson pops up due the error and neither the memory is adjusted nor the hard disk image gets created. I'm sorry if this is not enough information or that I'm not helping but I'm using this build of Qemu 1.1 which has not yet been officially released: http://roy.orz.hm/qemu/qemu-2012060508.zip Anyways, looking at the files I get a Illegal Instruction error message (exception number c000001d). Here are the logs for complete information on why it crashed: Logs for Qemu 1.1: Logs for Qemu-img 1.1: (I'll remove the attachments once this is fixed.) tomasz86, the latest version of the UURollup is great so far, I sure hope that improvements are made to get Qemu 1.1 running.

Well...folks, the final version of Firefox 13 is out now!: http://releases.mozilla.org/pub/mozilla.org/firefox/releases/13.0/win32/en-US/

I'll try to see if these drivers work and report back in my next comment. I'm sorry if I'm taking this long.

Correct. If I strip out the unnecessary drivers, MS-DOS will load correctly. But I run Windows for Workgroups 3.11 on a SCSI hard disk, it will NOT load at all. With one SCSI hard disk, it will kick back to the C: prompt, with four SCSI hard disks, WfW 3.11 will hang at the splash screen. Now looking at lines 15 to 19 of the AUTOEXEC.BAT file, if I replace LH (LOADHIGH) with LOADFIX, the drivers will load correctly on a SCSI hard disk: As for trying this on actual hardware or booting off a SCSI virtual hard disk, it is not possible. It's been so long since I last ran Windows 3.x on a SCSI hard disk, I'm just afraid that it is not even possible to run Windows 3.x correctly in 386 Enhanced Mode on a VMware emulated SCSI hard disk, if not at all. This similar forum thread "WFW 3.11 fails to start - VMWare" believes that the SCSI drivers do not work properly on Windows 3.x when run in 386 Enhanced Mode. Furthermore, a lot of software will not even work correctly or will hang when run from a SCSI hard drive under DOS. With that, I afraid that I have given up and is about to switch back to IDE with a drive overlay.

Okay, here are the contents of the stripped down CONFIG.SYS file and all of the other drivers have been removed: And here are the contents of the stripped down AUTOEXEC.BAT file: I attempted to use FLASHPT.SYS and BTMDISK.SYS and they failed to work in VMware Player. But if I change line 4 of the CONFIG.SYS and remove the BTMDISK.SYS driver and replace it with BTDOSM.SYS below: It will work. All of the other SCSI hard disks, but one have been disabled. >> WHERE does the btdosm.sys come from (it is NOT in the referenced archive)? Where did I get the BTDOSM.SYS driver? Right here: http://www.hiren.info/downloads/dos-files Should I send you an attachment of what the SYSTEM.INI file looks like? Just curious.

You cannot imagine HOW MUCH it is for me. An example of what your posts/reports are NOT like: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/problem-report-standard-litany.html jaclaz I agree. It's really frustrating. On the other hand, MS-DOS and Windows 3.x will work under Qemu 0.15.1 as it supports LSILogic SCSI, but you can't even boot from SCSI drives yet, because that feature is not even implemented yet.

I tried so hard to add these two lines that you mentioned in the config.sys and both the SCSI manager and the BTMDisk manage failed to load. Verbose output from device=c:\buslogic\flashpnt.sys /d throws this error message: SCANNING ADAPTERS AND DEVICES... ERROR: SCSI MANAGER FAILED TO LOAD Verbose output from device=c:\buslogic\btmdisk.sys /d: --> ERROR: DOS ASPI MANAGER NOT LOADED No devices detected to add to system configuration. The only driver that worked is the BTDOSM.SYS driver which when using the /D displays verbose information regarding the SCSI disk. I even REM'd out other drivers and drivers that are loaded with the LH command. Apparently, loading the drivers in the AUTOEXEC.BAT file with the LH (or LOADHIGH) command causes the Sector Not Found error message. And even if I disabled each and every other device including the BusLogic SCSI drivers in the CONFIG.SYS, Windows for Workgroups 3.11 simply refuses to load. It just sends me back to the DOS prompt. I tried to do some research regarding running MS-DOS and Windows 3.x on a virtual SCSI hard disk under VMware, but it was simply no help. In short using the BTDOSM.SYS worked under DOS, but Windows for Workgroups 3.11 still fails to load. Gah, this is frustrating! We will now have to find some workarounds to get WfW 3.11 working on a virtual SCSI hard disk somehow, otherwise, it would be no use.

allen2, I'm trying to get the SCSI drives to work under MS-DOS and Windows 3.x. The SCSI drives did work under Windows 95 and Windows NT 3.51 though.

Cannot say specifically, but first thing, simplify your environment (have ONLY one SCSI disk connected). Then, I cannot see why you don't follow (at least initially) "to the T" the contents of the README.TXT within the given fpdos302 archive. Particularly WHY you did not set to load FLASHPT.SYS (which AFAICU is the "main" driver). WHERE does the btdosm.sys come from (it is NOT in the referenced archive)? Are you using "something else" form what was suggested? jaclaz Okay, I disabled the three other SCSI hard disk and get this output: This means that if I disabled three other SCSI hard disk, this means that BusLogic failed to detect the first SCSI hard disk and upon typing WIN at the command prompt, the VM reboots. And if I load the FLASHPT.SYS as the main driver, I get this output: I don't know where I got the BTDOSM.SYS but it appearently was required to load removable devices and the virtual hard disks are not removable.

Not that I know of, those ARE the LSILogic DOS drivers. jaclaz Thanks for telling me, you might want to refer to my next reply that I made, because I'm still running into trouble getting the SCSI drivers to work properly under MS-DOS 6.22.

Okay, I loaded the BusLogic drivers in the MS-DOS 6.22 VM in the first two lines of the CONFIG.SYS by adding the following: device=c:\buslogic\btdosm.sys device=c:\buslogic\btmdisk.sys /d And upon reboot, this is the output of what I got. Instead of having MS-DOS use drives C through F for the SCSI devices, drives G through I get added to the system configuration and I still get a Sector Not Found error message when loading the drivers in high memory using LH or LOADHIGH on boot in the AUTOEXEC.BAT file. Additionally, I added device=vtdapi.386 in the [386Enh] section of the SYSTEM.INI and Windows for Workgroups 3.11 still doesn't even start at all.. How can I get this corrected?

Yes I am. I will use the FPDOS 3.02, 3.01 and 2.01 drivers and report back verbosely. Are there any VMWare LSILogic SCSI drivers for MS-DOS as well?

Hello. Under VMware Player 2.5.5, I've been running into problems trying to run Windows 3.0 or Windows 3.1x on a BusLogic or a LSILogic SCSI adapter with a SCSI virtual hard disk of less than 2 GB. In one of the VMs that I'm running. Windows 3.0 is currently installed on a 1,000 MB SCSI hard disk with a BusLogic SCSI controller with 16 MB of system RAM. When running Windows 3.0 in 386 Enhanced Mode, attempting to click on the one of the icons in Program Manager throws this error message: After clicking on OK, I get kicked out of Windows 3.0 and into the MS-DOS prompt. In a MS-DOS 6.22 VM, I'm currently emulating four 2,000 MB SCSI hard disks (8,000 MB total) with the virtual CD-ROM on the primary master with 64 MB of memory allocated. The problem here is that when I try to load a driver into high memory, this error message throws up: If I press A to abort the second time, this results in a fatal error message: To fix this, I had to press CTRL+ALT+Insert to reset. And when I attempted to run Windows for Workgroups 3.11 on a emulated SCSI hard disk, it will display the splash screen, but when it attempted to run, it just kicked me out and got thrown back to the C prompt. And in some cases, attempting to run WIN at the command prompt and the VMware Player will end up rebooting by itself. The hard disks are running under the MS-DOS 6.22 VM use the LSILogic Virtual Host Adapter. I'm sorry if this fails to make sense, but is there a way to fix this to make MS-DOS and Windows 3.x work properly with a SCSI hard drive under VMware?

Thank you for getting the bug registered in the database. Hopefully, in Java 6u33, it will get fixed before Java 6 hits EOL this November.

Alright! I think that I finally did the right thing by replacing "freeaddrinfo" with "gethostname". How? I used a hex editor and searched for "freeaddrinfo" the hexadecimal numbers for the entry point are 66 72 65 65 61 64 64 72 69 6E 66 6F. Since "gethostname" has 11 characters, I have to change the 6F hexadecimal to 00, so the end result is that the output for gethostname is 67 65 74 68 6F 73 74 6E 61 6D 65 00. I will now have to download Qemu 1.0, the last (and hexedited) version that fully worked on Windows 2000 and Windows XP RTM to test it out. Update: I found that Qemu 1.0 is unstable and crashing...so, until Qemu 1.1 comes out in June, I will have to stick with Qemu 0.15.1. If I find a way to hex out the dependencies in Qemu 1.1 and get it working, I'll update this reply.

Thank you for telling me. Replacing "freeaddrinfo" with "gethostname" will most likely not work. "freeaddrinfo" has 12 characters and not 11. There is a modified version of Qemu 0.10.5.that still works on Win2k though. I will most likely have to look up online on how to properly replace freeaddrinfo. VMware Workstation 8 and VMware Player 4 require a 64-bit operating system as far as I know.

The output looks similar to the one that you uploaded in your fourth comment. The problem here is that none of the files are being able to detect dependencies that are missing.

Is "depends.txt" created at all? The depends.txt file is not created at all. I did a search for that file on drives C: and D: and came up with nothing.

Yes, I did ran the script on Win2k and for some reason didn't report correctly with the exception of the missing dependencies in WS2_32.DLL. I'm using the US English language version of the OS, btw. As for Dependency Walker, I'm using the latest version - version 2.2.6000 released on 2006-10-29.

Any of the executable files including qemu-system-i386.exe which throws the freeaddrinfo, getaddrinfo and getnameinfo dependencies.

Thanks again. It looks like that the script to check for dependencies didn't correctly check for dependencies that don't exist on Win2k and getting a "There are no dependency issues." message instead of dependency issues found in (filename). What am I doing wrong here?

Thank you for telling me. I'll probably install the UURollup v9b when Firefox 13 comes out for sure. :B

Thank you for telling me. The drivers that are incompatible with Win2k either causes BSODs, doesn't function or even includes dependencies that do not exist on Win2k. It seems that ClamWin and MalwareBytes Antivirus software are the only viable option now. (I've made a forum post regarding Qemu 1.0.1 on Win2k, btw. )