Re: Wine, win4lin, vmware, bochs, plex86 can we build an alternative Windows yet ?
Check out our work on ReactOS > > My question to the Wine comminuty is this ? Whithout stopping the > current development would it be possible to build a striped down wine > version that can run most Windows apps if you have windows available and > are willing to install it in our Wine Virtual Environment. > \ __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com
Re: Wine, win4lin, vmware, bochs, plex86 can we build analternative Windows yet ?
I think setting DefaultLoadOrder to native, then pointing wine at your windows installation would achieve the effect you wanted. On the other hand, that doesn't always work - MS DLLs often make undocumented calls between each other. Also of course, the aim is to replace Windows, not just provide a convenient shortcut, if in 2020 we all use Linux but still have a Windows license lying around to run the occasional app, arguably we wouldn't have got anywhere at all. thanks -mike On Thu, 2003-03-27 at 07:34, Jacobus Erasmus wrote: > Hi, I've been following the Wine development for years now. > > I was surprized when I learned of vmware and win4lin being able to run > Windows. After some investigation it seems that they have consentrated > on a simpler task that of building a virtual machine that can run > Windows on top of linux. > > Wine on the other hand is concentrating on replacing Windows a much > harder task. > > My question to the Wine comminuty is this ? Whithout stopping the > current development would it be possible to build a striped down wine > version that can run most Windows apps if you have windows available and > are willing to install it in our Wine Virtual Environment. > > Given that Wine already contains most of the code to read and use DLL's. > Most of the drivers is already available what would it take to setup > such a wine version. (Interim solution ) -- Mike Hearn <[EMAIL PROTECTED]> QinetiQ - Malvern Technology Center
Re: wine & win4lin
robert w hall <[EMAIL PROTECTED]> writes: > well the mods are in include/asm/segment.h I think > > and the double whammy is that people loading stock win4lin kernels DON'T > get that updated . So even if they build WINE from source (but not their > kernel) they're scuppered. No, Wine gets the value directly from the %cs register at compile-time, so kernel headers don't matter, what is important is the kernel you are running on when you compile. Anyway it's not really hard to fix Wine to avoid this, I'm working on it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine & win4lin
In message <[EMAIL PROTECTED]>, David Elliott <[EMAIL PROTECTED]> writes >Jeremy White wrote: >Ah, so that explains why I haven't seen this problem then, because I always >build from source. likewise > Hmm, come to think of it, that'd make it kind of hard >for me to make a wine package usable by anyone else. > >Do you happen to know WHY this problem shows up??? see AJ's post >I don't believe it has >anything to do with kernel headers, since I am using kernel headers from >2.4.0testXX (ala RedHat 7.0) even though I am running a customized version >of 2.2.18pre17 (http://www.thecomputerbuilder.com/~dfe/linux/kernel_RPM/). >So theoretically I should be hit really hard by the problem if it was the >headers. > well the mods are in include/asm/segment.h I think and the double whammy is that people loading stock win4lin kernels DON'T get that updated . So even if they build WINE from source (but not their kernel) they're scuppered. Bob In another context though, it may explain the loadlin/win4lin problem (since that uses KERNEL_CS, KERNEL_DS which are also mod'd I think?) >-Dave > >P.S. cced this back to the win4lin-beta list as this could be informative >for people on that list. > Thanks - I posted independently to both lists initially -- robert w hall
Re: wine & win4lin
Jeremy White wrote: > Actually, it's a fascinating problem - I've been bit by it, badly. > > Wine works fine with a Win4lin kernel, so long as you build > it from source. If you try to take a binary built on a non > Win4lin kernel, you get an unhandled exception when your > app starts to run, with a problem in the ThunkConnect32 area. > > Similarly, if you take a binary that you built on your Win4lin > kernel, and give that binary to someone on a non Win4lin kernel, > they see the exact same problem. > > So, it works with Win4lin, sorta. > > Jer > Ah, so that explains why I haven't seen this problem then, because I always build from source. Hmm, come to think of it, that'd make it kind of hard for me to make a wine package usable by anyone else. Do you happen to know WHY this problem shows up??? I don't believe it has anything to do with kernel headers, since I am using kernel headers from 2.4.0testXX (ala RedHat 7.0) even though I am running a customized version of 2.2.18pre17 (http://www.thecomputerbuilder.com/~dfe/linux/kernel_RPM/). So theoretically I should be hit really hard by the problem if it was the headers. In any case, a message by Richard Bass ([EMAIL PROTECTED]) says that they are fixing the problem. I just wish they'd go ahead and release a fixed kernel patch right now rather than wait for all the different kernels to build. I could have it in my kernel RPM in about 5 minutes then go worrk on Wine while I'm waiting for it to build. ;-) -Dave P.S. cced this back to the win4lin-beta list as this could be informative for people on that list.
Re: wine & win4lin
Actually, it's a fascinating problem - I've been bit by it, badly. Wine works fine with a Win4lin kernel, so long as you build it from source. If you try to take a binary built on a non Win4lin kernel, you get an unhandled exception when your app starts to run, with a problem in the ThunkConnect32 area. Similarly, if you take a binary that you built on your Win4lin kernel, and give that binary to someone on a non Win4lin kernel, they see the exact same problem. So, it works with Win4lin, sorta. Jer robert w hall wrote: > I keep seeing occasional reports that 'wine does not run... on a > win4lin-enabled kernel'. Though this is contrary to my experience and > sounds like finger-trouble, I wonder if anyone has any better/hard > info?. > > The one possibility for serious interaction would appear to be the > dosmod/vm86 area? (which I don't personally use... sorry Ove! :-)) > > -- > robert w hall
Re: wine & win4lin
robert w hall <[EMAIL PROTECTED]> writes: > I keep seeing occasional reports that 'wine does not run... on a > win4lin-enabled kernel'. Though this is contrary to my experience and > sounds like finger-trouble, I wonder if anyone has any better/hard > info?. I think the problem is that they changed the value of USER_CS and USER_DS (the selectors used when running in 32-bit mode). We use these to switch from 16 to 32-bit code, and their value is hardcoded in the relay code at compile-time. So it will work as long as you also compile on a win4lin-patched kernel. But if you compile when running a normal kernel and run on the patched one, or the other way around, it will break. -- Alexandre Julliard [EMAIL PROTECTED]
