This is the initial TODO for Wine 0.8.
I know, 0.8 has been released before, but that's ancient history. Whether or not it gets released with this version number is irrelevant. In fact, even if it never becomes a public release, it is an important point to reach toward 0.9, and so if we complete this work, it would have solved its purpose.
Now, again, what I mean by 0.8: -- Users can start using Wine -- works well for a fair number of apps -- no MS DLLs required (from real Windows) -- User facing stuff (website, docs, etc.) are in a decent state, to avoid scaring them away What is NOT in 0.8: -- stable server protocol: no binary compatibility -- DLL separation: ditto
That being said, this is my initial list. Comments, flames, suggestions, are appreciated.
A. WineHQ work 0. Reorganize a bit the navigational menu 1. Add a screenshot link to the homepage 2. Create some really sexy screenshots 3. Rework the FAQ interface (static HTML, a la http://www.dvddemystified.com/dvdfaq.html, all on one page, with a clickable question list at the top) 4. Enlist some 'official' distribution maintainers (at the minimum RedHat, Suse, UnitedLinux, Debian) 5. Create nice page with apps that run virtually flawless They should not require MS dlls, tricks, etc. to run Small explanation, screeshot, optional link to download page, such as Tucows.
B. Documentation work Andy, take it away! :)
C. Wine configuration 0. Merge configuration into the registry 1. Write control panel applets for editing it 2. Have decent defaults so we can start control panel without prior configuration 3. Have wizard like app to autoconfigure wine (?) 4. Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg 5. Write .inf script to setup a new Wine installation
D. Stabilize utilities 0. Get rid of the init directive from .spec files 1. Make sure the .spec file format is fairly stable 2. Ensure the various utilities' options are stable
E. Important fixes Alexandre, what to you see here?
"Dimitrie O. Paun" dpaun@rogers.com writes:
Now, again, what I mean by 0.8: -- Users can start using Wine -- works well for a fair number of apps -- no MS DLLs required (from real Windows)
That alone should take a couple of years <g>
-- User facing stuff (website, docs, etc.) are in a decent state, to avoid scaring them away What is NOT in 0.8: -- stable server protocol: no binary compatibility -- DLL separation: ditto
IMO the goals for 0.9 will be reached before the ones for 0.8 so you might as well put everything together...
D. Stabilize utilities 0. Get rid of the init directive from .spec files
This requires dll separation...
E. Important fixes Alexandre, what to you see here?
I think the window management stuff is important, otherwise you can't install most apps without using desktop mode. But it's already in the 0.9 goals (and I'm working on it).
El jue, 31 de oct de 2002, a las 15:02, Alexandre Julliard escribio:
"Dimitrie O. Paun" dpaun@rogers.com writes:
Now, again, what I mean by 0.8: -- Users can start using Wine -- works well for a fair number of apps -- no MS DLLs required (from real Windows)
That alone should take a couple of years <g>
It depends on the complex of the apps (winmx,icq or ie6,officeXP ;) and what you means by "works well" ;) 70-80% or 95-100% functionality??
A list of apps should be prepared at least several months before of a release, and sometime before of release's time freeze the advance and concentrate in stabilize this applications. It should be good select the apps seeing the DLLs needed.
Hmm, surely after of the release the development should be divided in stable/unstable, because it should be a bad thing that 8.0 should run "Ex. ie5" and 8.1 no :/
Regards, Carlos.
It depends on the complex of the apps (winmx,icq or ie6,officeXP ;) and what you means by "works well" ;) 70-80% or 95-100% functionality??
ICQ and IE6 both install and work fine, over here. Never tried WinMX. I hear some significant progress is being made in the officeXP area over at CW :)
- Ender
On October 31, 2002 10:52 pm, Ender wrote:
ICQ and IE6 both install and work fine, over here.
Without any native DLLs?
On October 31, 2002 10:52 pm, Ender wrote:
ICQ and IE6 both install and work fine, over here.
Without any native DLLs?
Almost. It's on a 100% no-windows install, the only naitve DLL's I use are installed by IE6 itself - I think I'm using native crypt32/secur32 to get SSL working, and native wininet.
It did take some registry hacking to get working, and I didn't note down what :/
- Ender
On November 1, 2002 12:52 am, Ender wrote:
Almost. It's on a 100% no-windows install, the only naitve DLL's I use are installed by IE6 itself - I think I'm using native crypt32/secur32 to get SSL working, and native wininet.
I don't care what the app installs. I care what you do _before_ the app installs. That is, you should have no native DLLs in your fake windows.
It did take some registry hacking to get working, and I didn't note down what :/
Too bad, these are nice apps to showcase. Maybe you can rediscover? ;)
"Dimitrie O. Paun" dpaun@rogers.com writes:
I don't care what the app installs. I care what you do _before_ the app installs. That is, you should have no native DLLs in your fake windows.
Oh, if you allow using native dlls that the app installs then things are easier; I thought you wanted to make things work with builtins only. But then you cannot ignore the dll overrides problem, you need to tweak the overrides just right for every app, and make sure you get the correct version of every native dlls (for the same native dll some versions work and some don't).
On November 1, 2002 01:38 pm, Alexandre Julliard wrote:
Oh, if you allow using native dlls that the app installs then things are easier; I thought you wanted to make things work with builtins only. But then you cannot ignore the dll overrides problem, you need to tweak the overrides just right for every app, and make sure you get the correct version of every native dlls (for the same native dll some versions work and some don't).
Good point. Tweaking the dll overrides is a big NO-NO. We should look for apps that run with the current Wine default overrides:
[DllOverrides] ; some dlls you may want to change "oleaut32" = "builtin, native" "ole32" = "builtin, native" "commdlg" = "builtin, native" "comdlg32" = "builtin, native" "shell" = "builtin, native" "shell32" = "builtin, native" "shfolder" = "builtin, native" "shlwapi" = "builtin, native" "shdocvw" = "builtin, native" "advapi32" = "builtin, native" "msvcrt" = "native, builtin" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" ; you can specify applications too ; this one will apply for all notepad.exe ;"*notepad.exe" = "native, builtin" ; this one will apply only for a particular file ;"C:\windows\regedit.exe" = "native, builtin" ; default for all other dlls "*" = "builtin, native"
Hopefully we can switch msvcrt, mciavi.drv, and mcianim.drv to "builtin, native", as well. What are we missing to do that, BTW?
On Friday 01 November 2002 02:35 pm, Dimitrie O. Paun wrote:
[DllOverrides] ; some dlls you may want to change "oleaut32" = "builtin, native" "ole32" = "builtin, native" "commdlg" = "builtin, native" "comdlg32" = "builtin, native" "shell" = "builtin, native" "shell32" = "builtin, native" "shfolder" = "builtin, native" "shlwapi" = "builtin, native" "shdocvw" = "builtin, native" "advapi32" = "builtin, native" "msvcrt" = "native, builtin" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" ; you can specify applications too ; this one will apply for all notepad.exe ;"*notepad.exe" = "native, builtin" ; this one will apply only for a particular file ;"C:\windows\regedit.exe" = "native, builtin" ; default for all other dlls "*" = "builtin, native"
this reminds me, now that it's empty, shouldn't we add
"quartz" = "native, builtin"
?
Maybe not: I do this, but I don't even really know what the bloody thing does, and I don't notice any difference in my multimedia stuff (maybe 'cause there barely is any... the only thing I use regularly is winamp to listen to shoutcast streams, which, sadly, xmms doesn't seem to grok (?)).
On November 1, 2002 01:38 pm, Alexandre Julliard wrote:
Oh, if you allow using native dlls that the app installs then things are easier; I thought you wanted to make things work with builtins only. But then you cannot ignore the dll overrides problem, you need to tweak the overrides just right for every app, and make sure you get the correct version of every native dlls (for the same native dll some versions work and some don't).
Good point. Tweaking the dll overrides is a big NO-NO. We should look for apps that run with the current Wine default overrides:
<snip>
This really depends on what your aim is for 0.8.0 - from what I've read, your aim is to create a release which provides decent compatability, a good user experience, and -REQUIRES- no native DLLs.
However for this really to happen, you'll need to make some compromises on various DLL preferences. For example, the two the most common programs people first try to install under WINE are either Microsoft Word, or (which recent versions of Office require anyway..) Internet Explorer.
If you expect internet explorer to work, you are GOING to have to have at least shdocvw,shlwapi set native,builtin. That way they are not required, but if IE is installed and those DLLs exist, you will need to use the native versions. I really can't imagine ANY way we could create a builtin version of those two dll's which will work with -all- internet explorer versions, as the DLL's change horribly between revisions and even service packs. I think urlmon suffers from the same fate, but I'm not certain.
As these middleware DLLs change interfaces so often, we would either need a major hack-job to try and select the right version for the calling middleware.... or have a configuration file that will default them to native.
I'm sure other DLLs suffer from the same problem, these are DLLs we simply cannot hope to emulate to the extent where large middleware applications work. The main external APIs and/or COM interfaces may remain the same, but the middleware itself relies too much on subtle differences in the undocumeneted interfaces.
Cheers, - Ender
On November 2, 2002 12:02 am, Ender wrote:
If you expect internet explorer to work, you are GOING to have to have at least shdocvw,shlwapi set native,builtin. That way they are not required, but if IE is installed and those DLLs exist, you will need to use the native versions. I really can't imagine ANY way we could create a builtin version of those two dll's which will work with -all- internet explorer versions, as the DLL's change horribly between revisions and even service packs. I think urlmon suffers from the same fate, but I'm not certain.
If this is the only tweak required for IE6, I think it's acceptable since IE is such a high visibility app. However, we have to be very careful with these things because this way lies madness. So if other apps require such tweaks, they will not make our Gold list. A separate section, with instructions is more appropriate.
We can not go down the path of customizing dlls overrides for every app out there, because sooner rather than later we will encounter contradicting requirements. It's better IMO to have a default config that has the default overrides to "builtin, native", so that we encourage people to fix applications to work in this configuration (maybe IE is the big exception, but I am not convinced).
I would say that with 0.8/0.9 we should say we support so many apps (and they don't have to be IE or Word), with _NO_ native DLLs. If these apps are apps like FTP Commander, WinZip, Xnews, etc., we would have delivered an exciting release. In fact, heavyweights like IE, and Word should come supported in later releases, to refresh excitement. :)
On Sat, 2 Nov 2002, Dimitrie O. Paun wrote:
On November 2, 2002 12:02 am, Ender wrote:
If you expect internet explorer to work, you are GOING to have to have at least shdocvw,shlwapi set native,builtin. That way they are not required, but if IE is installed and those DLLs exist, you will need to use the native versions. I really can't imagine ANY way we could create a builtin version of those two dll's which will work with -all- internet explorer versions, as the DLL's change horribly between revisions and even service packs. I think urlmon suffers from the same fate, but I'm not certain.
If this is the only tweak required for IE6, I think it's acceptable since IE is such a high visibility app. However, we have to be very careful with these things because this way lies madness.
Two related notes: * you can specify DllOverrides on a per application basis * one place where to put this information is in the Application Database
*** Call for Application Owners ***
For instance, let's say I want to run for DreaWeaver 4. I go to the application database and see this:
---
To get DreamWeaver running, append the following lines to your Wine configuration file:
[AppDefaults\Dreamweaver.exe\DllOverrides] "comctl32" = "builtin,native" "shfolder" = "native" "ole32" = "builtin" "oleaut32" = "builtin" "msvcp60" = "native" "msvcrt" = "native" "mfc42" = "native" "imm32" = "builtin,native"
[AppDefaults\Dreamweaver.exe\x11drv] "Managed" = "N" "Desktop" = "1024x768"
---
Now what's cool is that this information actually is in the Application Database, it's just a bit buried (hopefully it's correct too). What's needed is:
* more applications should have instructions like the above * we need Application Owners who use a given application regularly and can check the validity of these settings, can put them at the beginning of the page, and keep them up to date
Then we can decide whether such options should be present in Wine's default configuration file, what to do if a given application has different requirements depending on its version, etc.
But already having the information in the Application Database would be very helpful.
On November 2, 2002 02:23 am, Francois Gouget wrote:
- you can specify DllOverrides on a per application basis
This is priceless, thank you Francois for pointing it out. Now, I still think 0.9 should be delivered without DLLs tweaks -- we should keep them for 1.0. But documenting them in the appdb is very important, if we are to every support per-app tweaks. And while we can simply ignore them for the 0.9 release, we can point people to them, so that they tweak them themselves. Who knows, maybe some of them will become Wine hackers! :)
On Saturday 02 November 2002 01:23 am, Francois Gouget wrote:
For instance, let's say I want to run for DreaWeaver 4. I go to the application database and see this:
To get DreamWeaver running, append the following lines to your Wine configuration file:
[AppDefaults\Dreamweaver.exe\DllOverrides] "comctl32" = "builtin,native" "shfolder" = "native" "ole32" = "builtin" "oleaut32" = "builtin" "msvcp60" = "native" "msvcrt" = "native" "mfc42" = "native" "imm32" = "builtin,native"
[AppDefaults\Dreamweaver.exe\x11drv] "Managed" = "N" "Desktop" = "1024x768"
Now what's cool is that this information actually is in the Application Database, it's just a bit buried (hopefully it's correct too). What's needed is:
- more applications should have instructions like the above
- we need Application Owners who use a given application regularly
and can check the validity of these settings, can put them at the beginning of the page, and keep them up to date
Can't we do one better by maintaining this information in the wine tree itself? I know such things /are/ hacks, but they are needed for several important applications, especially the "big ones". Keeping it in cvs (or some other easily updated database) just seems like the most likely way to get it actually kept up to date.
I realize this might not be the most popular proposal amongst the wine-devel crowd, given the desire of all of us to have the builtin dlls work properly in wine for all app's; but the reality is that wine isn't there yet and probably won't be for some time.
IMHO there is probably some kind of potential synergy between Jeremy's idea of integrating WineSetupTk with wine, and Francois' idea of keeping these dll overrides up-to-date -- I think it would be really cool if we could arrange things so that wine "just works" out of the box for commonly used app's. IMHO, this is more important than getting folks to fix bugs in wine; if they are inclined, and able to do so, they will be able to find the config file and hack on it. WineSetupTk provides all the hard parts of the infrastructure already: namely, a gui onto the ~/.wine/config file.
Since wine is rapidly evolving, we all want to stay on the bleeding edge, and users probably do too... I don't know about y'all, but I regularly manually merge changes to:
o the wine default registry o the wine default config file
into my installation in ~/.wine, from changes I see in CVS. It's a minor hassle for me; but unless you happen to be intimately familiar with version control techniques in general, and cvs/diff/patch utilities in particular, it's probably quite difficult to keep this all sorted out. You can probably guess where I'm headed with this:
o A database of configs and registries, with actual version numbers and change history (cvs could be all the database we need, or we could implement some more sophisticated system) o WineSetupTk (at least as a starting point) o Glue to launch WineSetupTk as a control-panel application o More glue to integrate WineSetupTk with the forementioned version database.
So, user Less Clue updates his wine. When next time he runs, some little dialog box pops up:
"New default registry entries and default configuration settings are available for wine. How to deal with this?
[ ] Attempt to merge changes automatically. [x] Ask me again later. [ ] Ignore the changes. [ ] Never, ever, show me this crap again. [ ] View the changes and merge them manually."
If Less isn't into tweaking the hell out of his config files, then he just picks "merge automatically" and his wine keeps on "just working," but he has all the latest-and-greatest defaults installed into his ~/.wine/config with no thinking involved, and no editing text-files. If he does need to do some hacking, but is scared of text files, well, we have a gui for him to do that.
This scheme can be adapted to a pure-registry-based approach with ease (in fact a pure-registry approach makes it /easier/ to implement since you now only have to merge registries, which already have a nice (OK, usable) API on them we can query (win32), and the config file is gone (or highly static)).
Just plantin' seeds...
--- Francois Gouget fgouget@free.fr wrote:
On Sat, 2 Nov 2002, Dimitrie O. Paun wrote:
On November 2, 2002 12:02 am, Ender wrote:
If you expect internet explorer to work, you are GOING to have to have
at
least shdocvw,shlwapi set native,builtin. That way they are not
required,
but if IE is installed and those DLLs exist, you will need to use the native versions. I really can't imagine ANY way we could create a
builtin
version of those two dll's which will work with -all- internet explorer versions, as the DLL's change horribly between revisions and even
service
packs. I think urlmon suffers from the same fate, but I'm not certain.
If this is the only tweak required for IE6, I think it's acceptable since IE is such a high visibility app. However, we have to be very careful
with
these things because this way lies madness.
Two related notes:
you can specify DllOverrides on a per application basis
one place where to put this information is in the Application Database
*** Call for Application Owners ***For instance, let's say I want to run for DreaWeaver 4. I go to the application database and see this:
To get DreamWeaver running, append the following lines to your Wine configuration file:
[AppDefaults\Dreamweaver.exe\DllOverrides] "comctl32" = "builtin,native" "shfolder" = "native" "ole32" = "builtin" "oleaut32" = "builtin" "msvcp60" = "native" "msvcrt" = "native" "mfc42" = "native" "imm32" = "builtin,native"
[AppDefaults\Dreamweaver.exe\x11drv] "Managed" = "N" "Desktop" = "1024x768"
The problem is what if another program requires a different version of native mscvrt, perhaps a later version of it that dreamweaver doesnt (for whatever reason) work with. The the user has to dll switching depending on the program he wants to run. In windows it somehow compensates for this and both programs run (even if some things in DreamWeaver dont exactly work right ;) thats MS for ya.. )
Now what's cool is that this information actually is in the Application Database, it's just a bit buried (hopefully it's correct too). What's needed is:
- more applications should have instructions like the above
- we need Application Owners who use a given application regularly and
can check the validity of these settings, can put them at the beginning of the page, and keep them up to date
*** Call For AppDB Overhaul ***
I have never understood the purpose of the AppDB, until recently, and the reason for that is because all I see is a bunch of apps listed with ratings that one user put in because he couldnt get it to run, and then a forum for each app that is borked in and of itself... That is why I have shot down every idea thus far to use the AppDB (or at least tried to). But if someone can show me where these cool sounding features are that I seem to have completely missed, I will probably go along with the AppDB.
Then we can decide whether such options should be present in Wine's default configuration file, what to do if a given application has different requirements depending on its version, etc.
But already having the information in the Application Database would be very helpful.
See above.
__________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
*** Call For AppDB Overhaul ***I have never understood the purpose of the AppDB, until recently, and the reason for that is because all I see is a bunch of apps listed with ratings that one user put in because he couldnt get it to run, and then a forum for each app that is borked in and of itself... That is why I have shot down every idea thus far to use the AppDB (or at least tried to). But if someone can show me where these cool sounding features are that I seem to have completely missed, I will probably go along with the AppDB.
Well, for that you can read a thread on this topic here on WineDevel a long time ago (oh, about 6 to 12 months back).
My proposal was back then that you would have one maintainer (or a bunch of them) for an application, that one would be the ONLY one able to change the status / description / how-to for this application. The forum would then only be relegated to people asking for support, people should NEVER have to read the forum to see how the application works, everything should be on the main page.
The role of this maintainer would also then to test the application for each release of Wine and update the status accordingly. Anyone not updating the status within X days (weeks ?) after a Wine release would put the application in an 'unmaintained' state and would then require the addition of a new maintainer.
This is, for me, the only way this could even work and be a little bit useful.
If we have even 10 or 20 of the most used application with a dedicated and competent maintainer, this would make Wine so much useful....
Lionel
On November 2, 2002 09:46 am, Lionel Ulmer wrote:
The role of this maintainer would also then to test the application for each release of Wine and update the status accordingly. Anyone not updating the status within X days (weeks ?) after a Wine release would put the application in an 'unmaintained' state and would then require the addition of a new maintainer.
This is, for me, the only way this could even work and be a little bit useful.
I have to agree 100% with Lionel here. A lot of things _need_ careful, and manual attention. This type of information gets bitrotten way too quickly, and bad information is worse than no information by a large margin. It needs to be maintained. I, for one, if I don't see a _clear_ indication that it is (such as, "Last updated 3 days ago", or "Tested with WineYYYYMMDD"), will assume it's obsolete, and don't use it.
--- "Dimitrie O. Paun" dpaun@rogers.com wrote:
On November 2, 2002 12:02 am, Ender wrote:
If you expect internet explorer to work, you are GOING to have to have at least shdocvw,shlwapi set native,builtin. That way they are not required, but if IE is installed and those DLLs exist, you will need to use the native versions. I really can't imagine ANY way we could create a builtin version of those two dll's which will work with -all- internet explorer versions, as the DLL's change horribly between revisions and even service packs. I think urlmon suffers from the same fate, but I'm not certain.
If this is the only tweak required for IE6, I think it's acceptable since IE is such a high visibility app. However, we have to be very careful with these things because this way lies madness. So if other apps require such tweaks, they will not make our Gold list. A separate section, with instructions is more appropriate.
It pretty much has to be acceptable, I was thinking about suggesting miltiple versions of those files but the requirements to maintain that number of different versions of the same dll is too great so i said scrap that.
We can not go down the path of customizing dlls overrides for every app out there, because sooner rather than later we will encounter contradicting requirements. It's better IMO to have a default config that has the default overrides to "builtin, native", so that we encourage people to fix applications to work in this configuration (maybe IE is the big exception, but I am not convinced).
See above. No we cant and shouldnt do that. Even with the AppDefaults section, there can and most likely always will be conflicting requirements for different apps because inevitably someone isnt using the latest version (for whatever reason) of a dll when they compile and so the older version is required...
I would say that with 0.8/0.9 we should say we support so many apps (and they don't have to be IE or Word), with _NO_ native DLLs. If these apps are apps like FTP Commander, WinZip, Xnews, etc., we would have delivered an exciting release. In fact, heavyweights like IE, and Word should come supported in later releases, to refresh excitement. :)
I agree, because even if we dont support it doesnt mean it wont run it just means that if they have a problem getting it to work, they cant come crying to us to fix it like they can the supported apps...
-Dustin
__________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
If you expect internet explorer to work, you are GOING to have to have at least shdocvw,shlwapi set native,builtin. That way they are not required, but if IE is installed and those DLLs exist, you will need to use the native versions. I really can't imagine ANY way we could create a builtin version of those two dll's which will work with -all- internet explorer versions, as the DLL's change horribly between revisions and even service packs. I think urlmon suffers from the same fate, but I'm not certain.
Hmm, you means that shlwapi and ..., works only with one version of ie? Good, it shouldn't be a problem then, we should support then only 1 version, and should try adjust this libraries to that version. Maybe that i haven't taken the point hmm..
Regards, Carlos.
Oh, one other thing that would be nice, while I think of it... is there any reason (now we are GPL'ed) that we cannot incorperate cabextract (http://www.kyz.uklinux.net/cabextract.php3) into Wine?
Currently we shell out to it as an external program, in order to run Microsoft's setup APIs ecetra. This is really annoying for new users, as unless they look closely at pages of logs... theres no real indication that's why installation of a Microsoft program failed.
- Ender
On Fri, 1 Nov 2002, Dimitrie O. Paun wrote:
Date: Fri, 1 Nov 2002 00:31:34 -0500 From: Dimitrie O. Paun dpaun@rogers.com To: Ender winedev@admdev.com, Carlos Lozano clozano@andago.com Cc: wine-devel@winehq.com Subject: Re: Wine 0.8 TODO v0.1
On October 31, 2002 10:52 pm, Ender wrote:
ICQ and IE6 both install and work fine, over here.
Without any native DLLs?
-- Dimi.
Ender wrote:
Oh, one other thing that would be nice, while I think of it... is there any reason (now we are GPL'ed) that we cannot incorperate cabextract (http://www.kyz.uklinux.net/cabextract.php3) into Wine?
Interresting thought, which I think is worth exploring. As long as Wine doesn't add every single program out there to it's build, (there are some projects taking this approach) it should be fine.
Greetings, Jaco
Alexandre Julliard wrote:
I think the window management stuff is important, otherwise you can't install most apps without using desktop mode. But it's already in the 0.9 goals (and I'm working on it).
And it's improving in leaps and bounds. WM updates done in the last month or so have improved the useability of several of the applications I use regularly out of sight. Thanks :p)
On October 31, 2002 06:02 pm, Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
-- Users can start using Wine -- works well for a fair number of apps -- no MS DLLs required (from real Windows)
That alone should take a couple of years <g>
Oh, what next, Murphy was an optimist?!? :)))
If we run 20 of the top 50 downloads from Tucows, we're doing good. I don't think we're that far off. Carlos, you we were doing some tests, care to look into this one?
What is NOT in 0.8: -- stable server protocol: no binary compatibility -- DLL separation: ditto
IMO the goals for 0.9 will be reached before the ones for 0.8 so you might as well put everything together...
Maybe so, you know this better. But 0.9 needs what's listed here anyhow, if we hit the 0.9 targets before, no harm's done. I am not that optimistic about the DLL separation. The x11drv is a bit of a mess, as we have a WND structure maintained by USER, which x11drv needs access to. It needs work. And in general, the separation work that's left is not trivial, and you seem to be the only one qualified to do it. And you are one busy guy...
D. Stabilize utilities 0. Get rid of the init directive from .spec files
This requires dll separation...
Well, the init directive stuff is not really mandatory for the goals of 0.8. I just put it here since you said you're working on some linker hacks to get this working before we have proper DLL separation. If we can get it soon, great (as people don't react nicely to format changes), if not, it belongs in the 0.9 list.
E. Important fixes Alexandre, what to you see here?
I think the window management stuff is important, otherwise you can't install most apps without using desktop mode. But it's already in the 0.9 goals (and I'm working on it).
Good to know. Indeed, I would say this is a requirement for 0.8 (as defined above).
El jue, 31 de oct de 2002, a las 23:56, Dimitrie O. Paun escribio:
On October 31, 2002 06:02 pm, Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
-- Users can start using Wine -- works well for a fair number of apps -- no MS DLLs required (from real Windows)
That alone should take a couple of years <g>
Oh, what next, Murphy was an optimist?!? :)))
If we run 20 of the top 50 downloads from Tucows, we're doing good. I don't think we're that far off. Carlos, you we were doing some tests, care to look into this one?
Oki doki :)
Regards, Carlos.
On November 1, 2002 05:40 am, Carlos Lozano wrote:
Oki doki :)
Very cool. Things like FTP Commander, WinZip, etc. Even if they are not perfect (like FTP Commnader with it's ComboEx problem), but they look like can be esily fixed. We can then start going through them, and getting them to work.
Andi and I have talked about the FAQ a lot on and off through the years, going back to when he was in St. Paul and first set up the FAQ-o-matic.
When I go visit a project the very first thing I look at (before screenshots, about, or *anything* else) is the FAQ.
Therefore, I think it's extremely important to have a good FAQ.
Now, Andi has poured a lot of work and energy into the FAQ over the years. But, here's the truth - it's not really a job he wants. (He and I discussed it privately). There are a lot of other things he'd rather do.
So, I'm hoping that we could get a volunteer to step forward and take over responsibility for the FAQ from Andi. I'm particularly hoping that one of the new crop of wine-devel participants would be inspired to volunteer.
My vision for the FAQ is a hand edited main FAQ with the current FAQ-o-matic being pushed to a secondary role.
Cheers,
Jeremy
My vision for the FAQ is a hand edited main FAQ with the current FAQ-o-matic being pushed to a secondary role.
I request that the new FAQ be done in the same was as the Docs, with SGML tools. This way it can be published in several formats.
On November 1, 2002 08:15 am, Jeremy White wrote:
My vision for the FAQ is a hand edited main FAQ with the current FAQ-o-matic being pushed to a secondary role.
Please get rid of the FAQ-O-matic. The interface is atrocious. A hand written one would do just fine, is not like we add 100 questions per day! (And if we do, something's wrong, who's gonna read them?)
On Fri, Nov 01, 2002 at 03:06:55PM -0500, Dimitrie O. Paun wrote:
On November 1, 2002 08:15 am, Jeremy White wrote:
My vision for the FAQ is a hand edited main FAQ with the current FAQ-o-matic being pushed to a secondary role.
Please get rid of the FAQ-O-matic. The interface is atrocious. A hand written one would do just fine, is not like we add 100 questions per day! (And if we do, something's wrong, who's gonna read them?)
Excuse me, what is sooooooo terrible about the FOM ??? Having to maintain hundreds of different web pages by hand (in order to gain the required interdependencies for some complicated issues) is a *lot* more difficult than simply adding/removing/reordering FOM content as you see fit. I agree that using a static web page for the FAQ part instead could probably be better - but for the troubleshooting content ?? The troubleshooting content is meant to be a step-by-step problem solver area (and it is, to some extent). Now tell me how you'd implement the same thing easily with an ordinary web page, without losing flexibility for very quick changes/reordering ??
*I* am the one maintaining the FOM (well, currently on the paper at least :-) and thus *I* reserve the right to have some extra say on how that docu part should be done. To me it sounds a bit like people turn a glaring maintenance problem (I currently don't have a lot of time to give it the necessary attention it requires due to people adding tons of stuff, and there're not too many people to still properly handle this) into a general, greatly simplifying "we need something entirely different, this sucks" kinda thing.
IMHO the REAL problem here is that the content is sort of outdated and unmaintained since I currently don't have a whole lot of time to spend in the IRC channel in order to catch up current Wine issues of people, and of course due to other obvious reasons.
...unless you can convince me that the FOM *indeed* is the wrong approach and you name me a valid replacement that handles the step-by-step problem solving approach at least as well as the FOM (or you name me an entirely different approach that is *superiour*).
Turning the FOM read-only might also be a "solution" to the maintenance issue...
I'm starting to be fed up about the fact that people keep complaining about things, without *really* suggesting superiour alternatives and *really* making sure this gets fixed if it's not good enough.
On November 1, 2002 04:02 pm, Andreas Mohr wrote:
Excuse me, what is sooooooo terrible about the FOM ??? Having to maintain hundreds of different web pages by hand (in order to gain the required interdependencies for some complicated issues) is a *lot* more difficult than simply adding/removing/reordering FOM content as you see fit.
But this is not the point. I was pretty clear on my problem with the FAQ-O-Matic: the interface is soooo bad, I wonder if anyone bothers reading the content! I was also clear on the solution, too. That is, I suggested something on lines of this FAQ: http://www.dvddemystified.com/dvdfaq.html While this is a *HUGE* FAQ, it's all in *one* page. This is important, as people don't have to click like crazy around to read it. The formatting is simple, distinctive, and easy on the eyes. It's easy to navigate (you can just click on the question), or read (just scroll down the page). It's simply a pleasant experience.
Now, from a maintenance point of view: we don't need "hundreds of different web pages". The problem with the DVD FAQ is that it is way too big. I suggested only for the format. Ours should not have more than 50 questions. If it does, something is wrong. Very wrong: -- important issues get lost in the torrent of information -- few people will bother reading it -- we actually *scare* people away -- it's a maintenance nightmare!
My do we need some special tool to maintain one page of FAQs?
On Fri, Nov 01, 2002 at 04:21:54PM -0500, Dimitrie O. Paun wrote:
On November 1, 2002 04:02 pm, Andreas Mohr wrote:
Excuse me, what is sooooooo terrible about the FOM ??? Having to maintain hundreds of different web pages by hand (in order to gain the required interdependencies for some complicated issues) is a *lot* more difficult than simply adding/removing/reordering FOM content as you see fit.
But this is not the point. I was pretty clear on my problem with the FAQ-O-Matic: the interface is soooo bad, I wonder if anyone bothers reading the content! I was also clear on the solution, too. That is, I suggested something on lines of this FAQ: http://www.dvddemystified.com/dvdfaq.html While this is a *HUGE* FAQ, it's all in *one* page. This is important, as people don't have to click like crazy around to read it. The formatting is simple, distinctive, and easy on the eyes. It's easy to navigate (you can just click on the question), or read (just scroll down the page). It's simply a pleasant experience.
And this is not my point either...
My (hidden) point was that the FOM is two *SEPARATE* units, the FAQ and everything else. (as always, nobody seems to grasp this)
Now, from a maintenance point of view: we don't need "hundreds of different web pages". The problem with the DVD FAQ is that it is
We definitely do. Not for the FAQ, but for everything else. IMHO.
way too big. I suggested only for the format. Ours should not have more than 50 questions. If it does, something is wrong. Very wrong: -- important issues get lost in the torrent of information -- few people will bother reading it -- we actually *scare* people away -- it's a maintenance nightmare!
My do we need some special tool to maintain one page of FAQs?
Like I said, not necessarily. I originally chose to also migrate the FAQ content to the FOM, since adding/modifying was a lot faster that way. Turned out that adding the FAQs probably wasn't a winner... (mainly to the "not one page" syndrome, which should be the case for the FAQ)
On November 1, 2002 04:36 pm, Andreas Mohr wrote:
My (hidden) point was that the FOM is two *SEPARATE* units, the FAQ and everything else. (as always, nobody seems to grasp this)
Good point, but you see, I wasn't grasping it :) But that's a problem in itself, there's some confusion there, no?
Now, from a maintenance point of view: we don't need "hundreds of different web pages". The problem with the DVD FAQ is that it is
We definitely do. Not for the FAQ, but for everything else. IMHO.
One thing at a time. So it seems are on the same wavelength with the FAQ. Let's discuss the troubleshooting bit in the other email I've sent.
On Fri, Nov 01, 2002 at 04:44:53PM -0500, Dimitrie O. Paun wrote:
On November 1, 2002 04:36 pm, Andreas Mohr wrote:
My (hidden) point was that the FOM is two *SEPARATE* units, the FAQ and everything else. (as always, nobody seems to grasp this)
Good point, but you see, I wasn't grasping it :) But that's a problem in itself, there's some confusion there, no?
Err, yes.
P.S. Guess we can consider the FAQ issue closed, right?
Yep, the FAQ stuff should be moved back to a static page.
On November 1, 2002 04:02 pm, Andreas Mohr wrote:
I agree that using a static web page for the FAQ part instead could probably be better - but for the troubleshooting content ?? The troubleshooting content is meant to be a step-by-step problem solver area (and it is, to some extent). Now tell me how you'd implement the same thing easily with an ordinary web page, without losing flexibility for very quick changes/reordering ??
Well, for one thing, this should not be in the FAQ, but a separate troubleshooting section. Second, I *know* I don't want to see the FOM as a user. It's just bad. Beyond words! :) I don't understand why you want this very quick changes/reordering flexibility. It just seems we're trying to fix the wrong problem. We don't need a tool to help us add hundred of pages, because nobody will bother to read them. We need to think how we can present the information in a few pages. Tops. If not, we are better off spending the time fixing the problems, rather than documenting workarounds on hundreds of pages.
On Fri, Nov 01, 2002 at 04:29:20PM -0500, Dimitrie O. Paun wrote:
On November 1, 2002 04:02 pm, Andreas Mohr wrote:
I agree that using a static web page for the FAQ part instead could probably be better - but for the troubleshooting content ?? The troubleshooting content is meant to be a step-by-step problem solver area (and it is, to some extent). Now tell me how you'd implement the same thing easily with an ordinary web page, without losing flexibility for very quick changes/reordering ??
Well, for one thing, this should not be in the FAQ, but a separate troubleshooting section. Second, I *know* I don't want to see the FOM as a user. It's just bad. Beyond words! :) I don't understand why you want this very quick changes/reordering flexibility. It just seems we're trying to fix the wrong problem. We don't need a tool to help us add hundred of pages, because nobody will bother to read them. We need to think how we can present the information in a few pages. Tops. If not, we are better off spending the time fixing the problems, rather than documenting workarounds on hundreds of pages.
The largest part of the FOM *is* the troubleshooting section. The FAQ is only a small part of the FOM that has been added later for maintenance convenience of the FAQ.
Good luck implementing it in a different way. I'm outta that one for now, especially given that spending my time on non-Wine things currently probably is a wise thing to do.
About the hundreds of pages: What's so problematic with navigating a directory structure that gets more and more specific about your problem until you (hopefully) hit the specific answer to your question ? That'd all get lost with your suggested change.
Sometimes I've got the impression that I'm partly fighting the "KISS dumb-it-down-until-there-is-plain-nothing-left-to-annoy-the-helpless-user- with-its-bewildering-size-and-information-overload syndrome".
On November 1, 2002 04:49 pm, Andreas Mohr wrote:
Sometimes I've got the impression that I'm partly fighting the "KISS dumb-it-down-until-there-is-plain-nothing-left-to-annoy-the-helpless-user- with-its-bewildering-size-and-information-overload syndrome".
Well, that's true. At least from my side. And I think there's a fair bit of rationale behind it too: these docs are intended for the helpless users, if you're writing them for Alexandre, you're wasting our time.
Back to the troubleshooting portion:
What's so problematic with navigating a directory structure that gets more and more specific about your problem until you (hopefully) hit the specific answer to your question ?
That's a valid point. You see, it's easier sometimes to say what you don't like, than what you like. In this case, it may make a lot of sense to have a hierarchical organization, in which case my only argument would be for a more tidy UI.
----- Original Message ----- From: "Dimitrie O. Paun" dpaun@rogers.com To: andi@rhlx01.fht-esslingen.de Cc: "Jeremy White" jwhite@codeweavers.com; wine-devel@winehq.com Sent: Friday, November 01, 2002 5:29 PM Subject: Re: Wine FAQ - call for a volunteer
On November 1, 2002 04:02 pm, Andreas Mohr wrote:
I agree that using a static web page for the FAQ part instead could probably be better - but for the troubleshooting content ?? The troubleshooting content is meant to be a step-by-step problem solver area (and it is, to some extent). Now tell me how you'd implement the same thing easily with an ordinary web page, without losing flexibility for very quick changes/reordering ??
Well, for one thing, this should not be in the FAQ, but a separate troubleshooting section. Second, I *know* I don't want to see the FOM as a user.
I'm a user, hovering around the edges of linux and wine for several years, and I use this faq-o-matic alot.
It's just bad. Beyond words! :) I don't understand
why you want this very quick changes/reordering flexibility. It just seems we're trying to fix the wrong problem. We don't need a tool to help us add hundred of pages, because nobody will bother to read them. We need to think how we can present the information in a few pages. Tops. If not, we are better off spending the time fixing the problems, rather than documenting workarounds on hundreds of pages.
-- Dimi.
Kevin
ps: I love to have the FOM or some FAQ telling how to edit config/registry to get debugger to start in same terminal or separate window though. And Lawson's sgml thingy needs to be there as well :-)
Hello everybody :),
Could you send me a list of the popular apps what you have been able to install+run more or less flawless (using only builtin dlls)???
o Name of the app. o Version. o URL, if it can be free downloaded.
* popular apps: Applications used by a large number of people in * multiples countries :) * install+run flawless
Thanks, Regards, Carlos.
--- Carlos Lozano clozano@andago.com wrote:
Hello everybody :),
Could you send me a list of the popular apps what you have been able to install+run more or less flawless (using only builtin dlls)???
o Name of the app. o Version. o URL, if it can be free downloaded.
- popular apps: Applications used by a large number of people in
- multiples
countries :)
- install+run flawless
Thanks, Regards, Carlos.
Does this include games too?
__________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
On November 1, 2002 07:37 am, Dustin Navea wrote:
Does this include games too?
I would say yes, most def.
Here are a few programs I've used in the last few days that are near enough to flawless with only builtins:
App-wise: mIRC 6.2 - www.mirc.co.uk IDA Pro 4.2.1 Demo - ftp://ftp.po.cs.msu.su/pub/ida/demo421.zip E-Tax (Australian Electronic Tax software, needs Desktop mode :/)
Game-wise: Jazz Jackrabbit 2 Fallout
- James 'Ender' Brown Project Leader, ScummVM: http://www.scummvm.org/ Founder, QuakeSRC: http://www.quakesrc.org/ Lead Programmer, www.collectivedetective.org
On Fri, 1 Nov 2002, Carlos Lozano wrote:
Date: Fri, 1 Nov 2002 12:19:22 +0100 From: Carlos Lozano clozano@andago.com To: wine-devel@winehq.com Subject: Re: Wine 0.8 TODO v0.1 + help request :)
Hello everybody :),
Could you send me a list of the popular apps what you have been able to install+run more or less flawless (using only builtin dlls)???
o Name of the app. o Version. o URL, if it can be free downloaded.
- popular apps: Applications used by a large number of people in
- multiples
countries :)
- install+run flawless
Thanks, Regards, Carlos.
-- ___ _ \ | / Infraestructuras | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . __ GNU/Linux |_|_||_|_|___|<___|_. |___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/__ \ > < -_) [ carlos.lozano@andago.com ]___|_| ____/ _/____| [ calb@epsxe.com ] http://www.epsxe.com
On Fri, 1 Nov 2002, Ender wrote:
Game-wise: Jazz Jackrabbit 2 Fallout
Neverwinter Nights Grand Prix Legends
"Dimitrie O. Paun" dpaun@rogers.com writes:
Well, the init directive stuff is not really mandatory for the goals of 0.8. I just put it here since you said you're working on some linker hacks to get this working before we have proper DLL separation.
Actually the linker hacks have to be on top of the dll separation. But it could be possible to do them for already separated dlls so that we can get rid of init everywhere except in kernel/ntdll. I'll try that.
On November 1, 2002 01:39 pm, Alexandre Julliard wrote:
Actually the linker hacks have to be on top of the dll separation. But it could be possible to do them for already separated dlls so that we can get rid of init everywhere except in kernel/ntdll. I'll try that.
Well, maybe the "dll separation" term is overloaded. One way to understand it is that DLLs export all their external functions through the .spec file. And yes, we are not that far away from doing that. What I was referring to is the elimination of the internal functions exported in .spec files.
So for example, in the first interpretation, USER is separated, but in the second, it's not, because of these:
################################################################ # Wine extensions: Win16 functions that are needed by other dlls # @ stdcall CallWindowProc16(long long long long long) CallWindowProc16 @ stdcall CloseDriver16(long long long) CloseDriver16 @ stdcall CreateDialogIndirectParam16(long ptr long long long) CreateDialogIndirectParam16 @ stdcall DefDriverProc16(long long long long long) DefDriverProc16 @ stdcall DestroyIcon32(long long) DestroyIcon32 @ stdcall DialogBoxIndirectParam16(long long long long long) DialogBoxIndirectParam16 @ stdcall GetDriverModuleHandle16(long) GetDriverModuleHandle16 @ stdcall OpenDriver16(str str long) OpenDriver16 @ stdcall PostAppMessage16(long long long long) PostAppMessage16 @ stdcall SendDriverMessage16(long long long long) SendDriverMessage16 @ stdcall UserYield16() UserYield16
################################################################ # Wine dll separation hacks, these will go away, don't use them # @ cdecl CLIPBOARD_DeleteRecord(ptr long) CLIPBOARD_DeleteRecord @ cdecl CLIPBOARD_EmptyCache(long) CLIPBOARD_EmptyCache @ cdecl CLIPBOARD_GetFormatName(long ptr long) CLIPBOARD_GetFormatName @ cdecl CLIPBOARD_IsPresent(long) CLIPBOARD_IsPresent @ cdecl CLIPBOARD_LookupFormat(long) CLIPBOARD_LookupFormat @ cdecl CLIPBOARD_ReleaseOwner() CLIPBOARD_ReleaseOwner @ cdecl DCE_InvalidateDCE(long ptr) DCE_InvalidateDCE @ cdecl HOOK_CallHooksA(long long long long) HOOK_CallHooksA @ cdecl HOOK_CallHooksW(long long long long) HOOK_CallHooksW @ cdecl HOOK_IsHooked(long) HOOK_IsHooked @ cdecl NC_GetInsideRect(long ptr) NC_GetInsideRect @ cdecl NC_HandleNCHitTest(long long long) NC_HandleNCHitTest @ cdecl NC_HandleSetCursor(long long long) NC_HandleSetCursor @ cdecl USER_Unlock() USER_Unlock @ cdecl WINPOS_ActivateOtherWindow(long) WINPOS_ActivateOtherWindow @ cdecl WINPOS_GetMinMaxInfo(long ptr ptr ptr ptr) WINPOS_GetMinMaxInfo @ cdecl WINPOS_ShowIconTitle(long long) WINPOS_ShowIconTitle @ cdecl WIN_FindWndPtr(long) WIN_FindWndPtr @ cdecl WIN_GetPtr(long) WIN_GetPtr @ cdecl WIN_Handle32(long) WIN_Handle32 @ cdecl WIN_LinkWindow(long long long) WIN_LinkWindow @ cdecl WIN_ListChildren(long) WIN_ListChildren @ cdecl WIN_ListParents(long) WIN_ListParents @ cdecl WIN_ReleaseWndPtr(ptr) WIN_ReleaseWndPtr @ cdecl WIN_RestoreWndsLock(long) WIN_RestoreWndsLock @ cdecl WIN_SetExStyle(long long) WIN_SetExStyle @ cdecl WIN_SetRectangles(long ptr ptr) WIN_SetRectangles @ cdecl WIN_SetStyle(long long) WIN_SetStyle @ cdecl WIN_SuspendWndsLock() WIN_SuspendWndsLock @ cdecl WIN_UnlinkWindow(long) WIN_UnlinkWindow
Anyhow, having the init stuff eliminated from all but ntdll/kernel would be ubercool, thank you! If you do it, maybe you should add a "Temporary hack, we'll go away soon" comment for those 2 inits left, so that people know it's not a feature, and don't use it in their apps.
"Dimitrie O. Paun" dpaun@rogers.com writes:
Well, maybe the "dll separation" term is overloaded. One way to understand it is that DLLs export all their external functions through the .spec file. And yes, we are not that far away from doing that. What I was referring to is the elimination of the internal functions exported in .spec files.
True, the term is overloaded; let's call them phase 1 and phase 2. IMO phase 1 is mandatory for 0.9 (and we are pretty close to it); phase 2 should be well under way for 0.9, but doesn't necessarily need to be 100% done, as long as we can fix the remaining ones for 1.0 without having to redesign everything.
Anyhow, having the init stuff eliminated from all but ntdll/kernel would be ubercool, thank you! If you do it, maybe you should add a "Temporary hack, we'll go away soon" comment for those 2 inits left, so that people know it's not a feature, and don't use it in their apps.
Well, I think it is a feature, you need to be able to specify an init function. Only it will default to DllMain so in 99% of the cases you won't have to know about it.
On November 1, 2002 04:51 pm, Alexandre Julliard wrote:
True, the term is overloaded; let's call them phase 1 and phase 2. IMO phase 1 is mandatory for 0.9 (and we are pretty close to it); phase 2 should be well under way for 0.9, but doesn't necessarily need to be 100% done, as long as we can fix the remaining ones for 1.0 without having to redesign everything.
OK, the reason I was proposing 0.8 as a separate release from 0.9 is that I though 0.9 entails completion of phase 2.
Well, I think it is a feature, you need to be able to specify an init function. Only it will default to DllMain so in 99% of the cases you won't have to know about it.
Well, true, but we can make it a command line argument, just like we did with the other out-of-band .spec directives. Sorry, I was not clear.
On Thu, Oct 31, 2002 at 05:38:10PM -0500, Dimitrie O. Paun wrote:
- Enlist some 'official' distribution maintainers (at the minimum RedHat, Suse, UnitedLinux, Debian)
Add Mandrake, remove UnitedLinux: UnitedLinux is a SERVER distro (or, to be more precise: the core of several server distros).
Ciao Jörg -- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
On Thu, 31 Oct 2002, Dimitrie O. Paun wrote: [...]
A. WineHQ work 0. Reorganize a bit the navigational menu
- Add a screenshot link to the homepage
See also my other email...
- Create some really sexy screenshots
Advice on screenshots: - if the screenshot is just about one application then only that application window should be in the screenshot rather than the whole desktop. - do not try to cram 15 different applications in the screenshot. A lot of screenshots I see look like a mess and that's not good. - try to avoid JPGs as they produce artifacts on text. Use PNG instead. Unless you have photos in the screenshot, you can even convert to 256 colors with no loss of quality if you use 'Positioned Color Dithering' in Gimp (reduces image size significantly).
- Rework the FAQ interface (static HTML, a la http://www.dvddemystified.com/dvdfaq.html, all on one page, with a clickable question list at the top)
- Enlist some 'official' distribution maintainers (at the minimum RedHat, Suse, UnitedLinux, Debian)
Agreed.
- Create nice page with apps that run virtually flawless They should not require MS dlls, tricks, etc. to run Small explanation, screeshot, optional link to download page, such as Tucows.
I suggest that this should be dynamically generated from the Application database by looking for applications rated 5 in no-windows mode. And it is the task of application database mantainers and application owners to control these applications and forcefully downgrade applications that incorrectly received a 5 rating.
There's still a risk of problem if too many applications receive and deserve 5 rating, but is that the case?
On October 31, 2002 07:12 pm, Francois Gouget wrote:
I suggest that this should be dynamically generated from the Application database by looking for applications rated 5 in no-windows mode.
I don't like automatically generated pages like the above. They don't have the "human touch" that make them nice. We could invent an automatically generated status page, but it will not be as nice as the one we have. The 'automatic' bit is cool geek-wise, but it almost always sucks.
What we need is a nicely done page with 10-15 apps ("Cream of the crop") with links, screenshots, etc., and at the end something like: "For a comprehensive list of apps, go here".
Same goes for the 0/9 & 1.0 TODOs. Pointing people to a list of Bugzilla bugs sucks big rocks. It's Not Nice (TM). We can not do nice colors as in the status page, etc. And it shows.
Dimitrie O. Paun wrote:
This is the initial TODO for Wine 0.8.
I know, 0.8 has been released before, but that's ancient history. Whether or not it gets released with this version number is irrelevant. In fact, even if it never becomes a public release, it is an important point to reach toward 0.9, and so if we complete this work, it would have solved its purpose.
Hello Dimi, List
This is exact same question that I brought up when I did the TODO's update on the status page :) I ask if TODO's should be .9/1.0 ToDo's ??? Or just ToDo's in general. Maybe after all this is hashed out I can go back and re-do the todo's section of the status page.....
0.8.0 ToDo's
0.9.0 ToDo's
1.0.0 ToDo's
That is what I wanted to do ... but wanting and doing is two very differant things.. First off I am very new to Wine my self and I just jumped in and and started with status page updates. Why ?? Because I think if a new user comes and looks at the frontpage and then ( what is Wine? ) then ohh shit there is a status page :) :) Then they look and it has not been updated in a YEAR !!! Then they have NO Freaken IDEA about the current status of Wine .... So I ask Alexandre if he would update it :) And I recieved a nice reply .. I would like for someone to volinteer to do this .. And here I am ...
Is the Status page up to date ?? @#*% NO ... I need to add in alot of missing parts.. dlls/shlwapi is a good example Marcus Meissner as worker for : ole32, oleaut32. Jukka Heinonen as worker on WineDos I have not made one single change to the Status of any of the Documentation !!
Then in the future if ** YOU** make a change to comctl32/listview and if you feel the status has went from say 5% to 10% -- ( the Status page goes in 5% increments.. ) And at the same time you have done some work on the DOC's .. All you need to do is send me a message and say ..... Hey, comctl32 is now --% and the DOC status is now whatever .. And ill update it ! and reflect the change in the Change Log.
The way it is now I Search around for who is working on what .. And then PESTER the info out of them ;) I don't like doing it this way. But it is the only way I have at this time.
I just want to say thanks to everyone who replied and gave Feed Back ( it really helps ) And since im new here I can't just make %% up off the top of my head and wait for someone to say .. What the HELL that is not 85% its more like 60% then change it to what it really is .. Tho it did think about it a time or two :)
Thomas Wickline
On Friday 01 November 2002 01:42 am, Thomas Wickline wrote:
The way it is now I Search around for who is working on what .. And then PESTER the info out of them ;) I don't like doing it this way. But it is the only way I have at this time.
Actually, this sounds like the only universally effective approach. No matter how well you encourage us, or how easy you make it for us, some devs will just forget or not care until someone approaches them personally and says "so how should this affect the status?"
It may be pestering, but, hey, nobody put a gun to these people's heads and forced them to contribute to wine (except Alexandre, who I am beginning to think is a POW at CodeWeavers, and may have Viet Kong tormentors who make him play Russian roulette for each unmerged patch ("what part of 'diddy mau' didn't you understand?"))
and forced them to contribute to wine (except Alexandre, who I am beginning to think is a POW at CodeWeavers, and may have Viet Kong tormentors who make him play Russian roulette for each unmerged patch ("what part of 'diddy mau' didn't you understand?"))
Drat! Our secret is out. Jon, we need to move the location of the secret slave camp; the natives are starting to get suspicious.
Alexandre, don't get any ideas, you remember what happened the last time you tried to escape, and if you thought last time was bad, well this time we'll be bringing out the boxes of Windows XP... <g>
Jer
In responding to Dimi's call for better binary packaging, and the whole issue of getting a base line config ready, it felt clear to me that WineSetupTk is a tool that is underutilized.
I have been trying to persuade Alexandre to include WineSetupTk in the main Wine distribution for some time now, and have always failed. (Alexandre is rightly concerned about increasing the dependencies in Wine).
However, it struck me that we ought to be able to do a better job of making it available to binary packagers so that it could be included in more packages. We could also make it easier for people to get both Wine and WineSetupTk from source.
To that end, I have the following proposal, and I wanted to see what folks here thought.
We would create a parallel CVS tree to Wine; say the winesetuptk tree. We'd put that code out under a dual license (GPL/but we still own rights). I'd probably welcome multiple maintainers.
The only thorny issue is that we share code between WineSetupTk and some of our proprietary pieces. We could shift our main WineSetupTk development to this tree, and share the common bits, including our developments as we make them. However, in exchange, we would need anyone making changes to WineSetupTk to grant us a license to use their changes in our proprietary stuff. (And, of course, if we ever abuse this, someone can take the GPL tree and go host it somewhere else).
Thoughts? Comments?
On Friday 01 November 2002 11:35 am, Jeremy White wrote:
In responding to Dimi's call for better binary packaging, and the whole issue of getting a base line config ready, it felt clear to me that WineSetupTk is a tool that is underutilized.
probably. any tool that can read in a config file, make significant changes, and spit them back out without pulverizing is a decent accomplishment, and inclusion in wine would certainly encourage further development of the features, and default config, provided by the tool itself.
Right off the bat, one thing comes to mind that could make things a lot nicer in the wine universe: instead of the wine invocation wrapper script just copying stuff from /etc (or wherever) for new users, it could optionally invoke WineSetupTk. This would give windows converts a warm-fuzzy feeling, I bet.
I have been trying to persuade Alexandre to include WineSetupTk in the main Wine distribution for some time now, and have always failed. (Alexandre is rightly concerned about increasing the dependencies in Wine).
OK, how about a conditional dependency? The linux kernel certainly hasn't fallen into disuse due to the "xsetup" feature. Certainly examples of the neccesary autoconf magic to detect and use itcl/tcl/tk are easily found.
We would create a parallel CVS tree to Wine; say the winesetuptk tree. We'd put that code out under a dual license (GPL/but we still own rights). I'd probably welcome multiple maintainers.
I'm new around here, so I am happy to defer to the judgement of more wizened folks on this issue; but doesn't wine have enough code-forks already?
The only thorny issue is that we share code between WineSetupTk and some of our proprietary pieces. We could shift our main WineSetupTk development to this tree, and share the common bits, including our developments as we make them. However, in exchange, we would need anyone making changes to WineSetupTk to grant us a license to use their changes in our proprietary stuff. (And, of course, if we ever abuse this, someone can take the GPL tree and go host it somewhere else).
hmmm... well this is all up to you of course. I took a look at the license included with WineSetupTk, and it looks pretty darn liberal to me, so I kind of feel like I'm missing your point...?
On November 1, 2002 12:35 pm, Jeremy White wrote:
We would create a parallel CVS tree to Wine; say the winesetuptk tree. We'd put that code out under a dual license (GPL/but we still own rights). I'd probably welcome multiple maintainers.
First off, thanks for the offer -- it's generous, and very useful IMO. It certainly sounds interesting, and I would like to take a peak at the code. The big problem I have with WineSetupTk it's that it's written in Tcl/Tk (I suppose). I don't know the language, and I don't care to learn it. Moreover, I think Wine should use itself for such tools, so we get to use all the nice controls we have <g>. One thing that I'd like to see is a programs/winesetup utility that's based on WineSetupTk, but it's written in C, with the Win32 API & Controls.
Again, this may be a pipedream, I don't know how much effort it would entail, but it's certainly something to think about. It's a nice project for someone familiar with the Win32 API, and little knowledge of Linux (if any) is required, so maybe someone will set up to the task (hint, hint :)).
Now it's my turn: comments? flames? :)
Jeremy White wrote:
Okay, we have a backup FAQ volunteer. Who will be our primary?
Hello,
I will volinteer to *help* on this.. So you now have two people on the backup side.. I really thought this was over my head and there would be very little that I could do.. But I will show one example: http://www.winehq.org/fom-meta/cache/670.html
---------------------
Wine currently supports Win32/Win9x (Win95, 98, ME) and Win16 (Win3.1, 3.0, 2.x) best. Win32/NT (NT 3.x, NT 4, Win2K, Win XP) support is more problematic, as fewer programs need that and as the NT API is often undocumented. That being said, Wine can currently return all Windows versions (and even some more !) given above to programs if you tell it which version value to return by --winver xxx.
---------------------
This needs a append as --winver has been taken out and....
[Version] "Windows" = "winXX"
needs to be edited in the config.
I can do what I know and if im not 85% sure i can always ask someone.
So Status page updates and helper on FAQ should keep me busy for a while :)
Tom
A certain path to fame, fortune, and a lot of thankless work .
Jer
Jeremy White wrote: Okay, we have a backup FAQ volunteer. Who will be our primary?
It's always easier to criticize, than to do. If you do something, you're bound to make mistakes. If you never do anything, you can rest assured that you're not a fault. So, to get a taste of my own medicine, I will coordinate the FAQ work, if people are OK with it. Give everybody a chance to flame me to a smoldering bit. ;)
On Sat, Nov 02, 2002 at 11:01:48AM -0500, Dimitrie O. Paun wrote:
Jeremy White wrote: Okay, we have a backup FAQ volunteer. Who will be our primary?
It's always easier to criticize, than to do. If you do something, you're bound to make mistakes. If you never do anything, you can rest assured that you're not a fault. So, to get a taste of my own medicine, I will coordinate the FAQ work, if people are OK with it. Give everybody a chance to flame me to a smoldering bit. ;)
Sounds damn good to me.
So again, the idea was that the FAQ part should get converted into SGML source for easy conversion etc.
Awesome! Okay, Dimi, you are in charge.
You've got Keith and Tom to help you out.
We have a request from Jer for SGML; my guess is that if you can get the SGML together, he can simply include it inside a clean looking web site.
If you need somewhere to host the result of the generated SGML, I'm sure we can find somewhere on winehq.com for you to hang it.
Cheers,
Jer
On Sat, 2002-11-02 at 10:01, Dimitrie O. Paun wrote:
Jeremy White wrote: Okay, we have a backup FAQ volunteer. Who will be our primary?
It's always easier to criticize, than to do. If you do something, you're bound to make mistakes. If you never do anything, you can rest assured that you're not a fault. So, to get a taste of my own medicine, I will coordinate the FAQ work, if people are OK with it. Give everybody a chance to flame me to a smoldering bit. ;)
-- Dimi.
On November 2, 2002 02:47 pm, Jeremy White wrote:
Awesome! Okay, Dimi, you are in charge.
Cool! I take this seriously, you know... :)
We have a request from Jer for SGML; my guess is that if you can get the SGML together, he can simply include it inside a clean looking web site.
Sorry, the SGML will come later. 99.9% of people don't care about anything than HTML, so that gets priority. As I said, SGML is cool (in a geeky way), but completely non-essential for the FAQ. It can wait a few days.
Dimitrie O. Paun wrote:
Jeremy White wrote: Okay, we have a backup FAQ volunteer. Who will be our primary?
It's always easier to criticize, than to do. If you do something, you're bound to make mistakes. If you never do anything, you can rest assured that you're not a fault. So, to get a taste of my own medicine, I will coordinate the FAQ work, if people are OK with it. Give everybody a chance to flame me to a smoldering bit. ;)
Your on !!!!!!!!!!! When your ready just let me know and we will go at it .. send me a list of things to start on..
Im off from work sun, mon, tue, wen
So lets get started :)
Tom
On November 2, 2002 12:27 pm, Thomas Wickline wrote:
When your ready just let me know and we will go at it .. send me a list of things to start on..
OK, here's the TODO:
1. Extract the FAQ from the FAQ-O-Matic This means also deleting it from there, to avoid duplication, and confusion. We need to: i. Separate the FAQ from troubleshooting ii. Delete stuff from FAQ-O-Matic Andy, how can we do that?
2. Come up with a stylesheet based on the DVD FAQ http://www.dvddemystified.com/dvdfaq.html that's more in the spirit of WineHQ
3. Format the extracted FAQ, and put it on the site
4. Work on getting the SGML tools to do what we want, so we can write the FAQ in XML, like so:
<faq> <entry> <question>What is this for?</question> <answer>Nothing in particular, it's just cool.</answer> </entry> </faq>
But this should be done later, after we post the new FAQ on the site.
On Sat, Nov 02, 2002 at 11:47:43AM -0500, Dimitrie O. Paun wrote:
On November 2, 2002 12:27 pm, Thomas Wickline wrote:
When your ready just let me know and we will go at it .. send me a list of things to start on..
OK, here's the TODO:
- Extract the FAQ from the FAQ-O-Matic
This means also deleting it from there, to avoid duplication, and confusion. We need to: i. Separate the FAQ from troubleshooting ii. Delete stuff from FAQ-O-Matic Andy, how can we do that?
Hmm, no idea :-) You should ask Newman to grant you access in case a normal user account on the FOM isn't able to delete the FAQ part. I'd have no trouble whatsoever deleting the FAQ part, though, so I could easily do this myself ;)
Come up with a stylesheet based on the DVD FAQ http://www.dvddemystified.com/dvdfaq.html that's more in the spirit of WineHQ
Format the extracted FAQ, and put it on the site
Work on getting the SGML tools to do what we want, so we can write the FAQ in XML, like so:
<faq> <entry> <question>What is this for?</question> <answer>Nothing in particular, it's just cool.</answer> </entry> </faq>
Ah, that sounds cool indeed !
On November 2, 2002 12:20 pm, Andreas Mohr wrote:
- Work on getting the SGML tools to do what we want, so we can write the FAQ in XML, like so:
<faq> <entry> <question>What is this for?</question> <answer>Nothing in particular, it's just cool.</answer> </entry> </faq>
Ah, that sounds cool indeed !
BTW, I don't have much experience with SGML tools, anyone interested in looking into this?
On November 2, 2002 12:20 pm, Andreas Mohr wrote:
Hmm, no idea :-) You should ask Newman to grant you access in case a normal user account on the FOM isn't able to delete the FAQ part. I'd have no trouble whatsoever deleting the FAQ part, though, so I could easily do this myself ;)
OK, first let me extract the content, then you can help us delete from the FOM.
On Sat, 2 Nov 2002, Dimitrie O. Paun wrote: [...]
- Work on getting the SGML tools to do what we want, so we can write the FAQ in XML, like so:
<faq> <entry> <question>What is this for?</question> <answer>Nothing in particular, it's just cool.</answer> </entry> </faq>
DocBook is the way to go there. It's already what we use for the Wine documentation and it has tags for writing FAQs. See the URL below for the reference of all the DocBook tags:
DocBook: The Definitive Guide http://www.docbook.org/tdg/en/html/docbook-x.html
Here is the basic structure for FAQs. It's pretty simple. I think the example below should be 99% of what you need to write the whole FAQ. You can look up the tags in the above doc for more details. And you can also ask me if needed (not that I'm a great DocBook specialist but having worked on the CrossOver FAQs...)
<qandaset>
<qandadiv><title>Installation</> <!-- Put all installation related questions in this section -->
<qandaentry> <question id="download"> <para> Where can I download Wine from? </para> </question> <answer> <para> You can get it from <ulink url="http://www.winehq.com">WineHQ</> blah, blah, ... </para> </answer> </qandaentry>
<qandaentry> <question id="will_be_an_html_a_name"> <para> What is question 2? </para> </question> <answer> <para> This is answer 2. </para> <para> More paragraphs. </para> </answer> </qandaentry> ...
</qandadiv>
<qandadiv><title>Configuration</> <!-- Put all configuration related questions in this section --> ... </qandadiv>
<qandadiv><title>Whatever...</> ... </qandadiv>
...
</qandaset>
Francois Gouget wrote:
On Sat, 2 Nov 2002, Dimitrie O. Paun wrote: [...]
- Work on getting the SGML tools to do what we
want, so we can write the FAQ in XML, like so:
<faq> <entry> <question>What is this for?</question> <answer>Nothing in particular, it's just cool.</answer> </entry> </faq>
DocBook is the way to go there. It's already what we use for the Wine documentation and it has tags for writing FAQs. See the URL below for the reference of all the DocBook tags:
DocBook: The Definitive Guide http://www.docbook.org/tdg/en/html/docbook-x.html
Here is the basic structure for FAQs. It's pretty simple. I think the example below should be 99% of what you need to write the whole FAQ. You can look up the tags in the above doc for more details. And you can also ask me if needed (not that I'm a great DocBook specialist but having worked on the CrossOver FAQs...)
<qandaset>
<qandadiv><title>Installation</>
<!-- Put all installation related questions in this section -->
<qandaentry> <question id="download"> <para> Where can I download Wine from? </para> </question> <answer> <para> You can get it from <ulink url="http://www.winehq.com">WineHQ</> blah, blah, ... </para> </answer> </qandaentry>
<qandaentry> <question id="will_be_an_html_a_name"> <para> What is question 2? </para> </question> <answer> <para> This is answer 2. </para> <para> More paragraphs. </para> </answer> </qandaentry> ...
</qandadiv>
<qandadiv><title>Configuration</>
<!-- Put all configuration related questions in this section -->
...
</qandadiv>
<qandadiv><title>Whatever...</> ...
</qandadiv>
...
</qandaset>
Perfect This is exactly what I was looking for...
Tony Lambregts
Dimitrie O. Paun wrote:
On October 31, 2002 06:02 pm, Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes:
What is NOT in 0.8: -- stable server protocol: no binary compatibility -- DLL separation: ditto
IMO the goals for 0.9 will be reached before the ones for 0.8 so you might as well put everything together...
Maybe so, you know this better. But 0.9 needs what's listed here anyhow, if we hit the 0.9 targets before, no harm's done. I am not that optimistic about the DLL separation. The x11drv is a bit of a mess, as we have a WND structure maintained by USER, which x11drv needs access to. It needs work. And in general, the separation work that's left is not trivial, and you seem to be the only one qualified to do it. And you are one busy guy...
Does anyone have any info on what needs to be done to separate out the WND structure from USER? Is there any other stuff that should be separated out into x11drv? Presumably even if the separation isn't trivial some pointers could enable others to give it a try...
David
-
Alexandre Julliard -
Andreas Mohr -
Brad Campbell -
Carlos Lozano -
Christoph Frick -
David Fraser -
Dimitrie O. Paun -
Dustin Navea -
Ender -
Francois Gouget -
Greg Turner -
Jaco Greeff -
Jeremy Newman -
Jeremy White -
Joerg Mayer -
Justin -
Lionel Ulmer -
Thomas Wickline -
Tony Lambregts