BetaArchive Logo
Navigation Home Database Screenshots Gallery Image Uploader Server Info FTP Servers Wiki Forum RSS Feed Rules Please Donate
UP: 16d, 4h, 0m | CPU: 22% | MEM: 5471MB of 11686MB used
{The community for beta collectors}

Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 67 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Sat May 13, 2017 6:09 pm 
FTP Access
User avatar
Offline

Joined
Wed May 10, 2017 9:08 pm

Posts
76

Location
Chicago, IL

Favourite OS
IBM OS/2 2.11
AlphaBeta wrote:
thunderbird32 wrote:
Battler wrote:
If you download the latest 86Box and the updated ROM set: http://dome.rol.im , you can also emulate the PS/2 models 50, 55SX, and 80, complete with MCA.


Battler, maybe I'm being a complete dunce, but the ROM set on that page (the only one I see is in the "workspace" folder) doesn't seem to include any of the PS/2 models. Am I just missing it?

http://tinyurl.com/rs86b


Awesome! Thank you very much!


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Sun May 14, 2017 6:05 pm 
Donator
User avatar
Offline

Joined
Sat Aug 19, 2006 8:13 am

Posts
2006

Location
Slovenia, Central Europe.

Favourite OS
Windows 98 SE 4.10.2222B
I think this PSA is also valid for pre-release builds of Windows 95.

Also, I just made this thread sticky.

_________________
Join #softhistory @ RoL IRC, a nice community for true enthusiasts!
Anime channel: #doki-doki @ RoL IRC, Mibbit, KiwiIRC.
The 86Box help channel is #softhistory now!

Check out our SoftHistory Forum for quality discussion about older software.


Top  Profile  WWW  ICQ  YIM
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Fri May 19, 2017 5:14 pm 
FTP Access
Offline

Joined
Tue Oct 18, 2016 7:03 pm

Posts
92

Location
/home/thedosprogrammer

Favourite OS
MS-DOS 6.22
Note that VirtualBox and vmWare are virtualizers not emulators! Emulators uses differend rom file and drivers than your hardware.
For pre-Windows 95 emulation are emulators with IBM-compatibile rom file support! Do NOT use dosbox for emulation of Windows 1 or 2.
It'll use your system hardware "converted" to type for MS-DOS emulation. And also running pre-95 Windows on Mac using virtualizers doesn't seen to work.

If you want the best experience use pcem or 86box.

_________________
Image


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Fri May 19, 2017 7:21 pm 
Offline

Joined
Sat Apr 29, 2017 2:21 pm

Posts
74
TheDosProgrammer wrote:
Do NOT use dosbox for emulation of Windows 1 or 2.


Why not? They seem to work quite happily, and opens up possibilities for tweaking things in interesting ways.


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Fri May 19, 2017 10:42 pm 
FTP Access
User avatar
Offline

Joined
Fri Apr 25, 2014 5:37 pm

Posts
516

Location
Poland

Favourite OS
3.11 WfW, 98SE, 5.1.2464, LH4001
Also, you can install actual MS-DOS on DOSBox using img files.


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Fri May 19, 2017 11:43 pm 
Offline

Joined
Sat Apr 29, 2017 2:21 pm

Posts
74
Actually, given the way that pre 95 windows works, basically a dynamic library and overlay manager (pre 3.0), and also as a DOS extender from 3 onwards, I view DOSbox as more or less the perfect vehicle for providing the base layer (modulo any bugs in its DOS compatibility).

Things get more awkward with Enhanced mode, Standard mode is no issue, due to the VXD based VMM having a dependency upon PC specific h/w, but the core of pre 95 windows (the 16 bit stuff) is actually quite machine independent. WFW 3.11 will be in a similar position to W95.

Witness that 1.03 ran on Apricot machines, which is not PC compatible (only DOS compatible), and that presumably the changes were restricted to the drivers: SYSTEM, SOUND, KEYBOARD, DISPLAY.


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Sat May 20, 2017 1:52 pm 
Donator
User avatar
Offline

Joined
Sat Aug 19, 2006 8:13 am

