Dear wine developers,
I have one question on the development of wine. Long(one or two years) ago I've heard that Microsoft got some hidden APIs in their products of various windows, and they use these APIs in their own applications. I wonder if this is still a problem on their recent product like windows XP. If it is, I guess wine will not be able to run such MS applications which uses hidden APIs. Is this right?
And, is wine designed(or its goal is) to run all applications(including MS product and non-MS product) that runs on windows?
Please forgive me if this problem has appeared in the past. I just joined this list a couple of days ago.
Thank you.
Regards,
-- Zhang Shu
On 2002.01.28 00:44 Zhang Shu wrote:
Dear wine developers,
I have one question on the development of wine. Long(one or two years) ago I've heard that Microsoft got some hidden APIs in their products of various windows, and they use these APIs in their own applications. I wonder if this is still a problem on their recent product like windows XP. If it is, I guess wine will not be able to run such MS applications which uses hidden APIs. Is this right?
And, is wine designed(or its goal is) to run all applications(including MS product and non-MS product) that runs on windows?
Please forgive me if this problem has appeared in the past. I just joined this list a couple of days ago.
Use the source, Luke!
Seriously.. a very quick perusal of the Wine sourcetree will show you quite a few undocumented functions that are already well-implemented. It will also show you quite a few that are spec-file stubs (i.e. no-one even knows what parameters the function takes, just that it is there). And you'll also see quite a few that are implemented as stubs (i.e. they receive the correct number and type of paramters and print out a fixme with that information). You also I am sure (with more looking) could find an undoc function that has the parameters wrong. Although most of the time this is not the case since if the incorrect number of bytes are popped off the stack then the program will surely crash.
-Dave
Dear wine developers,
I have one question on the development of wine. Long(one or two years) ago I've heard that Microsoft got some hidden APIs in their products of various windows, and they use these APIs in their own applications. I wonder if this is still a problem on their recent product like windows XP. If it is, I guess wine will not be able to run such MS applications which uses hidden APIs. Is this right?
Yes, there are still several undocumented functions that prevent certain applications from working under wine. Specifically, many XP applications don't work because they use the undocumented function RtlGetNtVersionNumbers.
And, is wine designed(or its goal is) to run all applications(including MS product and non-MS product) that runs on windows?
Yes, the goal of wine is to eventually run all windows applications (except for device drivers). However, for Wine 1.0, the focus will be on running a set of widely used applications, such as Microsoft Office, Lotus Notes, etc. Currently, many applications will work with a little tweaking. If you are using wine with Windows XP, you will have more success if you run wine with the command-line option, '-dll builtin ntdll,msvcrt'
Example: wine -dll ntdll,msvcrt=builtin yourapplication.exe
This will cause wine to use it's own ntdll instead of the one that comes with XP.
I hope this helps,
Josh
I am so sorry! Please ignore my previous reply. I must have accidentally sorted my email by sender instead of date. I noticed (after I hit send, of course) that your original message was posted in January. I must be staying up too late. Where is the undo button?
Josh Thielen
Yes, the goal of wine is to eventually run all windows applications (except for device drivers). However, for Wine 1.0, the focus will be on running a set of widely used applications, such as Microsoft Office, Lotus Notes, etc. Currently, many applications will work with a little tweaking.
I do have an objection to that. Linux has many native applications, including an office suite, a mailer, a perfect browser etc. Perhaps wine-developers should not focus on porting such apps from the other system. I 've even heard that we should even drop any support to the win apps, in a try to make them obsolete. My view is that we should focus on professional apps, such as CAD, some multimedia etc. There is professionals that won't switch to Linux until some unique apps they use can run under Linux. Games are an issue, too.
However, we couldn't make the rare apps run, until the API is mature, such that the most common ones will run, too. So, don't worry if Outlook or Money doesn't run, worry about Matlab (say..).
On Wed, 3 Jul 2002, P. Christeas wrote:
Yes, the goal of wine is to eventually run all windows applications (except for device drivers). However, for Wine 1.0, the focus will be on running a set of widely used applications, such as Microsoft Office, Lotus Notes, etc. Currently, many applications will work with a little tweaking.
I do have an objection to that. Linux has many native applications, including an office suite, a mailer, a perfect browser etc.
Ahem, I would disagree with the perfect browser part<g>. But that's besides the point.
Apparently, what you want is to see Linux succeed on the desktop. Then Office, Outlook, Money & co are a requirement. The issue is not whether they have perfectly good Linux replacements, but whether people are going to switch if that means giving up the applications they use now.
Some people have good reasons not to switch to the Linux apps: for instance some user use Word add-ons for reference management, bibliographies, etc. Until similar specialized add-ons (this specific one or others) are available these people just won't switch. Other people have not so good reasons (that's not what I use), but that's irrelevant. It means they won't switch to Linux just the same (or obstruct any switch in they company).
And until people switch to Linux these specialized add-ons, and the tens of thousands of specialty/professional applications you mentioned will not be ported to Linux, thus preventing large numbers of people from switching too.
So the best strategy is to add support for the applications that will allow the greater number of people to switch to Linux. And it turns out that if you order applications on this criteria, they will turn out to be pretty much in the order of their popularity in the Windows world.
But all the above is irrelevant since the premise "for Wine 1.0, the focus will be on running a set of widely used applications" is incorrect. This is not the focus of the 1.0 release. The focus of the 1.0 release (as far as the Wine project is concerned) is to get Wine to a stable state where we can go a fix bugs without having to reorganize three quarters of the code and to break half the applications and existing Wine/Winelib applications out there.
This is why dll separation, window management and stabilization of the server protocol is on the 0.9 list.
http://bugs.winehq.com/showdependencytree.cgi?id=35
We will have reached 0.9 when the the above tasks are completed. Then during the 0.9.0 to 1.0 period we will work out any left-over issue in the above items and gradually freeze the code for a 1.0 release. After that we should be able to improve Wine without breaking compatibility so much, and without having too much regression. But there is not official list of applications that 'must work in 1.0'.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service
Francois Gouget schrieb:
Apparently, what you want is to see Linux succeed on the desktop. Then Office, Outlook, Money & co are a requirement. The issue is not whether
Nonsense. At all, those Outsuck and blind-explorer files are not even a requirement on Windoze!
The rest of what you wrote deserves an almost full ACK! But no need to quote it.
Best regards!!
On Wed, Jul 03, 2002 at 01:33:46AM +0300, P. Christeas wrote:
My view is that we should focus on professional apps, such as CAD, some multimedia etc. There is professionals that won't switch to Linux until some unique apps they use can run under Linux. Games are an issue, too.
Very true. IMHO AutoCAD is *very* important, as it's considered to be a leading CAD package, with no UNIX version, ever.
However, we couldn't make the rare apps run, until the API is mature, such that the most common ones will run, too. So, don't worry if Outlook or Money doesn't run, worry about Matlab (say..).
Matlab is the worst example that you could possibly have chosen. You are aware of the fact that there is a Linux version ?
Le mer 03/07/2002 à 11:39, Andreas Mohr a écrit :
On Wed, Jul 03, 2002 at 01:33:46AM +0300, P. Christeas wrote:
My view is that we should focus on professional apps, such as CAD, some multimedia etc. There is professionals that won't switch to Linux until some unique apps they use can run under Linux. Games are an issue, too.
Very true. IMHO AutoCAD is *very* important, as it's considered to be a leading CAD package, with no UNIX version, ever.
Was a leading CAD package. It's still vastly used, but (in my experience) mostly to get access to old drawings. Newer stuff gets designed on SolidWorks, ProE, Catia, Mechanical Desktop and a couple others which do real 3D.
However, we couldn't make the rare apps run, until the API is mature, such that the most common ones will run, too. So, don't worry if Outlook or Money doesn't run, worry about Matlab (say..).
Matlab is the worst example that you could possibly have chosen. You are aware of the fact that there is a Linux version ?
Right. But are all toolboxes ported? The symbolic toolbox uses a Maple lib (not only m-files), and I'm not sure if it's been ported.
Vincent
Vincent Béron wrote:
Le mer 03/07/2002 à 11:39, Andreas Mohr a écrit :
On Wed, Jul 03, 2002 at 01:33:46AM +0300, P. Christeas wrote:
My view is that we should focus on professional apps, such as CAD, some multimedia etc. There is professionals that won't switch to Linux until some unique apps they use can run under Linux. Games are an issue, too.
Very true. IMHO AutoCAD is *very* important, as it's considered to be a leading CAD package, with no UNIX version, ever.
Was a leading CAD package. It's still vastly used, but (in my experience) mostly to get access to old drawings. Newer stuff gets designed on SolidWorks, ProE, Catia, Mechanical Desktop and a couple others which do real 3D.
Just barely on topic, hope people don't mind...
So, any hints on which would be a good one to get? I am planning to buy a mechanical CAD package, and would then attempt to fix any bugs to get it running under wine. I have managed to do fairly well getting my Xilinx FPGA software working (though getting the patches committed has been a little harder), so I figure I would try a CAD package, too.
My needs are pretty simple, so I don't really want the high dollar stuff, perhaps under $1K (the further under the better ;)? I would be doing things like mechanical drawings for machining front panels and brackets for electronic equipment (which I have done in Autocad in the past).
On 2002-07-03 10:59 Duane Clark wrote:
Vincent Béron wrote:
Le mer 03/07/2002 à 11:39, Andreas Mohr a écrit :
On Wed, Jul 03, 2002 at 01:33:46AM +0300, P. Christeas wrote:
My view is that we should focus on professional apps, such as CAD, some multimedia etc. There is professionals that won't switch to Linux until some unique apps they use can run under Linux. Games are an issue, too.
Very true. IMHO AutoCAD is *very* important, as it's considered to be a leading CAD package, with no UNIX version, ever.
Was a leading CAD package. It's still vastly used, but (in my experience) mostly to get access to old drawings. Newer stuff gets designed on SolidWorks, ProE, Catia, Mechanical Desktop and a couple others which do real 3D.
Just barely on topic, hope people don't mind...
So, any hints on which would be a good one to get? I am planning to buy a mechanical CAD package, and would then attempt to fix any bugs to get it running under wine. I have managed to do fairly well getting my Xilinx FPGA software working (though getting the patches committed has been a little harder), so I figure I would try a CAD package, too.
My needs are pretty simple, so I don't really want the high dollar stuff, perhaps under $1K (the further under the better ;)? I would be doing things like mechanical drawings for machining front panels and brackets for electronic equipment (which I have done in Autocad in the past).
Try QCad. At $0, it is hard to beat. http://www.qcad.org
-
Andreas Mohr -
David Elliott -
Duane Clark -
Francois Gouget -
Joshua Thielen -
Oliver Ob -
P. Christeas -
Tom Schutter -
Vincent Béron -
Zhang Shu