[comp.unix.sysv386] Does WINDOWS run under VP/ix?

graham@convex.com (Marv Graham) (05/11/91)

I am new to this group and don't know where the FAQ file is.  This surely
must be a frequently asked question.  What results are people having?
I'd hate to lose the use of CORELdraw (and other MS-DOS apps) by going to UNIX.

rbraun@spdcc.COM (Rich Braun) (05/14/91)

graham@convex.com (Marv Graham) writes:
>I am new to this group and don't know where the FAQ file is.  This surely
>must be a frequently asked question.  What results are people having?

Hmm--there ought to be a central repository of FAQ's for netnews.  Maybe
someone'll come up with such a thing sometime soon.  (Ideally it could
be accessed directly as a single keypress within netnews, like the Plato
'notes' system developed at U. Illinois a decade and a half ago.)

Anyway, as to whether Windows works under VP/ix:  yes.  Under SCO Unix,
you'll have to install a patch so it doesn't get some sort of illegal-
instruction error.  It's called Support Level Supplement number 268, and
you can get it from SCO or from the SCO archive directory on uunet.
Under ISC, it probably works without the need for such a patch.

-rich

lh@aega84.UUCP (L. Hirschbiegel) (05/14/91)

In article <1991May10.203634.8487@convex.com> graham@convex.com (Marv Graham) writes:
>I am new to this group and don't know where the FAQ file is.  This surely
>must be a frequently asked question.  What results are people having?
>I'd hate to lose the use of CORELdraw (and other MS-DOS apps) by going to UNIX.

Don't despair - you wont loose that wonderful DOS feeling... :-)
All you need is the famous "vpix upgrade 1.2.1" from ISC and Win3.0
will run.
Be prepared for several annoying messages like "not enough memory" when
running Win3.0 under VPIX, but at least it works. I have no reason to
complain about speed on my EISA 486/33, it's like a fast 286 (no exact
measurement here, just from the "look and feel").
I've also found some problems with very large directories when using the
standard file manager. Until now I didn't come across any application 
which refuses to run under the VPIX/Win combination - but then again I 
didn't try to run really large "monster" applications, just some of the
PD software packages and WinWord (you don't want THAT:-).

And if Win3.0 blows just switch to another vt with X11 running - the real
thing... :-)

Lothar Hirschbiegel
-- 
====================================================================
L. Hirschbiegel, AEG Produktionsautomatisierung, Frankfurt (Germany)
unido!aega84!lh                                      -49-69-66414316
====================================================================

leo@aai.com (05/14/91)

rbraun@spdcc.COM (Rich Braun) writes:

>graham@convex.com (Marv Graham) writes:
>>I am new to this group and don't know where the FAQ file is.  This surely
>>must be a frequently asked question.  What results are people having?

>Hmm--there ought to be a central repository of FAQ's for netnews.  Maybe
>someone'll come up with such a thing sometime soon.  (Ideally it could
>be accessed directly as a single keypress within netnews, like the Plato
>'notes' system developed at U. Illinois a decade and a half ago.)

This very proposal is being "debated" right now in news.groups.

>Anyway, as to whether Windows works under VP/ix:  yes.  Under SCO Unix,
>you'll have to install a patch so it doesn't get some sort of illegal-
>instruction error.  It's called Support Level Supplement number 268, and
>you can get it from SCO or from the SCO archive directory on uunet.
>Under ISC, it probably works without the need for such a patch.

An update, available from ISC, is necessary to run Windows 3.0 under VPIX
on ISC 2.2.
-- 
Leo	leo@aai.com   leo%aai@uunet.uu.net   ...uunet!aai!leo

dmocsny@minerva.che.uc.edu (Daniel Mocsny) (05/15/91)

In article <1991May14.164301.15364@aai.com> leo@aai.com writes:
>An update, available from ISC, is necessary to run Windows 3.0 under VPIX
>on ISC 2.2.

Wow! Will this update run any of the other troublesome vpix-buster
software such as the Borland Turbo Debugger? And can it run 386-
protected-mode DOS software such as the Borland TD386 version of
the Turbo Debugger?

