Andreas Mohr wrote:
On Tue, Nov 05, 2002 at 06:47:35PM +0200, Jukka Heinonen wrote:
After this patch winedos contains almost complete int31 emulation. What has not been moved to winedos is mostly functions that require either W32S_WINE2APP or W32S_APP2WINE. This makes me wonder whether Wine still needs to support WIN32S... Well, of course it does. Wine is supposed to run *all* reasonably new (i.e.: not "standard mode") Windows programs, and that does include Win32s IMHO.
Sure, I know that (I'm working on DPMI32 which isn't for standard mode Windows programs), I was probably being a bit unclear about what I was wondering about. It is quite difficult to find any information about Win32s nowadays and everything I have found was suggesting that Win32s was for running Win32 applications on Win16. Since Wine does run Win32 applications directly it just made me wonder whether Win32s support is something that was once needed when Wine only had Win16 support. But, since I know very little about Win32s, I can only wonder. It all depends on how Win32s applications differ from Win32 and Win16 applications. The existence of Win32s dlls seems to suggest that Win32s applications are not regular Win32 applications as well as the text in "msdos/vxd.c" which talks about some strange pointer mangling required with Win32s applications. This mangling is probably something that is only required if Wine supports official Win32s dlls. Which makes me wonder if Win32s dlls provided by Wine actually do work because they don't seem to do any pointer mangling. Well, it could be that Win32s applications do this pointer mangling internally. Anyway, I seem to have answered myself. If Wine is going to support Win32s applications using both builtin and official Win32s dlls, it needs pointer mangling. I just have to figure out how the required offset can be accessed from multiple dlls because I would really like to have all the interrupt handlers in one place. I still think that all the tricks required in order to support official Win32s dlls are quite ugly: all the routines that use linear addresses and are called directly by Win32s applications need to do pointer mangling and msdos/vxd.c actually modifies the official dlls in order to work around some problems. But since this most likely works already, I don't think I want to change anything. -- Jukka Heinonen <http://www.iki.fi/jhei/>
Hi All, I have been a silent observer on here for some time. (about 2 years or so). In the course of this time it has occurred to me that you are developing WINE with the aim of allowing all M$ platform programs to run on the _much_ more stable Linux platform. In light of some recent news here in Australia, (this link is to the article Alston opens agencies to linux ) I am proposing that wine take to two distinct streams: 1) Office Stream, which provides for the Office and business tool platform. 2) Games Stream, which offers the gaming community the place to play their games. The purpose of this proposal is to bring some ease in your developments and provide the right platform for the end user. Since Linux so easily boots alternative kernels, this would mean that the machines could be business and games, just not at the same time. Why? MS developed NT for business use and 95/98 for games. Even they couldn't make one platform for all and still can't. That's my 2c (as the saying goes). I will leave this to the people better qualified and experience than myself to decide if this has any merit. -- cheers Gregory Hicks Adelaide Australia
Sorry, URL slipped out of the link :( http://australianit.news.com.au/articles/0,7204,5421656%5e16123%5e%5enbv%5e,... -- cheers Gregory Hicks Q48036388 3rd Year CQU BIT "I took a bigger challenge - study externally and long distance"
--- Gregory Hicks <ghicks(a)ihug.com.au> wrote:
Hi All,
I have been a silent observer on here for some time. (about 2 years or so).
In the course of this time it has occurred to me that you are developing WINE with the aim of allowing all M$ platform programs to run on the _much_ more stable Linux platform.
In light of some recent news here in Australia, (this link is to the article Alston opens agencies to linux )
I am proposing that wine take to two distinct streams: 1) Office Stream, which provides for the Office and business tool platform.
2) Games Stream, which offers the gaming community the place to play their games.
The purpose of this proposal is to bring some ease in your developments and provide the right platform for the end user. Since Linux so easily boots alternative kernels, this would mean that the machines could be business and games, just not at the same time.
Why? MS developed NT for business use and 95/98 for games. Even they couldn't make one platform for all and still can't.
Not to start a flame war, right? ;) Wasnt Win2k Pro designed for just that purpose, games _and_ business? And besides, the 2 streams already exist. http://www.codeweavers.com for Business and http://www.transgaming.com for Games http://www.winehq.com is the middle ground for everyone to work from and send back to so if you want 2 in 1 without having to have 2 separate copies of wine, then you can. -Dustin __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Sure, I know that (I'm working on DPMI32 which isn't for standard mode Windows programs), I was probably being a bit unclear about what I was wondering about. It is quite difficult to find any information about Win32s nowadays and everything I have found was suggesting that Win32s was for running Win32 applications on Win16. Since Wine does run Win32 applications directly it just made me wonder whether Win32s support is something that was once needed when Wine only had Win16 support.
Win32s was an add-on to Windows 3.1 to allow it to run 32-bit Windows apps before Win95 was available. The "s" in Win32s meant that it was a subset of Win32 because features like threading and others simply weren't available in Win32s. I always assumed that the binary interface was the same as the full Win32. The add-on DLLs that made up Win32s were supposed to translate the 32-bit calls into the equivalent 16-bit calls. However, knowing Microsoft, I could easily be wrong. I do still have old copies of MSDN and I believe that I probably still have an old enough compiler that would produce a Win32s program. All-in-all, I wouldn't spend much (if any) effort on Win32s because it was simply intended as a transitional system and didn't really get installed in all that many computers. Most 32-bit apps waited for the arrival of Win95 before they were released. ----- Bob Amstadt http://www.amstadt.com/~bob bob(a)amstadt.com
On Wed, Nov 06, 2002 at 08:37:26AM -0800, Robert Amstadt wrote:
Sure, I know that (I'm working on DPMI32 which isn't for standard mode Windows programs), I was probably being a bit unclear about what I was wondering about. It is quite difficult to find any information about Win32s nowadays and everything I have found was suggesting that Win32s was for running Win32 applications on Win16. Since Wine does run Win32 applications directly it just made me wonder whether Win32s support is something that was once needed when Wine only had Win16 support.
Win32s was an add-on to Windows 3.1 to allow it to run 32-bit Windows apps before Win95 was available. The "s" in Win32s meant that it was a subset of Win32 because features like threading and others simply weren't available in Win32s.
If anyone needs that, I guess I could easily dig up the mail from Ulrich Weigand that explained the miracles accomplished at that time in great detail. (it was not much more other than pure luck that we were able to do what we did with Win32s support) Andreas P.S.: Hello Bob: great to see you around again ! :) (and no, at *that* archaic time, *I* haven't been involved yet !)
On November 6, 2002 11:47 am, Andreas Mohr wrote:
If anyone needs that, I guess I could easily dig up the mail from Ulrich Weigand that explained the miracles accomplished at that time in great detail. (it was not much more other than pure luck that we were able to do what we did with Win32s support)
That'd be good. Is there _any_ reasonable reason for not dropping the silly Win32s altogether? -- Dimi.
On Wed, Nov 06, 2002 at 12:12:45PM -0500, Dimitrie O. Paun wrote:
On November 6, 2002 11:47 am, Andreas Mohr wrote:
If anyone needs that, I guess I could easily dig up the mail from Ulrich Weigand that explained the miracles accomplished at that time in great detail. (it was not much more other than pure luck that we were able to do what we did with Win32s support)
That'd be good. Is there _any_ reasonable reason for not dropping the silly Win32s altogether? Hmm, not sure.
Check out the comment /* * If this is the first time we are called for this process, * hack the memory image of WIN32S16 so that it doesn't try * to access the GDT directly ... in msdos/vxd.c. We needed to support loading of the whole Win32s subsystem, at that time at least. Ulrich Weigand did the 0x10000 offset shift because Win32s intended to create selectors with base addr 0xffff0000 (not possible on Linux !), so he needed to shift all W32S address calculations by 0x10000 to fight that problem. Anyway, that's probably irrelevant. What's relevant is whether we still need to be able to use a real Win32s subsystem or not (and whether it's even still possible !). Most likely we don't need it any more, since Win32s apps are *supposed* to work perfectly not only on Win3.1 + Win32s, but also on a real Win32 box (which doesn't have Win32s specific functions). And as Wine has pretty good Win32 support nowadays, it's probably not needed any more. The application that I had problems with at that time was a Win3.1 version of Mathcad, BTW (IIRC) (hmm, was it Mathcad 3.1 ??). And Ulrich had been some great help in making this stuff work ! I should probably try to run Mathcad 3.1 again and report any result. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt
On November 6, 2002 01:19 pm, Andreas Mohr wrote:
What's relevant is whether we still need to be able to use a real Win32s subsystem or not (and whether it's even still possible !).
This is a hacky subsystem, and the associated code is hard to understand, and maintain. I see no reason to support it, and only if it was just for the simplicity we gain by dropping it, we should do it. It makes msdos work more difficult, and that is a problem *now*. It is just an example how we waste developer cycles on irrelevant problems like this. This is why we should not try to keep every conceivable hack in the tree. Alexandre, will you accept a patch removing that stuff? -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
Alexandre, will you accept a patch removing that stuff?
Certainly. I don't mind keeping it around as long as it doesn't impact anything, but if it gets in the way let's just kill that stuff. -- Alexandre Julliard julliard(a)winehq.com
On Wed, Nov 06, 2002 at 01:32:07PM -0500, Dimitrie O. Paun wrote:
On November 6, 2002 01:19 pm, Andreas Mohr wrote:
What's relevant is whether we still need to be able to use a real Win32s subsystem or not (and whether it's even still possible !).
This is a hacky subsystem, and the associated code is hard to understand, and maintain. I see no reason to support it, and only if it was just for the simplicity we gain by dropping it, we should do it. It makes msdos work more difficult, and that is a problem *now*. It is just an example how we waste developer cycles on irrelevant problems like this. This is why we should not try to keep every conceivable hack in the tree. While I get your point, you seem to be very eager to put everything into the worst possible light. May I suggest you say it with a somewhat sweeter voice next time ? ;-) (you know how harsh and proficient I can be at flaming back, so better don't challenge me ;-)))
And yes, I certainly agree on removing it in case it is a problem (unless it's really needed to make some programs work, and even then it could be debated whether those programs that are broken enough to actually need an original Win32s subsystem are *really* worth supporting). -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
On November 6, 2002 02:24 pm, Andreas Mohr wrote:
(you know how harsh and proficient I can be at flaming back, so better don't challenge me ;-)))
So you're asserting your exclusive right to be harsh? :)
And yes, I certainly agree on removing it in case it is a problem (unless it's really needed to make some programs work, and even then it could be debated whether those programs that are broken enough to actually need an original Win32s subsystem are *really* worth supporting).
We agree then. Excellent. -- Dimi.
Dimitry Timoshkov wrote:
On November 6, 2002 11:47 am, Andreas Mohr wrote:
If anyone needs that, I guess I could easily dig up the mail from Ulrich Weigand that explained the miracles accomplished at that time in great detail. (it was not much more other than pure luck that we were able to do what we did with Win32s support)
That'd be good. Is there _any_ reasonable reason for not dropping the silly Win32s altogether?
Those hacks are needed only to support running the original win32s subsystem (i.e. the win32s.exe including its libraries) as 16-bit application under Wine. Win32s *applications* should run just fine as *32-bit* applications under the Win32 API provided by Wine today. At the time I've done those hacks (1998), the Win32 support wasn't quite as good as today, so this was one way to get 32-bit applications running ... Nowadays, I don't really see much reasons for keeping this. There is one potential reason: the Win32s libraries did export the one or other routine that is not part of the actual Win32 API, mostly having to do with support for 32<->16 bit thunking under Win32s. There might be some original Win32s-applications that use those APIs, which could conceivably fail under Wine's Win32 API. (We do implement some of these, like the UT thunk routines, but not all as far as I recall.) However, I don't have any actual example; and if those hacks prevent other development work, there's no sense in keeping them IMO. (In fact, I have no idea whether all this still works after all the reorganizations that have been going on in the mean time, like address space separation. Maybe this code is completely useless anyway ;-/) Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de
On November 6, 2002 04:58 pm, Ulrich Weigand wrote:
Dimitry Timoshkov wrote: ^^^^^^^^^^^^^^^^^ Where did you come up with this? I wrote it... :)
Argh. I should configure my mailer correctly so that I don't need to hand-edit this :-/ Sorry ... -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de
participants (8)
-
Alexandre Julliard -
Andreas Mohr -
Dimitrie O. Paun -
Dustin Navea -
Gregory Hicks -
Jukka Heinonen -
Robert Amstadt -
Ulrich Weigand