Posts
2006

Location
Slovenia, Central Europe.

Favourite OS
Windows 98 SE 4.10.2222B
- dfawcus: Well, Windows 1.0x and 2.0x also ran on PC-98 and PC-186 (and 3.x also on FM-Towns), none of which are PC compatible. But I am not sure only the drivers differ.

And yes, Enhanced mode Windows is problematic to run in DOSBox, so I'd really recommend something that emulates all the hardware and runs real DOS for that.

_________________
Join #softhistory @ RoL IRC, a nice community for true enthusiasts!
Anime channel: #doki-doki @ RoL IRC, Mibbit, KiwiIRC.
The 86Box help channel is #softhistory now!

Check out our SoftHistory Forum for quality discussion about older software.


Top  Profile  WWW  ICQ  YIM
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Sat May 20, 2017 7:38 pm 
Offline

Joined
Sat Apr 29, 2017 2:21 pm

Posts
74
Battler wrote:
- dfawcus: Well, Windows 1.0x and 2.0x also ran on PC-98 and PC-186 (and 3.x also on FM-Towns), none of which are PC compatible. But I am not sure only the drivers differ.


Well, I don't know exactly how they differed, but given the software architecture, I'd expect the changes to be (largely) confined to the drivers. I'd guess that any changes to KERNEL, USER, GDI would be restricted to the resources part of the file, and that the actual executable portion would be identical to that provided by MS.

So if a given system specific version came supplied with the individual files for which one had to run the setup utility, this supposition of mine shouldn't be too hard to prove. If however, like in the Apricot case, they instead supplied the WINx00.BIN/WINx00.OVL files, it would be a bit more difficult to establish. Requiring a program to rip apart those files, and reassemble the individual input files.

Even then I suppose it would be possible that MS supplied any given OEM with an interim build of the product, and they could have shipped based upon that.

In the case of a non PC compatible Windows 3 distribution, it would also be possible for the VXDs in the VMM bundle to be platform specific.

What I'm driving at is that I doubt that MS supplied source to KERNEL/USER/GDI and hence the executable portions of those in a given (non PC compatible) platform would be as supplied by MS.


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Sun May 21, 2017 4:49 pm 
Donator
User avatar
Offline

Joined
Sat Aug 19, 2006 8:13 am

Posts
2006

Location
Slovenia, Central Europe.

Favourite OS
Windows 98 SE 4.10.2222B
dfawcus wrote:
and that the actual executable portion would be identical to that provided by MS.

Considering the kernel of a PC version most likely uses, say, INT 15h calls to determine the memory size and so on, and these calls are completely different on non-PC-compatibles, I think the kernel needs changes too.
At least the DOS versions also have changes in IO.SYS, MSDOS.SYS, and COMMAND.COM to, in the case of PC-98 version, use INT 18h and port I/O for video and keyboard instead of INT 10h and INT 16h, and so on.
Also, I am quite sure the KERNEL/USER/GDI sources were provided as well. At the very least, NEC needed to adapt the GDI to grab the font from the PC-98 Kanji font ROM for example, and all three modules also contain strings that may need to be localized.
Edit: And that's not to mention that the PC-98 memory map differs as well. On a PC compatible, EMS pages generally go to segments D000-EFFF, which won't work on PC-98 since D000-DFFF are used for peripheral ROM's even on the earliest PC-98's and E000-EFFF is the graphics buffer (which is always available, even in text mode due to the overlay capability), while B000-CFFF are free, so that's where you'd put the EMS pages on a PC-98. I wouldn't be surprised if the Apricots, the Rainbows, etc. have their own differences in both the interrupt vectors and the memory layout as well. Certainly the RM Nimbus PC-186 did, and RM did have the full Windows source code starting from Windows 1.0 pre-release onwards.

_________________
Join #softhistory @ RoL IRC, a nice community for true enthusiasts!
Anime channel: #doki-doki @ RoL IRC, Mibbit, KiwiIRC.
The 86Box help channel is #softhistory now!

Check out our SoftHistory Forum for quality discussion about older software.