Gosh, if it did, that would turn vpix into the equivalent of a
386 machine while running on a 386 machine... :-)


--
Dan Mocsny				
Internet: dmocsny@minerva.che.uc.edu

greg@halexii.uucp (Gregory F. Hogg) (05/15/91)

Windows does work under ISC 2.2 with a patch
-- 

				Greg Hogg

			COMPANY	: HOGG'S SOFTWARE

dag@gorgon.uucp (Daniel A. Glasser) (05/17/91)

In article <8466@uceng.UC.EDU> dmocsny@minerva.che.uc.edu (Daniel Mocsny) writes:
>In article <1991May14.164301.15364@aai.com> leo@aai.com writes:
>>An update, available from ISC, is necessary to run Windows 3.0 under VPIX
>>on ISC 2.2.
>Wow! Will this update run any of the other troublesome vpix-buster
>software such as the Borland Turbo Debugger? And can it run 386-
>protected-mode DOS software such as the Borland TD386 version of
>the Turbo Debugger?

Sorry, no.  The update from ISC for VPIX lets MS-Windows 3.0 run in
real mode only.  No standard ('286) mode, no Extended ('386) mode.
It would be amusing, but Intel didn't make the '386 (or '486) such
that it is easy for one set of '386 protected mode code to simulate
the iron for another set of '386 protected mode code which is simulaing
the iron for a bunch of 8086 (real-mode) virtual machines.  It might
be possible to do, just not easy (both Unix and Windows want to directly
bang on the MMU...  This is hard to trap/simulate transparently.)
Maybe someone ought to solve the DOS under Unix problem for '386 systems
the way I've seen DOS and CP/M done for non-ISA machines for years...
A hardware solution!  A real '386sx on a bus slot with some shared RAM or
DMA and some custom ICs that look to the 'sx as if they are standard
ISA peripherals (floppy controller, HD controller, VGA registers, keyboard
port, serial, etc.) and allow the main CPU to control access to the
real devices or simulate the hardware and do wholesale swaps of
machine context to allow multiple users to use the same board without
the 'protected mode' software knowing about it at all.  You should even
be able to run some '386 version of Unix (though this might be pushing
it) on the inner box and run VPIX on that :)

					Just a few thoughts from
					the endless stream of
					meaningless drivel from
					incoherent mind of

						Daniel A. Glasser

Disclaimer:  The opinions expressed in this posting are not necessarily
             those of WOOF FM, it's management or sponsers.  They belong
             to the poster, and he is welcome to them.
-- 
Daniel A. Glasser                       One of those things that goes
dag%gorgon@persoft.com                  "BUMP! (ouch!)" in the night.

glenn@suphys.physics.su.OZ.AU (Glenn Geers) (05/17/91)

From article <1991May17.010926.338@gorgon.uucp>, by dag@gorgon.uucp (Daniel A. Glasser):
> In article <8466@uceng.UC.EDU> dmocsny@minerva.che.uc.edu (Daniel Mocsny) writes:
>>In article <1991May14.164301.15364@aai.com> leo@aai.com writes:
>>>An update, available from ISC, is necessary to run Windows 3.0 under VPIX
>>>on ISC 2.2.
>>Wow! Will this update run any of the other troublesome vpix-buster
>>software such as the Borland Turbo Debugger? And can it run 386-
>>protected-mode DOS software such as the Borland TD386 version of
>>the Turbo Debugger?
> 
> Sorry, no.  The update from ISC for VPIX lets MS-Windows 3.0 run in
> real mode only.  No standard ('286) mode, no Extended ('386) mode.
> It would be amusing, but Intel didn't make the '386 (or '486) such
> that it is easy for one set of '386 protected mode code to simulate
> the iron for another set of '386 protected mode code which is simulaing
> the iron for a bunch of 8086 (real-mode) virtual machines.  It might
> be possible to do, just not easy (both Unix and Windows want to directly
> bang on the MMU...  This is hard to trap/simulate transparently.)
> Maybe someone ought to solve the DOS under Unix problem for '386 systems
> the way I've seen DOS and CP/M done for non-ISA machines for years...
> A hardware solution!  A real '386sx on a bus slot with some shared RAM or
> DMA and some custom ICs that look to the 'sx as if they are standard
> ISA peripherals (floppy controller, HD controller, VGA registers, keyboard
> port, serial, etc.) and allow the main CPU to control access to the
> real devices or simulate the hardware and do wholesale swaps of
> machine context to allow multiple users to use the same board without
> the 'protected mode' software knowing about it at all.  You should even
> be able to run some '386 version of Unix (though this might be pushing
> it) on the inner box and run VPIX on that :)

