I was wondering, since I have been away for so long, are we still implementing functionality for 16-bit programs? The reason I ask is because the freecell and solitaire from Win98/ME will not load in wine, while the ones from 2k/XP will. This is obviously due to the fact that our cards.dll is 32-bit only, whereas the cards.dll in Win98/ME is 16-bit.
Of course, the Win98/ME versions of the games wont start on WinXP either for the same reason.
Basically, I just need to know for the purposes of resolving this bug, should I leave it open and confirmed so that someone knows to implement the 16-bit functions (32 <-> 16 bit conversions?), or should I just go ahead and close it as WONTFIX?
Dustin
On 05/08/2005 03:09:39 AM, Dustin Navea wrote:
Basically, I just need to know for the purposes of resolving this bug, should I leave it open and confirmed so that someone knows to implement the 16-bit functions (32 <-> 16 bit conversions?), or should I just go ahead and close it as WONTFIX?
You got me wrong, I didn't mean WONTFIX because it's 16 bit code but because both the 32 bit and the 16 bit DLLs share the same name. (and so do the APIs)
Fixing this would require hacking the NE loader, winemaker and probably some more code. (and I stopped there since it didn't seem to be worth the effort)
Implementing the 16 bit routines by wrapping them around the 32 bit ones would be easy otherwise.
-flx
Hi,
On Sat, May 07, 2005 at 08:09:39PM -0500, Dustin Navea wrote:
I was wondering, since I have been away for so long, are we still implementing functionality for 16-bit programs? The reason I ask is because the freecell and solitaire from Win98/ME will not load in wine, while the ones from 2k/XP will. This is obviously due to the fact that our cards.dll is 32-bit only, whereas the cards.dll in Win98/ME is 16-bit.
Of course, the Win98/ME versions of the games wont start on WinXP either for the same reason.
As has been mentioned before on WD, cards.dll is a very obvious Microsoft screwup, since both 16bit and 32bit DLL carry the same name, which is a big no-no. I really don't think we want to patch our loader like mad to accomodate for such a stupid mistake. Instead, maybe we should implement cards16.dll and cards.dll. Then maybe there would be the possibility to programmatically advise the user to move the cards16.dll .so to the cards.dll .so in case he requires the 16bit version?
OTOH, is cards.dll being used by any program other than Microsoft's Solitaire? If it isn't, then it's rather useless to care about the 16/32bit distinction anyway.
Basically, I just need to know for the purposes of resolving this bug, should I leave it open and confirmed so that someone knows to implement the 16-bit functions (32 <-> 16 bit conversions?), or should I just go ahead and close it as WONTFIX?
I think I wouldn't feel too uncomfortable with providing the 32bit cards.dll only, even though this is a less preferrable situation.
Andreas
Andreas Mohr wrote:
Hi,
On Sat, May 07, 2005 at 08:09:39PM -0500, Dustin Navea wrote:
I was wondering, since I have been away for so long, are we still implementing functionality for 16-bit programs? The reason I ask is because the freecell and solitaire from Win98/ME will not load in wine, while the ones from 2k/XP will. This is obviously due to the fact that our cards.dll is 32-bit only, whereas the cards.dll in Win98/ME is 16-bit.
Of course, the Win98/ME versions of the games wont start on WinXP either for the same reason.
As has been mentioned before on WD, cards.dll is a very obvious Microsoft screwup, since both 16bit and 32bit DLL carry the same name, which is a big no-no. I really don't think we want to patch our loader like mad to accomodate for such a stupid mistake.
And I, personally, will not see the lose of the 16 bit version as too much of a problem. However:
Instead, maybe we should implement cards16.dll and cards.dll. Then maybe there would be the possibility to programmatically advise the user to move the cards16.dll .so to the cards.dll .so in case he requires the 16bit version?
A real PE file has an NE header, which has a MZ header. Usually, these headers just tell whoever is trying to run the application that this is a 32 bit application. One can, however, generate a DLL which is both a 32 and a 16 bit DLL.
Does our loader support such a format? If we call LoadLibrary16 on a DLL that has both PE and NE, will it use the NE? If so, we can create both DLLs inside the same file, and problem solved.
OTOH, is cards.dll being used by any program other than Microsoft's Solitaire? If it isn't, then it's rather useless to care about the 16/32bit distinction anyway.
I'm with you on this one, but if the Windows loader can do the 16/32 separation and we can't we may need to fix that.
I think I wouldn't feel too uncomfortable with providing the 32bit cards.dll only, even though this is a less preferrable situation.
I'm with you.
Andreas
Shachar
Shachar Shemesh wine-devel@shemesh.biz writes:
A real PE file has an NE header, which has a MZ header. Usually, these headers just tell whoever is trying to run the application that this is a 32 bit application. One can, however, generate a DLL which is both a 32 and a 16 bit DLL.
No, there's no way to do that, PE and NE are mutually exclusive. You could generate a DLL that is also a DOS binary but that's not very useful...
I'm with you on this one, but if the Windows loader can do the 16/32 separation and we can't we may need to fix that.
The Windows loader can't do it either.
Andreas Mohr wrote:
Hi,
As has been mentioned before on WD, cards.dll is a very obvious Microsoft screwup, since both 16bit and 32bit DLL carry the same name, which is a big no-no. I really don't think we want to patch our loader like mad to accomodate for such a stupid mistake.
Figures.. they are always FUBAR'ing things lol..
Instead, maybe we should implement cards16.dll and cards.dll. Then maybe there would be the possibility to programmatically advise the user to move the cards16.dll .so to the cards.dll .so in case he requires the 16bit version?
Nah, its not worth the trouble to most users. They just expect it to work.
OTOH, is cards.dll being used by any program other than Microsoft's Solitaire? If it isn't, then it's rather useless to care about the 16/32bit distinction anyway.
Doubtful, and I agree.
I think I wouldn't feel too uncomfortable with providing the 32bit cards.dll only, even though this is a less preferrable situation.
I agree here too, as 16-bit support is being phased out (Longhorn wont run any 16-bit apps), so theres no need for us to keep supporting it. If someone wants to play with a 16-bit program, they can make a 200mb DOS/Win3.11 Partition lol...
Dustin
Hi,
On Sun, May 08, 2005 at 03:47:52PM -0500, Dustin Navea wrote:
Figures.. they are always FUBAR'ing things lol..
That's just normal in software development. But MS does seem to have some special skills there ;)
Instead, maybe we should implement cards16.dll and cards.dll. Then maybe there would be the possibility to programmatically advise the user to move the cards16.dll .so to the cards.dll .so in case he requires the 16bit version?
Nah, its not worth the trouble to most users. They just expect it to work.
True. And since NT-based systems most likely only supply the 32bit version, this is what we should do as well.
I think I wouldn't feel too uncomfortable with providing the 32bit cards.dll only, even though this is a less preferrable situation.
I agree here too, as 16-bit support is being phased out (Longhorn wont run any 16-bit apps), so theres no need for us to keep supporting it. If someone wants to play with a 16-bit program, they can make a 200mb DOS/Win3.11 Partition lol...
Do we want to throw out the baby with the bath water? In this case it's an obvious conflict between 16bit and 32bit, and note that it's even with a very rarely used DLL, thus it's easy to give up on it.
In all other cases in which 16bit and 32bit can happily co-exist I don't see much reason why we should discard 16bit support.
Andreas
Andreas Mohr wrote:
Do we want to throw out the baby with the bath water? In this case it's an obvious conflict between 16bit and 32bit, and note that it's even with a very rarely used DLL, thus it's easy to give up on it.
In all other cases in which 16bit and 32bit can happily co-exist I don't see much reason why we should discard 16bit support.
hmm. I see your point, but at the same time, if we are trying to mimic windows, while still keeping the 16-bit code in there, shouldnt we just not work on it as much (like we are doing currently)?
Basically, the way I see it, vendors are stressing themselves with making 64-bit versions of their programs, as well as keeping their 32-bit versions going, so they are probably going to scrap 16-bit support in the near future, if they haven't already. Why should we continue developing something that is being phased out by the guys that create the need for this project in the first place?
Dustin
Dustin Navea wrote:
Andreas Mohr wrote:
Do we want to throw out the baby with the bath water? In this case it's an obvious conflict between 16bit and 32bit, and note that it's even with a very rarely used DLL, thus it's easy to give up on it.
In all other cases in which 16bit and 32bit can happily co-exist I don't see much reason why we should discard 16bit support.
hmm. I see your point, but at the same time, if we are trying to mimic windows, while still keeping the 16-bit code in there, shouldnt we just not work on it as much (like we are doing currently)?
Basically, the way I see it, vendors are stressing themselves with making 64-bit versions of their programs, as well as keeping their 32-bit versions going, so they are probably going to scrap 16-bit support in the near future, if they haven't already. Why should we continue developing something that is being phased out by the guys that create the need for this project in the first place?
Because there are still a lot of Win16 out there that continue to just do their job. Vendors are trying to convince you that you need the latest wizbang because they need to sell. But that's not necessary in the best interest of the customer. With Wine you can still use the old software on modern computer hardware in case your old one dies.
bye michael
Hi,
On Sun, May 08, 2005 at 04:11:56PM -0500, Dustin Navea wrote:
Andreas Mohr wrote:
Do we want to throw out the baby with the bath water? In this case it's an obvious conflict between 16bit and 32bit, and note that it's even with a very rarely used DLL, thus it's easy to give up on it.
In all other cases in which 16bit and 32bit can happily co-exist I don't see much reason why we should discard 16bit support.
hmm. I see your point, but at the same time, if we are trying to mimic windows, while still keeping the 16-bit code in there, shouldnt we just not work on it as much (like we are doing currently)?
Sure, but that's a moot point, since everybody will work as much on stuff as he wants to see it progress, and that won't be too much in the Win16 case since it's of not too much interest as compared to Win32 (or probably even Win64 relatively soon).
Basically, the way I see it, vendors are stressing themselves with making 64-bit versions of their programs, as well as keeping their 32-bit versions going, so they are probably going to scrap 16-bit support in the near future, if they haven't already. Why should we continue developing something that is being phased out by the guys that create the need for this project in the first place?
You're already sounding like the new marketing director of some random major software company... "we need FEATURES, FEATURES! Who cares about all that old crap..."
I don't really need to tell you that this attitude is rather wrong in the Wine case, do I?
Hmm, well, let me do it anyway :-) People are often migrating to Linux PRECISELY BECAUSE newer Windows versions are no alternative to them any more (old machines with insufficient performance/compatibility with newer Windows versions). And we better make sure we support their *older* Windows applications to some extent in that case.
Andreas
On Mon, May 09, 2005 at 05:06:31PM +0200, Andreas Mohr wrote:
People are often migrating to Linux PRECISELY BECAUSE newer Windows versions are no alternative to them any more (old machines with insufficient performance/compatibility with newer Windows versions). And we better make sure we support their *older* Windows applications to some extent in that case.
Oh well, last time I wanted to get a patch by Alexandre saying 'that works perfectly fine in Win98' he answered me 'but it's wrong in Win2K' and did not commit it :-)
So basically, correctness comes before the need to support old applications (and I know of at least 3 or 4 game demos which do not work on Win2K / WinXP anymore - of these only one actually still work in Wine).
Lionel
Andreas Mohr wrote:
Sure, but that's a moot point, since everybody will work as much on stuff as he wants to see it progress, and that won't be too much in the Win16 case since it's of not too much interest as compared to Win32 (or probably even Win64 relatively soon).
So, if john wants to play doom or duke, he either should know how to develop and contribute the code to get it working in wine, or have a friend that could do it for him? I ask because if everyone is trying to get their own stuff working (and in the process fixing other stuff that comes up along the way) who will have time to help the minority of people that want to play a classic game like duke or doom?
You're already sounding like the new marketing director of some random major software company... "we need FEATURES, FEATURES! Who cares about all that old crap..."
OOPS, didnt mean to come across that way. I was basically saying that it seems that way, as more people migrate to 64 (and away from 32), we need ot keep up with the times, and from a maintenance standpoint i think it would be much easier to maintain 1 set of code as opposed to 3. Which this has given me an idea that I will break down in the next email I send.
I don't really need to tell you that this attitude is rather wrong in the Wine case, do I?
No, of course not! But I see that you already have lol.
Hmm, well, let me do it anyway :-) People are often migrating to Linux PRECISELY BECAUSE newer Windows versions are no alternative to them any more (old machines with insufficient performance/compatibility with newer Windows versions). And we better make sure we support their *older* Windows applications to some extent in that case.
See next email
Dustin
-
Alexandre Julliard -
Andreas Mohr -
Dustin Navea -
Felix Nawothnig -
Lionel Ulmer -
Michael Stefaniuc -
Shachar Shemesh