Top  Profile  WWW  ICQ  YIM
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Sun May 21, 2017 7:53 pm 
Offline

Joined
Sat Apr 29, 2017 2:21 pm

Posts
74
Battler wrote:
Considering the kernel of a PC version most likely uses, say, INT 15h calls to determine the memory size and so on, and these calls are completely different on non-PC-compatibles, I think the kernel needs changes too.


Granted for Win 3.x, the Dos Extenders may well use Int 15; and KERNEL is probably asking DPMI about what it can get, however for Win 1/2, I suspect they do not use anything more than DOS calls.

Basically both Win 1 and Win 2 are simply using normal DOS conventional memory, and for Win 2, it is additionally using EMS (plus the HMA if available). Neither make use of Extended memory per-se (bar the HMA).

Unless one takes extra pains to limit the amount of memory granted, any DOS program will be allocated all of the conventional memory as its initial allocation. As such they'd not need to do any memory range queries, even if their DOS memory allocation was limited, they could allocate the remainder of the conventional memory using a simple DOS call.

Hence I don't expect either to need platform dependent code in KERNEL to figure out how much memory is available. There would be Int 67 calls in the Win 2 Kernel.

Battler wrote:
At least the DOS versions also have changes in IO.SYS, MSDOS.SYS, and COMMAND.COM to, in the case of PC-98 version, use INT 18h and port I/O for video and keyboard instead of INT 10h and INT 16h, and so on.


To the extent that such were available through DOS calls, there would be no need for KERNEL to have platform dependent logic. As to video, keyboard, serial ports, parallel ports etc - those are specifically the role which DISPLAY, KEYBOARD, MOUSE, COMM etc are intended to serve.

Battler wrote:
Also, I am quite sure the KERNEL/USER/GDI sources were provided as well. At the very least, NEC needed to adapt the GDI to grab the font from the PC-98 Kanji font ROM for example, and all three modules also contain strings that may need to be localized.


The localized strings are what I was referring to by resources. The usual method for building an executable is to generate such (based upon source), then subsequently process the resources (localisable strings) and append the output to the exe file. Hence MS could deliver executables with source for the resources, and makefiles that simply compile the resources, then combine them with the executables to make the final deliverable executable. This is similar to the approach they took with the MSDOS OAK - some parts a source, but the core simply as Object files.

For Windows 1 & 2, there is logic in KEYBOARD to inform KERNEL about Far East (Kanji etc) character mapping ranges, dual byte sequences I believe. One could have the DISPLAY driver grab the font info and pass it to the FONT/OEMFONT modules, possibly also give the FONT modules some real init code, so maybe they could grab the data themselves. However, there are no guarantees about what method a programmer may take to achieve what they want when under time pressure, so if the NEC folk did have access to the source, I'd not be surprised at them hacking in logic wherever it was easiest.

That said, I'm not excluding the possibility of OEMs being shown the source, possibly for USER, maybe as you suggest for GDI, but probably not for KERNEL (as I don't see the need for the latter), but who knows what any individual contract may have contained. However I'd not expect this to be the normal case.

Battler wrote:
I wouldn't be surprised if the Apricots, the Rainbows, etc. have their own differences in both the interrupt vectors and the memory layout as well.


Given the Apricot h/w, I expect the platform dependent bits for it to be contained wholly within the drivers. I may have a go at splitting apart its fast boot files, and see if I can prove that (modulo resource changes). Since for the moment this is (on my part) largely simply informed speculation.

Battler wrote:
Certainly the RM Nimbus PC-186 did, and RM did have the full Windows source code starting from Windows 1.0 pre-release onwards.


Interesting, I wonder why? Do you have a reference for that assertion?
I seem to recall that I've used one of those machines - around 1989?


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Mon May 22, 2017 12:55 pm 
Donator
User avatar
Offline

Joined
Sat Aug 19, 2006 8:13 am

Posts
2006

Location
Slovenia, Central Europe.

Favourite OS
Windows 98 SE 4.10.2222B
dfawcus wrote:
Granted for Win 3.x, the Dos Extenders may well use Int 15; and KERNEL is probably asking DPMI about what it can get, however for Win 1/2, I suspect they do not use anything more than DOS calls.