Don't forget UNIX runs in one 4 Gb segment. I think it is possible to have
a supervisor running in another segment that could switch between UNIX and
windows 3.0 in protected mode. The segment selector is 16 bits wide so you
get 65536 segments (i.e. the 386 can address up to 2^16*2^32 bytes of (very)
virtual memory). What I'm saying is that you could run a lot of different
protected mode operating systems if you had a suitable supervisor program
to manage segment swapping - I'd hate to wait for a 4Gb swap! - and memory
fragmentation and compaction would be a pain!

This idea is explained more fully in "Programming the 80386" by [name forgotten]
and Gellsinger (sp?) - a friend has my copy at present...

> 
> 					Just a few thoughts from
> 					the endless stream of
> 					meaningless drivel from
> 					incoherent mind of
> 
> 						Daniel A. Glasser
> 
> Disclaimer:  The opinions expressed in this posting are not necessarily
>              those of WOOF FM, it's management or sponsers.  They belong
>              to the poster, and he is welcome to them.
> -- 
> Daniel A. Glasser                       One of those things that goes
> dag%gorgon@persoft.com                  "BUMP! (ouch!)" in the night.

Even more mindless drivel,

Glenn
--
___________________________________________________________________________
Glenn Geers                       | "So when it's over, 
                                  |  we're back to people.
Department of Theoretical Physics |  Just to prove that human touch
The University of Sydney          |  can have no equal."
Sydney NSW 2006 Australia         |  - Basia Trzetrzelewska, 'Prime Time TV'
                                  |
Phone: +61 2 692-3241 (voice)     |_________________________________________
       +61 2 660-2903 (fax)       |
                                  |
glenn@qed.physics.su.oz.au        | #include <standard_disclaimer.h>
                                  |
----------------------------------------------------------------------------

nlane@well.sf.ca.us (Nathan D. Lane) (05/19/91)

It would be quite a sight to see a 386 running multiple 386 virtual
processors! :)  The idea of using a 386 in a unix box has been done
by several vendors:  Everex in thier Step 88000 workstations uses
a 286/386sx/386 CPU for i/o processing and running DOS.
I did read an interesting tid-bit in Undocumented DOS - it would
be possible for someone to implement DPMI (Dos Protected Mode
Interface) in Unix (using Unix as the DPMI server).  That would
enable at least Standard mode Windows to run Under Unix (as the
DPMI client).  Any takers...:)?

-Nathan Lane
Digital Technology Service, Santa Barbara, CA
(805) 683-3760        Authorized Esix Resellers

peet@locus.com (J. David Peet) (05/21/91)

In article <24867@well.sf.ca.us> nlane@well.sf.ca.us (Nathan D. Lane) writes:
>
>It would be quite a sight to see a 386 running multiple 386 virtual
>processors! :)  The idea of using a 386 in a unix box has been done
>by several vendors:  Everex in thier Step 88000 workstations uses
>a 286/386sx/386 CPU for i/o processing and running DOS.
>I did read an interesting tid-bit in Undocumented DOS - it would
>be possible for someone to implement DPMI (Dos Protected Mode
>Interface) in Unix (using Unix as the DPMI server).  That would
>enable at least Standard mode Windows to run Under Unix (as the
>DPMI client).  Any takers...:)?
>
>-Nathan Lane
>Digital Technology Service, Santa Barbara, CA
>(805) 683-3760        Authorized Esix Resellers

