I don't know if this is the right place to suggest a feature, but would it be possible to integrate the app database into wine? What I mean is that when someone tries to install a program, wine would first check with the app database to see if there is an entry on it, and what its current ranking is for usability. Then it could possibly warn the user at maybe a self defined level (i.e. silver or lower, bronze or lower).
Does that seem plausible to anyone who knows more about the inner workings of wine? I am curious.
Wine Feature suggestion
How do you expect it to work?
Should Wine spy on the o/s you are using, the wine version and the software you are trying to install to connect to the wine database and get the answer what to expect?
I think one calls it call home from Windows and I am not sure you would like it as a systematical way.
I think every user is educated and can check for himself.
On the other side, I would be more than happy to send the results of the tests for a software directy to wine if this helps their testing but to write don'tt work, don't work, don't work, hey wait a little bit, light in the horizon, don't work, maybe, no chances of it, version after version in the database it pretty silly to me.
I will enter when it works past the last working stand or at least to it.
Should Wine spy on the o/s you are using, the wine version and the software you are trying to install to connect to the wine database and get the answer what to expect?
I think one calls it call home from Windows and I am not sure you would like it as a systematical way.
I think every user is educated and can check for himself.
On the other side, I would be more than happy to send the results of the tests for a software directy to wine if this helps their testing but to write don'tt work, don't work, don't work, hey wait a little bit, light in the horizon, don't work, maybe, no chances of it, version after version in the database it pretty silly to me.
I will enter when it works past the last working stand or at least to it.
Re: Wine Feature suggestion
the ratings on the AppDB are subjective and can vary wildly, an app might be garbage to one user due to bad video drivers or bad support for a certain soundcard but the same could be Platinum for another.dawinsor87 wrote:I don't know if this is the right place to suggest a feature, but would it be possible to integrate the app database into wine? What I mean is that when someone tries to install a program, wine would first check with the app database to see if there is an entry on it, and what its current ranking is for usability. Then it could possibly warn the user at maybe a self defined level (i.e. silver or lower, bronze or lower).
Does that seem plausible to anyone who knows more about the inner workings of wine? I am curious.
Wine Feature suggestion
On Fri, Aug 29, 2008 at 12:06 PM, jeffz <[email protected]> wrote:
specific app is being installed.
Also consider how exactly one would determine what app/version ofdawinsor87 wrote:the ratings on the AppDB are subjective and can vary wildly, an app might be garbage to one user due to bad video drivers or bad support for a certain soundcard but the same could be Platinum for another.I don't know if this is the right place to suggest a feature, but would it be possible to integrate the app database into wine? What I mean is that when someone tries to install a program, wine would first check with the app database to see if there is an entry on it, and what its current ranking is for usability. Then it could possibly warn the user at maybe a self defined level (i.e. silver or lower, bronze or lower).
Does that seem plausible to anyone who knows more about the inner workings of wine? I am curious.
specific app is being installed.
Re: Wine Feature suggestion
The executable checksum (md5 or so) could be used for that purpose.austin987 wrote:On Fri, Aug 29, 2008 at 12:06 PM, jeffz <[email protected]> wrote:Also consider how exactly one would determine what app/version ofdawinsor87 wrote:the ratings on the AppDB are subjective and can vary wildly, an app might be garbage to one user due to bad video drivers or bad support for a certain soundcard but the same could be Platinum for another.I don't know if this is the right place to suggest a feature, but would it be possible to integrate the app database into wine? What I mean is that when someone tries to install a program, wine would first check with the app database to see if there is an entry on it, and what its current ranking is for usability. Then it could possibly warn the user at maybe a self defined level (i.e. silver or lower, bronze or lower).
Does that seem plausible to anyone who knows more about the inner workings of wine? I am curious.
specific app is being installed.
A checksum would of course only be done in case of software install.
Re: Wine Feature suggestion
They can also vary according to the person's level of expertise, and whether or not any overrides were used. Newbies may get garbage results simply because they don't know what they're doing. Experienced users sometimes neglect to mention the overrides and/or tweaks they used to get an app to run. You really have to read all the reports for a particular app carefully to make a judgment, and software can't do that for you.jeffz wrote: the ratings on the AppDB are subjective and can vary wildly, an app might be garbage to one user due to bad video drivers or bad support for a certain soundcard but the same could be Platinum for another.
You are right about overrides and tweaks.
The same thing is that the experienced user that had been testing week after week knows about them and doesn't think a lot when installing.
In my case, Trados, sometimes a version did require a tweak, another another override (I did remember in 0.9.59 to be installing msxml 4 to avoid a crash on the .NET on this particular version where it was not needed before and afterwards).
Once I talked to my colleague because they were talking about a forum post I made one year ago about Trados and Wine (when I actually started to do it) and I answered you still have to get your hands pretty dirty but the best version was still 0.9.59 (actually between 0.9.56 and 59).
He just answered me that he admired for this but reminded me that before wanting be climbing the everest without oxygen, there was also the mt blanc if I were to give up - which he would understand).
If you see garbage and gold at the same time, it's very likely down to experience or tweaks. Starters will find anything that is not actually platium garbage at the first try.
The same thing is that the experienced user that had been testing week after week knows about them and doesn't think a lot when installing.
In my case, Trados, sometimes a version did require a tweak, another another override (I did remember in 0.9.59 to be installing msxml 4 to avoid a crash on the .NET on this particular version where it was not needed before and afterwards).
Once I talked to my colleague because they were talking about a forum post I made one year ago about Trados and Wine (when I actually started to do it) and I answered you still have to get your hands pretty dirty but the best version was still 0.9.59 (actually between 0.9.56 and 59).
He just answered me that he admired for this but reminded me that before wanting be climbing the everest without oxygen, there was also the mt blanc if I were to give up - which he would understand).
If you see garbage and gold at the same time, it's very likely down to experience or tweaks. Starters will find anything that is not actually platium garbage at the first try.
-
Dan Oetting
- Newbie
- Posts: 1
- Joined: Sat Aug 30, 2008 10:47 am
Instead of just providing a lookup in the apps database, it might be better to have a local database of the implementation level for each entry point in the implemented libraries. An application loader could then report if the application is expected to encounter problems and possibly what type of functions won't work based on what's missing in the implementations.
The next level would be a central database of the entry points required by each application. The data could be compiled from the loader, static analysis of the executable or by logging calls made by the running application. This database would tell developers what implementations or improvements would likely satisfy users the most and could tell users when developments may have improved the usability of applications they are waiting for.
The next level would be a central database of the entry points required by each application. The data could be compiled from the loader, static analysis of the executable or by logging calls made by the running application. This database would tell developers what implementations or improvements would likely satisfy users the most and could tell users when developments may have improved the usability of applications they are waiting for.
-
dawinsor87
- Level 1
- Posts: 7
- Joined: Mon Jul 07, 2008 7:37 am
There is still a part missing from wine. Windows Compatibility system. The shim's that automatically provide overrides for some applications.
For some applications getting that working will be required. Due to MS using shims to work out variations in the API.
Of course making lookup, status reporting and bug application for wine could make wine more userfriendly. This really cannot be automatic when wine runs because that would just generate too much server load and be breach of privacy. But a tool user can choose to run when they have trouble is fine.
Advantage with a program bug reporting tool it can be setup to check common causes of invalid bug reports like bad opengl. Even provide the data to pastebin for use with irc channel.
Advantage with status reporting program as noted in the appdb people forget to post there tweaks and give applications plat status when they have used tweaks.
There are lots of usability things that can be improved. Currently users have to run from command line to get wine debugging information. This is kinda hard on new users.
So idea itself is not without base. Way to do needs to be different.
For some applications getting that working will be required. Due to MS using shims to work out variations in the API.
Of course making lookup, status reporting and bug application for wine could make wine more userfriendly. This really cannot be automatic when wine runs because that would just generate too much server load and be breach of privacy. But a tool user can choose to run when they have trouble is fine.
Advantage with a program bug reporting tool it can be setup to check common causes of invalid bug reports like bad opengl. Even provide the data to pastebin for use with irc channel.
Advantage with status reporting program as noted in the appdb people forget to post there tweaks and give applications plat status when they have used tweaks.
There are lots of usability things that can be improved. Currently users have to run from command line to get wine debugging information. This is kinda hard on new users.
So idea itself is not without base. Way to do needs to be different.
I think an interesting way of helping would be some kind of feedback after a crash of:
- Which natives dlls have been called and which native dlls were still loaded at the time of the crash. Would be a function like wineserver -k -log
- Differences which a vanilla Wine, i.e. a report of all natives dlls in system32 and all installed assemblies in the builtin WinSxS.
- Report of all dlls which have a override (buitin to native).
That way, you may get an idea of which (incomplete) builtin library caused the crash along with the crash report of whether as some developers like to say Wine had been corrupted by some uneducated use of a override.
- Which natives dlls have been called and which native dlls were still loaded at the time of the crash. Would be a function like wineserver -k -log
- Differences which a vanilla Wine, i.e. a report of all natives dlls in system32 and all installed assemblies in the builtin WinSxS.
- Report of all dlls which have a override (buitin to native).
That way, you may get an idea of which (incomplete) builtin library caused the crash along with the crash report of whether as some developers like to say Wine had been corrupted by some uneducated use of a override.
