Mike McCormack wrote:
Hi All,
I'd like to compile a list of all applications that don't work correctly without native ole32 (aka dcom95), then go through and try fix them.
I think bugzilla is probably the right place to save the list, and that alot of the information we're looking for is already in the appdb.
How can we extract if easily? Maybe the appdb guys can provide a check box that app maintainers can click on to indicate that builtin ole32 works fine?
Well If I can get around to submitting my "new bugzilla integration" patch this could work right. The idea is to be able to attach multiple apps (versions) to the same bug. Right now we use "url" in Bugzilla to attach a bug to an app and that limits us to on app per bug.
The feature you want is to be able to click on a link in a bug and see all the applications that that bug affects.
I know exactly what I want it to do. I even have a bit rotted (almost) working version on my old machine. The problem I currently have is trying to keep up with the changes that Jon has been doing ( I don't work nearly as fast as him) so I have been waiting for the database to stablize a bit ...
--
Tony Lambregts
Tony Lambregts wrote:
Well If I can get around to submitting my "new bugzilla integration" patch this could work right. The idea is to be able to attach multiple apps (versions) to the same bug. Right now we use "url" in Bugzilla to attach a bug to an app and that limits us to on app per bug.
Yeah, that would be neat. I'd like to have a meta bug, say "Make OLE work", and then add all the applications that don't work as bugs under that meta bug.
I thought a checkbox might work too... a single click that somebody can set to show that the app works with builtin OLE or not. Maybe that could add the app to the metabug somehow?
The feature you want is to be able to click on a link in a bug and see all the applications that that bug affects.
Well, kind of. I want the app db to tell me all stuff that's not working with builtin ole32. (later possibly other dlls).
I know exactly what I want it to do. I even have a bit rotted (almost) working version on my old machine. The problem I currently have is trying to keep up with the changes that Jon has been doing ( I don't work nearly as fast as him) so I have been waiting for the database to stablize a bit ...
OK. I'm sure that Jon would help you out. This change would help to leverage the appdb for developers, not just for users.
I'm a bit worried that our users are content to use native Windows dlls, which doesn't help achieve Wine's goals.
Mike
Mike McCormack wrote:
I'm a bit worried that our users are content to use native Windows dlls, which doesn't help achieve Wine's goals.
Well, for what it's worth, I certainly am not (content to use native Windows dlls).
Today I just tested an app (see "Pretty Good Solitaire shootout" thread), and the reason why it worked on CX and not Wine was DCOM.
So I had to haul butt over to the MS site and get that (I probably have it backed up somewhere, but didn't feel like digging through CDs).
Now, from what I hear, it's going to become much more difficult for me to do even that in the near future, which stinks, as it was already a PITA. Besides which, the documentation on using native dlls is not so fabulously detailed and complete that even a user who had said dlls readily available (because they dual-boot, for example), is going to have a magic carpet ride trying to use them-- they have the dlls for a specific version of Windows, which may or may not conform to the dlls the program in question actually needs (you have XP dlls, but the program wants Win98); with the config file going the way of the dodo, there's not such an easy way to change things like winver temporarily, and even attempting to consider but a small subset of the possible trouble/inconveniences/conflicts that one might encounter brings visions of "way too much rtfm/command-line/general geekiness for the 'average' user".
If there was a simple, foolproof, well-documented and easily-understood method to effectively implement native Windows dlls (or if such dlls were implemented invisibly), I might agree with you, because ultimately I don't care one way or the other as long as my app works. After all, I'm just a user; it's not my job to care about what dlls are being used by the backend. So as far as that goes, you're right. I am "content" to use native Windows dlls if I can install and utilize them easily to get my app working.
But this is not really the case, so if the whole affair of getting my app working is going to be a PITA any way you slice it, I'd just as soon have it be a Linux-only PITA than a PITA with Microsoft secret sauce.
:-)
Holly
Holly Bostick wrote:
Now, from what I hear, it's going to become much more difficult for me to do even that in the near future, which stinks, as it was already a PITA.
Right. Microsoft will help Wine by making it harder to download parts of Windows, and better to use Wine code. We need to make it easier for people to let us know what's not working in Wine.
But this is not really the case, so if the whole affair of getting my app working is going to be a PITA any way you slice it, I'd just as soon have it be a Linux-only PITA than a PITA with Microsoft secret sauce.
If Wine just works, there's no PITA at all. We need to fix dlls to get rid of the need to download any "secret sauce". Ideally, fix from the bottom up, encourage people to say "hey! This behaves differently to the native dll", and be suprised about it... and note that somewhere.
The application database is a per application thing. What I want is a list of bugs per dll, not per application.
Mike
-
Holly Bostick -
Mike McCormack -
Tony Lambregts