Locus Computing Corporation is one of the twelve founding members
of the DPMI committee.  We plan on implementing DPMI in a future
release of DOS Merge.  We have not announced any timeframe for this.
When DPMI is implemented as a part of Merge, it will allow DOS
programs that are written to the "1.0" spec to fully use all the
386 protected mode features, while running as a process under UNIX!

-David Peet
--------------------------------------------------------------------- 
peet@locus.COM                                                     
Merge Development Group,    Locus Computing Corporation, Los Angeles
---------------------------------------------------------------------

jjb@triada.UUCP (Jack Bailey) (05/29/91)

I'm currently having a problem with WINDOWS under VP/ix.  With the
SSU installed, WINDOWS comes up and works fine.  Sometime afterword,
I installed FAS 2.08 to replace the async drivers, promptly causing
the serial mouse connected to COM1 to stop working.  Upon starting
VP/ix, I now get the error message "cannot send serial info."  TFM
says that I must use a standard kernel.

Has anyone else seen this problem?

BTW, I made the necessary changes to vpix.cnf.

wes@harem.clydeunix.com (Barnacle Wes) (06/01/91)

In article <1991May17.105152.1870@metro.ucc.su.OZ.AU>, glenn@suphys.physics.su.OZ.AU (Glenn Geers) writes:
> Don't forget UNIX runs in one 4 Gb segment. I think it is possible to have
> a supervisor running in another segment that could switch between UNIX and
> windows 3.0 in protected mode. The segment selector is 16 bits wide so you
> get 65536 segments (i.e. the 386 can address up to 2^16*2^32 bytes of (very)
> virtual memory). What I'm saying is that you could run a lot of different
> protected mode operating systems if you had a suitable supervisor program
> to manage segment swapping - I'd hate to wait for a 4Gb swap! - and memory
> fragmentation and compaction would be a pain!

I think you'd have to re-write the VM handler code in the unix kernel
pretty extensively to do this; all of the REAL operating systems :-)
running in such a system are going to want control of the Global
Descriptor Table, and I think the GDT would differ greatly from system
to system.  The 386 allows you multiple virtual 8086s, but not multiple
virtual 386s.

	Wes Peters
-- 
#include <std/disclaimer.h>                               The worst day sailing
My opinions, your screen.                                   is much better than
Raxco had nothing to do with this!                        the best day at work.
     Wes Peters:  wes@harem.clydeunix.com   ...!sun!unislc!harem!wes

lothar@tmcsys.UUCP (L. Hirschbiegel) (06/02/91)

In article <314@harem.clydeunix.com> wes@harem.clydeunix.com (Barnacle Wes) writes:
+In article <1991May17.105152.1870@metro.ucc.su.OZ.AU>, glenn@suphys.physics.su.OZ.AU (Glenn Geers) writes:
+> [ ... ]  What I'm saying is that you could run a lot of different
+> protected mode operating systems if you had a suitable supervisor program
+> to manage segment swapping - I'd hate to wait for a 4Gb swap! - and memory
+> fragmentation and compaction would be a pain!
+
+I think you'd have to re-write the VM handler code in the unix kernel
+pretty extensively to do this; all of the REAL operating systems :-)
+running in such a system are going to want control of the Global
+Descriptor Table, and I think the GDT would differ greatly from system
+to system.  The 386 allows you multiple virtual 8086s, but not multiple
+virtual 386s.
+
+	Wes Peters

I'm not really sure about this, but didn't Jolitz et al. describe something
like this for their BSD/386 port? They have mentioned the possiblity of some
kind of "supervisor kernel" above the real unix, handling interrupts, traps,
exceptions etc. out of regular internal unix kernel context.
This would force the kernel to handle itself as some kind of [system] process
and surely increase the number of context switches some orders of magnitude.
Does anybody know whether they finally realised something in this direction?

-- 
------------------------------------------------------------------------
L. Hirschbiegel, AEG - A84, Frankfurt (Germany) / email: unido!aega84!lh