Basically both Win 1 and Win 2 are simply using normal DOS conventional memory, and for Win 2, it is additionally using EMS (plus the HMA if available). Neither make use of Extended memory per-se (bar the HMA).

Unless one takes extra pains to limit the amount of memory granted, any DOS program will be allocated all of the conventional memory as its initial allocation. As such they'd not need to do any memory range queries, even if their DOS memory allocation was limited, they could allocate the remainder of the conventional memory using a simple DOS call.

Hence I don't expect either to need platform dependent code in KERNEL to figure out how much memory is available. There would be Int 67 calls in the Win 2 Kernel.

I thought Win/286 and Win/386's kernels would need to deal with memory above 1 MB. Of course, real mode versions wouldn't, but 286 and 386 versions would, even in Windows 2.x. And even then, for example, from what I recall, the RM Nimbus PC-186 for example had more than 640 kB conventional memory, so definitely the kernel had to be made aware of that.
And the KERNEL does do memory management even in Windows 1.x, in fact, that's where the bad bug was in Premiere Edition which caused a delay in public shipment and the first public version to be 1.01.

Quote:
To the extent that such were available through DOS calls, there would be no need for KERNEL to have platform dependent logic. As to video, keyboard, serial ports, parallel ports etc - those are specifically the role which DISPLAY, KEYBOARD, MOUSE, COMM etc are intended to serve.

What about the PIC? After all, the KERNEL has to intercept IRQ-generated INT's and pass them to the drivers, and the IRQ to INT mapping differs on each platform, as is the I/O ports the one or two PIC's listen on. And there's no DOS call for that. Same goes for DMA operation.

Quote:
For Windows 1 & 2, there is logic in KEYBOARD to inform KERNEL about Far East (Kanji etc) character mapping ranges, dual byte sequences I believe. One could have the DISPLAY driver grab the font info and pass it to the FONT/OEMFONT modules, possibly also give the FONT modules some real init code, so maybe they could grab the data themselves. However, there are no guarantees about what method a programmer may take to achieve what they want when under time pressure, so if the NEC folk did have access to the source, I'd not be surprised at them hacking in logic wherever it was easiest.

In Windows, it's the GDI that handles the fonts, not the DISPLAY driver, or at least it was so in Windows 3.x (hence why replacing the Farsi version's GDI.EXE with some other version messes up the text for example).

Quote:
Interesting, I wonder why? Do you have a reference for that assertion?
I seem to recall that I've used one of those machines - around 1989?

I suspect probably exactly because KERNEL changes were needed. Also, the source for the assertion is a RM employee, I forgot who. Ask The Distractor for more information.

_________________
Join #softhistory @ RoL IRC, a nice community for true enthusiasts!
Anime channel: #doki-doki @ RoL IRC, Mibbit, KiwiIRC.
The 86Box help channel is #softhistory now!

Check out our SoftHistory Forum for quality discussion about older software.


Top  Profile  WWW  ICQ  YIM
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Thu May 25, 2017 8:42 pm 
Offline

Joined
Sat Apr 29, 2017 2:21 pm

Posts
74
This is not conclusive yet, as I've not finished the programs, but analysing the Siemens PC-D images which Overdoze pointed to, and contrasting to the normal 1.02 files we get the following.

Generic PC:
Code:
 0 : 00000 + 00400 (   1024) / 00000 + 00000 |     STUB|
 1 : 00400 + 07b00 (  31488) / 00020 + 005f0 |   KERNEL| Microsoft Windows Kernel Interface for 2.x and 3.x
 2 : 07f00 + 004b0 (   1200) / 00610 + 000c0 |   SYSTEM| Microsoft Windows System configuration module for IBM/PC/XT/AT
 3 : 083b0 + 00720 (   1824) / 006d0 + 000a0 | KEYBOARD| KEYBOARD United States, Mexico:1!0!0!2!0!0!AM!PM!$!,!.!/!:!,!!52!1!0!2!0!0!AM!PM!$!,!.!/!:!,
 4 : 08ad0 + 005c0 (   1472) / 00770 + 00040 |    MOUSE| Microsoft Mouse (Bus/Serial)
 5 : 09090 + 03420 (  13344) / 007b0 + 01210 |  DISPLAY| DISPLAY : 133, 96, 72 : EGA (more than 64K) with Enhanced Color Display
 6 : 0c4b0 + 00150 (    336) / 019c0 + 00f40 |    SOUND| Windows Sound Driver
 7 : 0c600 + 00c30 (   3120) / 02900 + 000b0 |     COMM| Windows Communications Driver
 8 : 0d230 + 00c90 (   3216) / 029b0 + 018b0 |    FONTS| FONTRES 133,96,72 : System, Terminal (Set #3)
 9 : 0dec0 + 08260 (  33376) / 04260 + 12060 |      GDI| Microsoft Windows Graphics Device Interface
10 : 16120 + 10c10 (  68624) / 162c0 + 13f70 |     USER| Microsoft Windows User Interface
11 : 26d30 + 00080 (    128) / 2a230 + 012c0 |   MSDOSD| Windows MSDOS Machine Dependent
12 : 26db0 + 05d30 (  23856) / 2b4f0 + 09fd0 |    MSDOS| Microsoft Windows MSDOS Executive Application
13 : 2cae0 + 00210 (    528) / 00000 + 00000 |     Tail|


PC-D:
Code:
 0 : 00000 + 00400 (   1024) / 00000 + 00000 |     STUB|
 1 : 00400 + 07b00 (  31488) / 00020 + 005f0 |   KERNEL| Microsoft Windows Kernel Interface for 2.x and 3.x
 2 : 07f00 + 003e0 (    992) / 00610 + 000c0 |   SYSTEM| Microsoft Windows System configuration module for SIEMENS PC-D
 3 : 082e0 + 00780 (   1920) / 006d0 + 00060 | KEYBOARD| Western Germany
 4 : 08a60 + 00230 (    560) / 00730 + 00040 |    MOUSE| Microsoft Mouse (Bus/Serial)
 5 : 08c90 + 02790 (  10128) / 00770 + 01210 |  DISPLAY| DISPLAY : 133, 96, 72 : EGA with Enhanced Color Display (Black and White Display)
 6 : 0b420 + 00200 (    512) / 01980 + 00c80 |    SOUND| Windows Sound Driver
 7 : 0b620 + 00bd0 (   3024) / 02600 + 000b0 |     COMM| Windows Communications Driver
 8 : 0c1f0 + 00c90 (   3216) / 026b0 + 018b0 |    FONTS| FONTRES 133,96,72 : System, Terminal (Set #3)
 9 : 0ce80 + 08260 (  33376) / 03f60 + 12060 |      GDI| Microsoft Windows Graphics Device Interface
10 : 150e0 + 10c10 (  68624) / 15fc0 + 13f70 |     USER| Microsoft Windows User Interface
11 : 25cf0 + 00080 (    128) / 29f30 + 00f70 |   MSDOSD| Windows MSDOS Machine Dependent
12 : 25d70 + 05d30 (  23856) / 2aea0 + 09fd0 |    MSDOS| Microsoft Windows MSDOS Executive Application
13 : 2baa0 + 00210 (    528) / 00000 + 00000 |     Tail|


The columns are (in order): Sequence in .BIN/.OVL, start offset within .BIN, length within .BIN, length in decimal, start offset within .OVL, length within .OVL, module name, module description.

It is interesting to note that the lengths for KERNEL, USER, GDI, and MSDOS (the shell) are identical in both; I've not yet compared the contents of those modules.

In contast the PC-D 2.11 BIN/OVL doesn't match the Generic PC version, as the description string in the kernel more closely matches the Generic 2.10 version:

Generic 2.10:
Code:
 1 : 00400 + 0d770 (  55152) / 00000 + 02ee0 |   KERNEL| Microsoft Windows Kernel Interface for 2.x and 3.x
10 : 174b0 + 08570 (  34160) / 0b4e0 + 12c70 |      GDI| Microsoft Windows Graphics Device Interface
11 : 1fa20 + 15ba0 (  88992) / 1e150 + 19560 |     USER| Microsoft Windows User Interface
13 : 35640 + 036f0 (  14064) / 38c00 + 0adb0 |    MSDOS| Microsoft Windows MSDOS Executive Application


PC-D 2.11:
Code:
 1 : 00400 + 0d160 (  53600) / 00000 + 02ee0 |   KERNEL| Microsoft Windows Kernel Interface for 2.x and 3.x
10 : 13e00 + 08570 (  34160) / 092a0 + 12c70 |      GDI| Microsoft Windows Graphics Device Interface
11 : 1c370 + 15bf0 (  89072) / 1bf10 + 195b0 |     USER| Microsoft Windows User Interface
13 : 31fe0 + 038c0 (  14528) / 36970 + 0b0d0 |    MSDOS| Microsoft Windows MSDOS Executive Application


Generic 2.11:
Code:
 1 : 00400 + 0d830 (  55344) / 00000 + 02ea0 |   KERNEL| Microsoft Windows Kernel Interface Version 2.11
10 : 17590 + 08570 (  34160) / 0b4a0 + 12c70 |      GDI| Microsoft Windows Graphics Device Interface
11 : 1fb00 + 15ba0 (  88992) / 1e110 + 19560 |     USER| Microsoft Windows User Interface
13 : 35720 + 036f0 (  14064) / 38bc0 + 0adb0 |    MSDOS| Microsoft Windows MSDOS Executive Application


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Thu May 25, 2017 8:53 pm 
Offline

Joined
Sat Apr 29, 2017 2:21 pm

Posts
74
Doing the same for the Apricot files, and the generic 1.03 we get the following.

Generic 1.03:
Code:
 1 : 00400 + 07b10 (  31504) / 00020 + 00610 |   KERNEL| Microsoft Windows Kernel Interface for 2.x and 3.x
 2 : 07f10 + 004f0 (   1264) / 00630 + 000c0 |   SYSTEM| Microsoft Windows System configuration module for IBM/PC/XT/AT
 3 : 08400 + 00810 (   2064) / 006f0 + 000e0 | KEYBOARD| KEYBOARD United States, Mexico:1!0!0!2!0!0!AM!PM!$!,!.!/!:!,!!52!1!0!2!0!0!AM!PM!$!,!.!/!:!,
 4 : 08c10 + 00750 (   1872) / 007d0 + 00410 |    MOUSE| Microsoft Mouse (Bus/Serial)
 5 : 09360 + 03420 (  13344) / 00be0 + 01210 |  DISPLAY| DISPLAY : 133, 96, 72 : EGA (more than 64K) with Enhanced Color Display
 6 : 0c780 + 00150 (    336) / 01df0 + 00f40 |    SOUND| Windows Sound Driver
 7 : 0c8d0 + 00c20 (   3104) / 02d30 + 000b0 |     COMM| Windows Communications Driver
 8 : 0d4f0 + 00c90 (   3216) / 02de0 + 018b0 |    FONTS| FONTRES 133,96,72 : System, Terminal (Set #3)
 9 : 0e180 + 082f0 (  33520) / 04690 + 119f0 |      GDI| Microsoft Windows Graphics Device Interface
10 : 16470 + 10c20 (  68640) / 16080 + 13f80 |     USER| Microsoft Windows User Interface
11 : 27090 + 00080 (    128) / 2a000 + 01400 |   MSDOSD| Windows MSDOS Machine Dependent
12 : 27110 + 05dc0 (  24000) / 2b400 + 0a300 |    MSDOS| Microsoft Windows MSDOS Executive Application


Apricot XEN:
Code:
 1 : 00400 + 07b10 (  31504) / 00030 + 00610 |   KERNEL| Microsoft Windows Kernel Interface for 2.x and 3.x
 2 : 07f10 + 003c0 (    960) / 00640 + 000c0 |   SYSTEM| Microsoft Windows System configuration module for IBM/PC/XT/AT
 3 : 082d0 + 00a30 (   2608) / 00700 + 00090 | KEYBOARD| KEYBOARD United Kingdom:44!1!0!2!1!0!AM!PM!�!,!.!-!:!,
 4 : 08d00 + 00b10 (   2832) / 00790 + 00040 |    MOUSE| Microsoft Mouse (Bus/Serial)
 5 : 09810 + 03960 (  14688) / 007d0 + 01220 |  DISPLAY| DISPLAY : 150, 108, 72 :HERCULES GRAPHICS CARD (OR COMAPTIBLE) WITH MONOCHROME DISPLAY
 6 : 0d170 + 00120 (    288) / 019f0 + 00ce0 |    SOUND| Windows Sound Driver
 7 : 0d290 + 012d0 (   4816) / 026d0 + 000b0 |     COMM| Windows Communications Driver
 8 : 0e560 + 01280 (   4736) / 02780 + 026b0 |    FONTS| FONTRES 133,96,72 : System, Terminal (Set #3)
 9 : 0f7e0 + 082f0 (  33520) / 04e30 + 119f0 |      GDI| Microsoft Windows Graphics Device Interface
10 : 17ad0 + 10c10 (  68624) / 16820 + 13f70 |     USER| Microsoft Windows User Interface
11 : 286e0 + 00080 (    128) / 2a790 + 00150 |   MSDOSD| Windows MSDOS Machine Dependent
12 : 28760 + 05dc0 (  24000) / 2a8e0 + 0a300 |    MSDOS| Microsoft Windows MSDOS Executive Application


In this the USER module differs in length, but its length match those for the Generic 1.02 release.


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Fri May 26, 2017 7:05 pm 
Donator
User avatar
Offline

Joined
Sat Aug 19, 2006 8:13 am

Posts
2006

Location
Slovenia, Central Europe.

Favourite OS
Windows 98 SE 4.10.2222B
Have you actually compared the code? You could have radically different code that still has the same length.

_________________
Join #softhistory @ RoL IRC, a nice community for true enthusiasts!
Anime channel: #doki-doki @ RoL IRC, Mibbit, KiwiIRC.
The 86Box help channel is #softhistory now!

Check out our SoftHistory Forum for quality discussion about older software.


Top  Profile  WWW  ICQ  YIM
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Fri May 26, 2017 8:38 pm 
Offline

Joined
Sat Apr 29, 2017 2:21 pm

Posts
74
Battler wrote:
Have you actually compared the code? You could have radically different code that still has the same length.

As I wrote:
dfawcus wrote:
I've not yet compared the contents of those modules.

and the reason why, is this:
dfawcus wrote:
as I've not finished the programs

Hence I've not yet extracted them back to base New Executable files, and so have not performed a detailed comparison.


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Wed Jul 12, 2017 6:19 pm 
User avatar
Offline

Joined
Wed Jul 12, 2017 6:03 pm

Posts
41

Favourite OS
Windows 7
I think pre-95 OS's work fine on VMware!

_________________
Image


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Thu Jul 13, 2017 2:46 pm 
Donator
User avatar
Offline

Joined
Sun Aug 12, 2012 4:33 pm

Posts
2004

Location
Czechia
TheWinnerCollector111 wrote:
I think pre-95 OS's work fine on VMware!

You might want to read the rest of the thread to see why it's recommended to use an emulator.

_________________
AlphaBeta, stop brainwashing me immediately!

Image


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Fri Jul 14, 2017 6:06 am 
Windows 3.x works fine on VirtualBox, especially for Mac users who cannot use PCem or PCE. DOSBox likes to be uncooperative sometimes, and high color support on Mac is somewhat broken-- everything is tinted red for some reason.

But Windows 1.x and 2.x? Definitely use PCem, PCE or another emulator. I agree with you.


Top
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Sun Aug 06, 2017 8:43 am 
Offline

Joined
Sat Aug 05, 2017 5:05 pm

Posts
11

Favourite OS
SP3
I agree that Windows 3.x works fine on VirtualBox. I actually prefer VirtualBox when I'm being productive (getting data from legacy systems etc). However, for games, DosBox is probably the best way to go imo.


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Sun Aug 06, 2017 12:16 pm 
Donator
User avatar
Offline

Joined
Sat Aug 19, 2006 8:13 am

Posts
2006

Location
Slovenia, Central Europe.

Favourite OS
Windows 98 SE 4.10.2222B
- jman: Yes, it works fine now. But there's increasing amounts of hardware on which Windows 3.1 does not work fine on VirtualBox.

_________________
Join #softhistory @ RoL IRC, a nice community for true enthusiasts!
Anime channel: #doki-doki @ RoL IRC, Mibbit, KiwiIRC.
The 86Box help channel is #softhistory now!

Check out our SoftHistory Forum for quality discussion about older software.


Top  Profile  WWW  ICQ  YIM
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Sun Aug 06, 2017 2:50 pm 
Offline

Joined
Sat Aug 05, 2017 5:05 pm

Posts
11

Favourite OS
SP3
VirtualBox is still under active development by Oracle. Chances are pretty good that they will keep pace as hardware issues arise.


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Sun Aug 06, 2017 4:04 pm 
Donator
User avatar
Offline

Joined
Sat Aug 19, 2006 8:13 am

Posts
2006

Location
Slovenia, Central Europe.

Favourite OS
Windows 98 SE 4.10.2222B
- jman: Except I doubt they care about running Windows 3.1 (which is proven by the fact they haven't even released VM Additions for Windows 3.1). Also, they can't fix problems due to changes in host CPU operations - if an instruction no longer works the way it did in 1992, there's nothing the VirtualBox developers can do about that.

_________________
Join #softhistory @ RoL IRC, a nice community for true enthusiasts!
Anime channel: #doki-doki @ RoL IRC, Mibbit, KiwiIRC.
The 86Box help channel is #softhistory now!

Check out our SoftHistory Forum for quality discussion about older software.


Top  Profile  WWW  ICQ  YIM
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Sun Aug 06, 2017 11:23 pm 
Offline

Joined
Sat Aug 05, 2017 5:05 pm

Posts
11

Favourite OS
SP3
VirtualBox has a 3.1 mode you can select when you first spin up the virtual machine. Maybe they didn't have this in prior versions?

You have a good point about CPU issues. For me at least, I'm only coming across issues running games of that era, which could often be a bit hacky at times. Thus my route... VirtualBox for work, DosBox for play.


Top  Profile
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Mon Aug 07, 2017 6:38 pm 
Donator
User avatar
Offline

Joined
Wed Feb 23, 2011 12:11 am

Posts
3529

Location
Italy

Favourite OS
Windows, OS/2, DOS
If you want higher resolutions on Windows 3.1x, just use 86Box, it has good support for the trio64 and virge class cards.
This emulator (86Box) behaves better than DOSBox, in general, even for PC Win3.1x games and it has a proper UI.

_________________
http://forum.softhistory.org


Top  Profile  WWW
 PostPost subject: Re: PSA: Don't use VirtualBox or VMWare for things pre-Win95        Posted: Tue Aug 08, 2017 1:33 am 
Staff
User avatar
Offline

Joined
Thu Oct 11, 2007 9:13 pm

Posts
2025

Location
United States

Favourite OS
MacOS 9.2.2
TheCollector1988 wrote:
If you want higher resolutions on Windows 3.1x, just use 86Box, it has good support for the trio64 and virge class cards.
This emulator (86Box) behaves better than DOSBox, in general, even for PC Win3.1x games and it has a proper UI.


I think the popular consensus has been established to use 86box about twenty times now. I think the point has been made.

_________________
James *~*~* BA Moderator | Alternate History writer


Top  Profile
Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 67 posts ]  Go to page Previous  1, 2, 3  Next




Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  

All views expressed in these forums are those of the author and do not necessarily represent the views of the BetaArchive site owner.

Powered by phpBB® Forum Software © phpBB Group

Copyright © 2006-2019

 

Sitemap | XML | RSS