December 2004 - Wine-Devel - list.winehq.org

Re: <<PATCH>> Added shell32.dll functions to browse for unix directory;

by Robert van Herk

Rolf Kalbermatter wrote: >Robert van Herk wrote: > > > >>-LPITEMIDLIST WINAPI SHBrowseForFolderA (LPBROWSEINFOA lpbi) >>+static INT_PTR BrowseW (LPBROWSEINFOW lpbi, DLGPROC dlgproc, enum browsemode aBrowseMode) >>+{ >>+ INT_PTR ret; >>+ >>+ browseMode = aBrowseMode; >> >> > ^^^^^^^^^^ > >I may miss something here but this looks like a global variable and that would make >these function theoretically thread unsafe. As long as only winecfg is going to use >this functionality for the unix case it seems not a problem as there is probably not >any chance that the native Windows version is called at that moment but this may of >course change in the future. > > I guess you are right, but the strange thing is that this was already the case in the original code. The hwnd of the tree view and the pointer to the browseinfo structure are copied into a global variable, so at least my code is not worse here :-). By the way, isn't it so that a copy of shell32.dll gets loaded for each application anyway? If so, then the variable is at least application local, and, c'mon, who is going to show two modal browsing dialog boxes at the same time :-)? Robert

Dec. 1, 2004

Re: <<PATCH>> Added shell32.dll functions to browse for unix directory;

by Rolf Kalbermatter

Robert van Herk wrote: >-LPITEMIDLIST WINAPI SHBrowseForFolderA (LPBROWSEINFOA lpbi) >+static INT_PTR BrowseW (LPBROWSEINFOW lpbi, DLGPROC dlgproc, enum browsemode aBrowseMode) >+{ >+ INT_PTR ret; >+ >+ browseMode = aBrowseMode; ^^^^^^^^^^ I may miss something here but this looks like a global variable and that would make these function theoretically thread unsafe. As long as only winecfg is going to use this functionality for the unix case it seems not a problem as there is probably not any chance that the native Windows version is called at that moment but this may of course change in the future. Rolf Kalbermatter

Dec. 1, 2004

Re: Winecfg -> browse for folder

by Robert van Herk

>>+static void prepNextFile(LP_UNIXTOOLS_DIRDATA dirdata) >>+{ >>+ TRACE("hallo\n"); >>+ >> >> > >Well, the patch clearly still needs a bit more work ;) Still, it looks >like it's on the right track. Good going! > > Haha! I am glad there is still a "Hallo" in the code :-). Thanks for your advice Mike. I will change it today or tomorrow. Robert

Dec. 1, 2004

Re: Winecfg -> browse for folder

by Mike Hearn

On Wed, 2004-12-01 at 17:08 +0100, Robert van Herk wrote: > Anyways: I already implemented it (as you perhaps saw) using UNIX api > calls. I think I did OK, though I am not very experienced in neither C > programming or win32. Mike, perhaps you could take a look at my patch? Sure. Here you go. > @@ -46,7 +48,8 @@ > shpolicy.c \ > shv_bg_cmenu.c \ > shv_item_cmenu.c \ > - systray.c > + systray.c \ > + unixTools.c s/unixTools.c/unix_tools.c/ for consistency +/************************************************************************* + * wine_shell_browse_for_UNIX_directory [SHELL32.@] + */ +BOOL WINAPI wine_shell_browse_for_UNIX_directoryA (LPBROWSEINFOA lpbi) +{ + if (!lpbi) + return FALSE; UNIX here should be lower case IMHO, makes it look nicer. Also you want to crash or do an ERR if a wine API is abused like this, silently returning false can lead to hard to find bugs. + + /*For UNIX browsing, pidls are not used. Hence, if the + user passes a pidl that should be root for this browse + anyway, we refuse to show the dialog:*/ Could you put spaces between the comment markers and the text? Also consistent indentation would be good. + /*For UNIX browsing, we always use the pszDiplayName to RETURN + the chosen path in, thus:*/ + if (!lpbi->pszDisplayName) + { + ERR("pszDisplayName must be set for UNIX browsing.\n"); + return FALSE; + } How does this work? Is the pszDisplayName pointing to a preallocated buffer (if so how do you know how big it should be?). +@ stdcall wine_shell_browse_for_UNIX_directory(ptr) wine_shell_browse_for_UNIX_directoryA +@ stdcall wine_shell_browse_for_UNIX_directoryA(ptr) +@ stdcall wine_shell_browse_for_UNIX_directoryW(ptr) Don't bother with a forwarder here, the WINELIB_NAME_AW macro should be sufficient. > C_SRCS = \ > appdefaults.c \ > @@ -16,7 +16,7 @@ > main.c \ > properties.c \ > winecfg.c \ > - x11drvdlg.c > + x11drvdlg.c \ That looks wrong, a \ is only needed when there's something on the next line. > + bi->hwndOwner = dialog; > + bi->pszDisplayName = HeapAlloc(GetProcessHeap(), 0, MAX_PATH); > + bi->lpszTitle = "Please choose a directory"; /*FIXME: Get this multilingual*/ Oh, I see. This is a rather unintuitive API design, why not simply return the path or have a char ** out parameter instead of setting the input structure? > + if ((dirp=readdir(dirdata->dp))!=NULL) { > + /* We are done, if we found an entry of the correct type: */ > + if (strcmp(dirp->d_name, ".") == 0) continue; /*Ignore "." */ > + if (strcmp(dirp->d_name, "..") == 0) continue; /*Ignore ".." */ Excellent! I was wondering if you'd make the mistake of assuming . and .. were the first two elements in the list, good to see you didn't. By the way, same comments as with Aneurin, could you please space things out rather than jamming it all together, eg if ((dirp = readdir(dirdata->dp) != NULL) > +static void prepNextFile(LP_UNIXTOOLS_DIRDATA dirdata) > +{ > + TRACE("hallo\n"); > + Well, the patch clearly still needs a bit more work ;) Still, it looks like it's on the right track. Good going! thanks -mike

Dec. 1, 2004

Re: Bug Busters

by tony_lambregts＠telusplanet.net

Robert van Herk wrote: > Also, I am getting the strange feeling that the buglist is somewhat > outdated :-). For example: almost all bugs are either NEW or > UNCONFIRMED. Isn't that a bit odd? > It's just that way right now. The way Bugzilla was designed there is supposed to be a default person for each component. typically a bug would be "Assigned" to the owner of that component. The way we use Bugzilla does not work that way. There are a few times that a person will volunteer to take on a bug and Assign it to themselves. Right now we live with the fact that "New" means "Confirmed". Once our copy of Bugzilla is CVS's I plan to fix this (and other things). -- Tony Lambregts

Dec. 1, 2004

Re: Bug Busters

by James Hawkins

On Wed, 01 Dec 2004 17:42:26 +0000, Mike Hearn <mh(a)codeweavers.com> wrote: > On Wed, 2004-12-01 at 12:27 -0500, James Hawkins wrote: > > > So that the most potential developers will be able to join, let's have > > > the session this Friday Dec. 3, 7pm GMT. Is that a good time for > > I think Sunday would be a better day of the week. Friday/Saturday nights > people tend to go out on (I know I'll probably be out this Friday). > > haha you're right. I was hesitant about having it on the weekends, but if people would like Sunday better than Sunday it is. Same time of the day and place. This will give us more time to get the word out too. -- James Hawkins

Dec. 1, 2004

Re: Bug Busters

by Mike Hearn

On Wed, 2004-12-01 at 12:27 -0500, James Hawkins wrote: > > So that the most potential developers will be able to join, let's have > > the session this Friday Dec. 3, 7pm GMT. Is that a good time for I think Sunday would be a better day of the week. Friday/Saturday nights people tend to go out on (I know I'll probably be out this Friday).

Dec. 1, 2004

Re: Bug Busters

by James Hawkins

On Wed, 1 Dec 2004 12:25:38 -0500, James Hawkins <truiken(a)gmail.com> wrote: > On Wed, 01 Dec 2004 17:04:49 +0000, Mike Hearn <mh(a)codeweavers.com> wrote: > > > > On Wed, 2004-12-01 at 11:52 -0500, James Hawkins wrote: > > > What time is best for everyone? Also is once a week too much or not > > > enough? > > > > I think as long as both USians and Europeans can be awake at the same > > time, it should be that sort of time. So evening GMT. Before saying > > "let's do it once a week" it makes sense to just do it once and gauge > > interest. If there aren't really that many potential hackers wanting > > help then I'd be pretty demotivated quickly (as pointed out, I'm not so > > keen on just random untargetted bugfixing) > > > > > > So that the most potential developers will be able to join, let's have > the session this Friday Dec. 3, 7pm GMT. Is that a good time for > anyone interested or should we push it back a week? Also get the word > out to anyone that possibly doesn't read this list but that you know > would like to get started with developing wine. The more we have show > up, the more future developers we can get on the project (plus more > squashing power :) > > -- > James Hawkins > I forgot to mention that we'll meet on #winehackers on IRC. If you have any questions about logging on, let us know. -- James Hawkins

Dec. 1, 2004

Re: Bug Busters

by James Hawkins

On Wed, 01 Dec 2004 17:04:49 +0000, Mike Hearn <mh(a)codeweavers.com> wrote: > On Wed, 2004-12-01 at 11:52 -0500, James Hawkins wrote: > > What time is best for everyone? Also is once a week too much or not > > enough? > > I think as long as both USians and Europeans can be awake at the same > time, it should be that sort of time. So evening GMT. Before saying > "let's do it once a week" it makes sense to just do it once and gauge > interest. If there aren't really that many potential hackers wanting > help then I'd be pretty demotivated quickly (as pointed out, I'm not so > keen on just random untargetted bugfixing) > > So that the most potential developers will be able to join, let's have the session this Friday Dec. 3, 7pm GMT. Is that a good time for anyone interested or should we push it back a week? Also get the word out to anyone that possibly doesn't read this list but that you know would like to get started with developing wine. The more we have show up, the more future developers we can get on the project (plus more squashing power :) -- James Hawkins

Dec. 1, 2004

Re: Bug Busters

by Mike Hearn

On Wed, 2004-12-01 at 11:52 -0500, James Hawkins wrote: > What time is best for everyone? Also is once a week too much or not > enough? I think as long as both USians and Europeans can be awake at the same time, it should be that sort of time. So evening GMT. Before saying "let's do it once a week" it makes sense to just do it once and gauge interest. If there aren't really that many potential hackers wanting help then I'd be pretty demotivated quickly (as pointed out, I'm not so keen on just random untargetted bugfixing)

Dec. 1, 2004

Re: Bug Busters

by Mike Hearn

On Wed, 2004-12-01 at 09:24 -0700, tony_lambregts(a)telusplanet.net wrote: > There is nothing wrong with fixing a bug for its own sake and any bug we fix > will ultimately improve wine and provide some insites into debugging > wine. Well, yes if you assume infinite manpower. We don't have that so I'd personally rather spend my time helping budding developers. Debugging random apps users bring into a channel is just asking to be overwhelmed and anyway, I can't really justify the time to do that these days when I could be working on paying customers stuff. Whereas I can justify (to myself at any rate) getting new developers on board who will go on to write bugfixes themselves. thanks -mike

Dec. 1, 2004

Re: which classes support aggregation?

by Robert Shearman

James Hawkins wrote: >IClassFactory->CreateInstance aggregation check: >"The CreateInstance method of IClassFactory takes pUnkOuter as the >second member. This parameter must be null unless the class supports >aggregation, which many don't." > >Where can I find out which classes support aggregation? > > Generally, most classes don't bother with aggregation as it is only something that OLE geeks get excited over. There are a few classes in ole32 that support aggregation and it is specified as so in MSDN. So, unless tests or MSDN say otherwise, just assume that a class doesn't support aggregation. Rob

Dec. 1, 2004

Re: implementing DllCanUnloadNow questions

by Robert Shearman

James Hawkins wrote: >On Tue, 30 Nov 2004 15:34:50 -0600, Robert Shearman <rob(a)codeweavers.com> wrote: > > >>James Hawkins wrote: >> >> >> >>>I would like to work on the DllCanUnloadNow janitorial task, but I was >>>wondering if there are any patches or examples of dll's that correctly >>>implement this so that I can do it right. >>> >>> >>> >>> >>I don't know of any examples so far, but Mike Hearn and I will be >>tackling OLE soon, so that will involve cleaning up ole32. However, that >>probably won't happen until we've done some groundwork on COM first, so >>feel free to beat us to it and make a shining example of a DLL that >>correctly implements DllCanUnloadNow. >> >> >> >> >> >>>Is LockServer(TRUE/FALSE) the same as this example? >>> >>>static HRESULT WINAPI SFCF_LockServer(LPCLASSFACTORY iface,BOOL dolock) { >>> IClassFactoryImpl *This = (IClassFactoryImpl *)iface; >>> FIXME("(%p)->(%d),stub!\n",This,dolock); >>> return S_OK; >>>} >>> >>>If they are the same, what is needed to complete this stub? I would >>>think that there would be a refCount variable that is incremented if >>>dolock is true and decremented if dolock is false. Also, should the >>>LockServer functions be listed in the spec files of the dlls? >>> >>> >>> >>> >>No, the LockServer functions are part of IClassFactory vtables. Only >>DllCanUnloadNow needs to be exported. >> >> >> >>>After implementing LockServer, it should be an easy matter to do a >>>check for refCount == 0 to see if the dll can be unloaded or not. Am >>>I heading in the right direction? >>> >>> >>> >>> >>To implement DllCanUnloadNow properly you need to do the following: >>1. Add a variable "LONG cLocks" and two function for manipulating it: >>void LockModule() >>{ >> InterlockedIncrement(&cLocks); >>} >> >>void UnlockModule() >>{ >> InterlockedDecrement(&cLocks); >>} >>2. Increment cLocks on construction of every heap object: >>static HRESULT Example_Construct(...) >>{ >>... >> LockModule(); >> return S_OK; >>} >>3. Decrement cLocks on destruction of every heap object: >>static ULONG Example_Release(...) >>{ >> ... >> res = InterlockedDecrement(&This->cRefs); >> if (!res) >> { >> /* Free object's resources, including memory, etc. */ >> UnlockModule(); >> } >>} >>4. For non-heap based objects (commonly objects with no state, like >>IClassFactory): >>static ULONG Example_AddRef(...) >>{ >> LockModule(); >> return 2; /* non-heap object */ >>} >> >>static ULONG Example_Release(...) >>{ >> UnlockModule(); >> return 1; >>} >>5. Implement IClassFactory_LockServer's as follows: >>HRESULT WINAPI Example_LockServer(...) >>{ >> if (bLock) >> LockModule(); >> else >> UnlockModule(); >> return S_OK; >>} >>6. Then implement DllCanUnloadNow: >>HRESULT WINAPI DllCanUnloadNow() >>{ >> return cLocks > 0 : S_FALSE : S_OK; >>} >> >>Rob >> >> >> > >Attached is my beginning attempts at adding DllCanUnloadNow to msi. >There are a couple questions I have though. > > > >>static HRESULT Example_Construct(...) >>{ >>... >> LockModule(); >> return S_OK; >>} >> >> > >Is _Construct the same as _AddRef()? I'm thinking it's not. If it >isn't, I need to add a MSI_Construct to msi. What are the parameters >to the Construct function and what would usually go in the place of >the "..."? > > The _Construct function has a similar purpose to the C++ constructor, except that we usually allocate the memory in _Construct as well (whereas the C++ normally compiler does this). The parameters and return value vary according to the situation. If the object has a number of properties that are set up at creation time, then these should be passed to the constructor. >>static ULONG Example_Release(...) >>{ >> ... >> res = InterlockedDecrement(&This->cRefs); >> if (!res) >> { >> /* Free object's resources, including memory, etc. */ >> UnlockModule(); >> } >>} >> >> > > > >>static ULONG Example_Release(...) >>{ >> UnlockModule(); >> return 1; >>} >> >> > >Are these _Release's referring to the same function? If not, what is >the difference? If so, which one should be implemented and what >usually goes in the place of the "..."? > > The difference is that the first one is a heap based object, so it does the ref-counting itself, whereas the second is a non-heap based object where it makes no sense to keep an internal ref-count so UnlockModule is always called (and LockModule is always called in AddRef). >------------------------------------------------------------------------ > >@@ -1567,12 +1570,32 @@ > return S_OK; > } > >+void LockModule() >+{ >+ InterlockedIncrement(&cLocks); >+} >+ >+void UnlockModule() >+{ >+ InterlockedDecrement(&cLocks); >+} >+ >+HRESULT WINAPI MSI_LockServer(LPCLASSFACTORY iface,BOOL bLock) >+{ >+ if (bLock) >+ LockModule(); >+ else >+ UnlockModule(); >+ >+ return S_OK; >+} >+ > > Not quite right. The _LockServer method should be the one included in the IClassFactory implementation's vtable and I don't see this in this patch. Rob

Dec. 1, 2004

Re: Bug Busters

by James Hawkins

On Wed, 01 Dec 2004 14:54:59 +0000, Mike Hearn <mh(a)codeweavers.com> wrote: > On Wed, 01 Dec 2004 01:29:50 -0500, James Hawkins wrote: > > Well, as long as it's at a time I can do without having redeye the next > day I'm happy to drop in and help with this. On choices of bugs: > > I think if this goes ahead, we should advertise this in developer circles > and people who have bugs they'd like to fix, but aren't sure how, can come > in and get some training. IE rather than it being a "service" for end > users, it'd be more about getting people who already know programming and > want to hack on Wine but need help doing so. > I think this sounds like the best way for now. Anyone interested in joining should have in mind any bugs they would like to fix, and we will work on those bugs. Concerning the time of the events, I am living in Pennsylvania right now, 5 hours behind GMT (i think), but I am willing to work at whatever time is best for everyone. What time is best for everyone? Also is once a week too much or not enough? I can do this any day of the week including the weekend, but some might not want to work on the weekends. Let's get some ideas for times so we can bust some bugs :) -- James Hawkins

Dec. 1, 2004

Re: Wine book

by Ira Krakow

Dimi, > > We need a discussion of how to use the std C++ lib. > Thanks. I'll add it to my list. Ira

Dec. 1, 2004

Re: Bug Busters

by tony_lambregts＠telusplanet.net

Mike Hearn wrote: > On Wed, 01 Dec 2004 01:29:50 -0500, James Hawkins wrote: > >> agree that programs should be freely available to anyone if the bug >>requires a program. Some of the bugs don't need them. I also agree >>that the older bugs should be fixed first. We might even find that a >>bunch of bugs we try to fix have already been fixed (it's good to >>clean up bugzilla too). My thought is that we would pick the bugs >>before the sessions so that anyone interested can research the >>problems beforehand and we know what we're going to work on for the >>session. Another option is that we pick the bugs to work on during >>the session. I think both options are convenient and worth >>considering. It's ultimately up to the community though. > > > Well, as long as it's at a time I can do without having redeye the next > day I'm happy to drop in and help with this. On choices of bugs: > > I think if this goes ahead, we should advertise this in developer circles > and people who have bugs they'd like to fix, but aren't sure how, can come > in and get some training. IE rather than it being a "service" for end > users, it'd be more about getting people who already know programming and > want to hack on Wine but need help doing so. > > > There is nothing wrong with fixing a bug for its own sake and any bug we fix will ultimately improve wine and provide some insites into debugging wine. That being said, I would agree that at least to some degree this should be a training execise and that whatever bug(s) we go after, some (budding?) developer would like to have fixed. However there should be a bug report in bugzilla so that developers can research the bug in the first place and we can keep track of what was done for these sessions. I have created a key word "BugBuster" in Bugzilla to keep track of candidates. Hopefully after several sesions we will have a list of fixed bugs that new developers can use as a reference. -- Tony Lambregts

Dec. 1, 2004

Re: Bug Busters

by tony_lambregts＠telusplanet.net

Mike Hearn wrote: > On Wed, 01 Dec 2004 01:29:50 -0500, James Hawkins wrote: > >> agree that programs should be freely available to anyone if the bug >>requires a program. Some of the bugs don't need them. I also agree >>that the older bugs should be fixed first. We might even find that a >>bunch of bugs we try to fix have already been fixed (it's good to >>clean up bugzilla too). My thought is that we would pick the bugs >>before the sessions so that anyone interested can research the >>problems beforehand and we know what we're going to work on for the >>session. Another option is that we pick the bugs to work on during >>the session. I think both options are convenient and worth >>considering. It's ultimately up to the community though. > > > Well, as long as it's at a time I can do without having redeye the next > day I'm happy to drop in and help with this. On choices of bugs: > > I think if this goes ahead, we should advertise this in developer circles > and people who have bugs they'd like to fix, but aren't sure how, can come > in and get some training. IE rather than it being a "service" for end > users, it'd be more about getting people who already know programming and > want to hack on Wine but need help doing so. > > > There is nothing wrong with fixing a bug for its own sake and any bug we fix will ultimately improve wine and provide some insites into debugging wine. That being said, I would agree that at least to some degree this should be a training execise and that whatever bug(s) we go after, some (budding?) developer would like to have fixed. However there should be a bug report in bugzilla so that developers can research the bug in the first place and we can keep track of what was done for these sessions. I have created a key word BugBuster to keep track of candidates. Hopefully after several sesions we will have a list of fixed bugs that new developers can use as a reference. -- Tony Lambregts

Dec. 1, 2004

Re: Winecfg -> browse for folder

by Robert van Herk

Mike Hearn wrote: >On Tue, 30 Nov 2004 22:08:26 +0100, Robert van Herk wrote: > > >>Oops, I guess this suggestion was a bit too late, since I commited my >>patch this afternoon... >> >> > >I wouldn't worry too much. I'm not sure a PIDL extension is a good idea >anyway - it's probably the Microsoft way, but this is a Wine extension API >so we don't have to follow in their footsteps exactly. It would be a >harder to use API if it was PIDL based. > > Exactly. Perhaps a shell namespace extension would be nice though. I don't know what exactly those are, but at least it makes a great buzz word :-). Anyways: I already implemented it (as you perhaps saw) using UNIX api calls. I think I did OK, though I am not very experienced in neither C programming or win32. Mike, perhaps you could take a look at my patch? It is not perfect yet (for example: folder icons are missing in UNIX browsing) but at least people can happily select a UNIX path now from winecfg and that was the main point :-). Regards, Robert

Dec. 1, 2004

Re: Bug Busters

by Jakob Eriksson

Mike Hearn wrote: >On Wed, 01 Dec 2004 01:29:50 -0500, James Hawkins wrote: > > >> agree that programs should be freely available to anyone if the bug >>requires a program. Some of the bugs don't need them. I also agree >>that the older bugs should be fixed first. We might even find that a >>bunch of bugs we try to fix have already been fixed (it's good to >>clean up bugzilla too). My thought is that we would pick the bugs >>before the sessions so that anyone interested can research the >>problems beforehand and we know what we're going to work on for the >>session. Another option is that we pick the bugs to work on during >>the session. I think both options are convenient and worth >>considering. It's ultimately up to the community though. >> >> > >Well, as long as it's at a time I can do without having redeye the next >day I'm happy to drop in and help with this. On choices of bugs: > >I think if this goes ahead, we should advertise this in developer circles >and people who have bugs they'd like to fix, but aren't sure how, can come >in and get some training. IE rather than it being a "service" for end >users, it'd be more about getting people who already know programming and >want to hack on Wine but need help doing so. > > > Maybe we can hack the regression tests too? Many of them bug me to no end, but I haven't got a clue how to fix most of them. (Not once have we had an all green run of winetest.exe.) regards, Jakob

Dec. 1, 2004

Re: Bug Busters

by Robert van Herk

Joel Konkle-Parker wrote: > James Hawkins wrote: > >> I have a totally non-original idea for sessions called Bug Busters >> where, at a designated time, a group of wine developers would get >> together on #winehackers (or some other channel). We would pick a bug >> (or maybe more) from wine's bug tracker and work together to fix the >> bug(s). This would serve several good purposed. First, we would be >> giving more attention to wine's bugzilla and getting rid of a lot of >> those bugs. Second, many newcomers can witness and take part in the >> wine development process. I'm sure everyone can remember how daunting >> it is to jump into wine development. Anyway, if anyone has any ideas >> or would like to take part in this, let me know and we'll get this >> started. > > > Sounds like a great idea. I've been trying to get into Wine > development, but haven't been able to get my foot firmly planted > anywhere. The whole thing is just too complex. I'd gladly join a BB > session, if only to get some insight into how things work. Great idea indeed. I find myself spending much more time reading the bug lists and not understanding how to get started than actually implementing stuff. But this might indeed change that. Problem: we probably will have to deal with multiple time zones (.e.g. I am in Europe) :-). Also, I am getting the strange feeling that the buglist is somewhat outdated :-). For example: almost all bugs are either NEW or UNCONFIRMED. Isn't that a bit odd? Robert

Dec. 1, 2004

Re: Wine book

by Dimitrie O. Paun

On Tue, Nov 30, 2004 at 05:42:31PM -0700, Brian Vincent wrote: > 13. Advanced Porting Techniques [25 pages] > C++ Problems We need a discussion of how to use the std C++ lib. -- Dimi.

Dec. 1, 2004

Re: Bug Busters

by Mike Hearn

On Wed, 01 Dec 2004 01:29:50 -0500, James Hawkins wrote: > agree that programs should be freely available to anyone if the bug > requires a program. Some of the bugs don't need them. I also agree > that the older bugs should be fixed first. We might even find that a > bunch of bugs we try to fix have already been fixed (it's good to > clean up bugzilla too). My thought is that we would pick the bugs > before the sessions so that anyone interested can research the > problems beforehand and we know what we're going to work on for the > session. Another option is that we pick the bugs to work on during > the session. I think both options are convenient and worth > considering. It's ultimately up to the community though. Well, as long as it's at a time I can do without having redeye the next day I'm happy to drop in and help with this. On choices of bugs: I think if this goes ahead, we should advertise this in developer circles and people who have bugs they'd like to fix, but aren't sure how, can come in and get some training. IE rather than it being a "service" for end users, it'd be more about getting people who already know programming and want to hack on Wine but need help doing so.

Dec. 1, 2004

Re: Wine book

by Mike Hearn

On Tue, 30 Nov 2004 17:42:31 -0700, Brian Vincent wrote: > 3. Configuring Wine [35 pages] > Introduction to Winecfg Hah, optimist :)

Dec. 1, 2004

Re: which classes support aggregation?

by Mike Hearn

On Tue, 30 Nov 2004 18:36:37 -0500, James Hawkins wrote: > IClassFactory->CreateInstance aggregation check: > "The CreateInstance method of IClassFactory takes pUnkOuter as the > second member. This parameter must be null unless the class supports > aggregation, which many don't." > > Where can I find out which classes support aggregation? Typically MSDN will tell you. However MSDN is often wrong or missing vital info, so we need unit tests for them really. Rob has made a start on a COM testing framework. Where COM objects are implemented, there should be unit tests which check if the object can be aggregated or not. For this a dummy COM object could be used and then passed as the outer unknown, if you don't get back CO_E_NOAGGREGATION then it's OK (in theory ... in practice I suspect not all objects check this). Maybe we should have a header that makes aggregation checks really easy.

Dec. 1, 2004

Re: implementing DllCanUnloadNow questions

by Mike Hearn

On Tue, 30 Nov 2004 18:33:20 -0500, James Hawkins wrote: > Is _Construct the same as _AddRef()? I'm thinking it's not. If it > isn't, I need to add a MSI_Construct to msi. What are the parameters > to the Construct function and what would usually go in the place of > the "..."? It's just the function that creates the object. There are no real source conventions in Wine unfortunately so it could be called anything. Look for a function that HeapAllocs a struct then sets its ->refcount member to 1 (may not be called ->refcount of course). thanks -mike

Dec. 1, 2004

Re: Winecfg -> browse for folder

by Mike Hearn

On Tue, 30 Nov 2004 22:08:26 +0100, Robert van Herk wrote: > Oops, I guess this suggestion was a bit too late, since I commited my > patch this afternoon... I wouldn't worry too much. I'm not sure a PIDL extension is a good idea anyway - it's probably the Microsoft way, but this is a Wine extension API so we don't have to follow in their footsteps exactly. It would be a harder to use API if it was PIDL based. thanks -mike

Dec. 1, 2004

Suggestions for fixing test?

by Jakob Eriksson

http://test.winehq.org/data/200412011000/xp_IDWASEMPTY/gdi32:metafile.txt Any suggestions for fixing this? regards, Jakob

Dec. 1, 2004

Re: systray rewrite part 2

by Mike Hearn

On Tue, 30 Nov 2004 19:14:15 +0100, Grant Williamson wrote: > Mike, > ok the rewrite, applies & compiles cleanly on 20041019, however, > running SIP Phone-lite, it does not show on the systray, the older > patch did. > I am running gnome-2.8 on rhel4, what program do you want us to test > with it. Can you post a +systray trace please? I tested this with the CoolTrayTest demo program, but the XEMBED docking code is ridiculously race prone and flaky. It doesn't surprise me at all you don't see anything. What may have happened is that it did dock but GNOME assigned it a 1pixel width area. Last time I talked to Anders about this he seemed to think it was a bug in the EggTrayManager code, but it never seems to show up with native apps so presumably we could hack around it in Wine. thanks -mike

Dec. 1, 2004

<<PATCH>> Added shell32.dll functions to browse for unix directory; altered winecfg to use it to select the root directory of a virtual drive

by Robert van Herk

Hi, I had some problems with my mail server, so I send in this patch again. If the previous one did arrive, please ignore this e-mail. ------------------------------------------------------------------------ Changes: Added functionality to browse for a UNIX folder. This is done by making two new funtions in dlls/shell32/brsfolder.c, namely wine_shell_browse_for_UNIX_directoryA wine_shell_browse_for_UNIX_directoryW These functions are exported in shlobj.h. The original code that allowed just for picking a Windows folder, was split up. It was to be found in brsfolder.c, but I split this in: brsfolder.c brsfolder.h brsfolder_windows.c brsfolder_windows.h brsfolder_unix.c brsfolder_unix.h unixTools.c unixTools.h, Otherwise I found the code to be incomprehendible. Furthermore, winecfg now uses the wine_shell_browse_for_UNIX_directoryA to let the user pick a UNIX directory as root for his virtual drive mappings. Regards, Robert van Herk

Dec. 1, 2004

Re: Always create a suspended thread in CreateThread and resume it if CREATE_SUSPENDED flag is not set as Windows does

by Robert Shearman

Dmitry Timoshkov wrote: >Hello, > >there is at least one application which crashes in CreateThread due >to a race between a creating thread and a newly created one. The problem >is that the tid address passed to CreateThread resides in the memory >block allocated with VirtualAlloc which gets freed once the newly created >thread starts running, and when CreateThread code attempts to store thread >id it crashes. > >It appears that Windows always creates suspended threads in CreateThread >and a created thread gets resumed later. Here is a snippet of the log >running a simple test program under NT strace (the test app just creates >a thread): > >hThread = CreateThread(NULL, 0, thread_proc, NULL, 0, &tid); >CloseHandle(hThread); > >... >117 796 792 NtCreateThread (0x1f03ff, 0x0, -1, 1243704, 1244568, 1, ... 60, {796, 800}, ) == 0x0 >118 796 792 NtRequestWaitReplyPort (40, {28, 52, new_msg, 0, 2013529912, 2147348480, 902, 2086471576} "\0\0\0\0\1\0\1\0x\1\23\0\320<\23\0<\0\0\0\34\3\0\0 \3\0\0" ... {28, 52, reply, 0, 796, 792, 2138, 0} "\0\0\0\0\1\0\1\0\0\0\0\0\320<\23\0<\0\0\0\34\3\0\0 \3\0\0" ) == 0x0 >119 796 792 NtResumeThread (60, ... 1, ) == 0x0 >120 796 792 NtClose (60, ... ) == 0x0 >... > >Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Always create a suspended thread in CreateThread and resume it > if CREATE_SUSPENDED flag is not set as Windows does. > >--- cvs/hq/wine/dlls/kernel/thread.c 2004-09-22 16:48:59.000000000 +0900 >+++ wine/dlls/kernel/thread.c 2004-12-01 18:04:52.000000000 +0800 >@@ -164,7 +164,7 @@ HANDLE WINAPI CreateRemoteThread( HANDLE > if (flags & STACK_SIZE_PARAM_IS_A_RESERVATION) stack_reserve = stack; > else stack_commit = stack; > >- status = RtlCreateUserThread( hProcess, NULL, (flags & CREATE_SUSPENDED) != 0, >+ status = RtlCreateUserThread( hProcess, NULL, TRUE, > NULL, stack_reserve, stack_commit, > THREAD_Start, info, &handle, &client_id ); > if (status == STATUS_SUCCESS) >@@ -172,6 +172,19 @@ HANDLE WINAPI CreateRemoteThread( HANDLE > if (id) *id = (DWORD)client_id.UniqueThread; > if (sa && (sa->nLength >= sizeof(*sa)) && sa->bInheritHandle) > SetHandleInformation( handle, HANDLE_FLAG_INHERIT, HANDLE_FLAG_INHERIT ); >+ if (!(flags & CREATE_SUSPENDED)) >+ { >+ DWORD ret; >+ >+ status = NtResumeThread( handle, &ret ); >+ if (status) >+ { >+ NtTerminateThread( handle, -1 ); >+ RtlFreeHeap( GetProcessHeap(), 0, info ); >+ SetLastError( RtlNtStatusToDosError(status) ); >+ handle = 0; >+ } >+ } > } > else > > I think you should close the thread handle in the error case, otherwise it will be leaked. Rob

Dec. 1, 2004

Re: Wine book

by Shachar Shemesh

I'm not sure what I'm writing here is appropriate for actual "headings". It's just some points to keep in mind when writing the actual chapters. Brian Vincent wrote: >[1] Chapter outlines: > >Title: "Wine: Running Windows Applications on Linux" [4] >1. Wine Introduction[15 pages] > What is Wine? > How Can Wine Help You? > An Introduction to Windows Components > Overview of Wine's Components > Recent Changes to Wine > A History of the Wine Project > How Can You Get Wine? > > Back to earth - what will wine not do at this stage. >2. Installing Wine [20 pages] > System Requirements > Bundled Versions > Downloading Packaged Versions > Accessing CVS > Compiling and Installing Wine > > The soft vs. hard dependencies. How to tell whether you have everything you need. > Uninstalling Wine > >5. Installing Common Programs [35 pages] > Microsoft Office > > Internet explorer? > Adobe Photoshop > File Utilities > Peer-to-Peer Applications > Further Help: The Wine Application Database > >10. Introduction to Winelib [20 pages] > Introduction to Winelib > > Make sure you mention here that you'll still need wine at the end of the day! > Licensing Considerations > Portability Considerations > Getting Started > Understanding the Winelib toolkit > A Roadmap for Porting > Installation of the MinGW Compiler > >13. Advanced Porting Techniques [25 pages] > C++ Problems > Working with Microsoft Foundation Classes > > Actually, Boaz can probably help you with: Working with Advanced Template Library > Working with Templates > Moving From Visual Studio to MinGW > > >PPS. I'd like to think this won't affect WWN because I really have no >life. However, that's not too realistic. Hopefully WWN won't suffer >too much. > > Let's hope so. Good news is that you'd have to keep on the wine mailing list. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Dec. 1, 2004

Debian Packages Almost Ready

by Scott Ritchie

Debian packages are almost done. I have them up for testing. Add the following to /etc/apt/sources.list deb http://tuzakey.com/~scott/ binary/ deb-src http://tuzakey.com/~scott/ source/ My friend's webserver can't handle the huge bandwidth permanent hosting of packages like this will require, so if there's a way we could put them up on winehq it would be nice. I'd like to have an apt repository here, so installing the latest debian wine package would be as simple as adding something like the above line to sources.list and then doing things as normal. What would be ideal, of course, is if the package could be included in the Debian distribution itself. I've yet to hear back from Ove (the current maintainer of the package), and unless he's disappeared entirely there's really nothing that can be done until he decides to update the package or orphan it, as Debian maintainers have total control over their packages. Ubuntu is a different matter, however, and I may be able to get an Ubuntu version included much quicker. If you're a Debian/Ubuntu user, test out the packages and tell me if I left anything out. Thanks, Scott Ritchie

Dec. 1, 2004

Small WinMM janitorial project

by Steven Edwards

Hi, With this patch it is possible to use a few Windows sound drivers under ReactOS but I have only submitted patches for one small part of this because its going to require a bit of rework of the existing WinMM code. This should fix 2 of the existing W->A CrossCall issues # dlls/winmm/winmm.c: winmm: waveInGetDevCapsW: illegal call to waveInGetDevCapsA # dlls/winmm/winmm.c: winmm: waveOutGetDevCapsW: illegal call to waveOutGetDevCapsA but before it can be merged we have to rewrite the Wine drivers to accept Unicode. I am planing on adding this as a subproject to the Janitorial page. Thanks Steven __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

Dec. 1, 2004

Re: Bug Busters

by James Hawkins

On Tue, 30 Nov 2004 23:23:46 -0700, tony_lambregts(a)telusplanet.net <tony_lambregts(a)telusplanet.net> wrote: > James Hawkins wrote: > > > > On Tue, 30 Nov 2004 23:58:59 -0500, Adam Babcock <adam(a)nemesys.ca> wrote: > > > >>James Hawkins wrote: > >> > >> > >> > >>>I have a totally non-original idea for sessions called Bug Busters > >>>where, at a designated time, a group of wine developers would get > >>>together on #winehackers (or some other channel). We would pick a bug > >>>(or maybe more) from wine's bug tracker and work together to fix the > >>>bug(s). This would serve several good purposed. First, we would be > >>>giving more attention to wine's bugzilla and getting rid of a lot of > >>>those bugs. Second, many newcomers can witness and take part in the > >>>wine development process. I'm sure everyone can remember how daunting > >>>it is to jump into wine development. Anyway, if anyone has any ideas > >>>or would like to take part in this, let me know and we'll get this > >>>started. > >>> > >> > >>This is a good idea, same idea as Gentoo Bug Days, and those have been > >>extremely successful. > >> > > > > > > Awesome, I think it could be really successful with wine too. > > > This is a good idea but how do we decide which bug(s) to fix... Here is what I > think. > > - The program that the bug involves has to be available to anyone. at least for > the first sessions (Search for keyword download in bugzilla reveals 146 candidates) > http://bugs.winehq.org/buglist.cgi?product=Wine&keywords_type=allwords&keyw… > > - Older bugs bugs should be fixed first. > > - More Popular programs should be take higher priority > > -- > > Tony Lambregts > > I agree that programs should be freely available to anyone if the bug requires a program. Some of the bugs don't need them. I also agree that the older bugs should be fixed first. We might even find that a bunch of bugs we try to fix have already been fixed (it's good to clean up bugzilla too). My thought is that we would pick the bugs before the sessions so that anyone interested can research the problems beforehand and we know what we're going to work on for the session. Another option is that we pick the bugs to work on during the session. I think both options are convenient and worth considering. It's ultimately up to the community though. -- James Hawkins

Dec. 1, 2004

Re: Bug Busters

by tony_lambregts＠telusplanet.net

James Hawkins wrote: > On Tue, 30 Nov 2004 23:58:59 -0500, Adam Babcock <adam(a)nemesys.ca> wrote: > >>James Hawkins wrote: >> >> >> >>>I have a totally non-original idea for sessions called Bug Busters >>>where, at a designated time, a group of wine developers would get >>>together on #winehackers (or some other channel). We would pick a bug >>>(or maybe more) from wine's bug tracker and work together to fix the >>>bug(s). This would serve several good purposed. First, we would be >>>giving more attention to wine's bugzilla and getting rid of a lot of >>>those bugs. Second, many newcomers can witness and take part in the >>>wine development process. I'm sure everyone can remember how daunting >>>it is to jump into wine development. Anyway, if anyone has any ideas >>>or would like to take part in this, let me know and we'll get this >>>started. >>> >> >>This is a good idea, same idea as Gentoo Bug Days, and those have been >>extremely successful. >> > > > Awesome, I think it could be really successful with wine too. > This is a good idea but how do we decide which bug(s) to fix... Here is what I think. - The program that the bug involves has to be available to anyone. at least for the first sessions (Search for keyword download in bugzilla reveals 146 candidates) http://bugs.winehq.org/buglist.cgi?product=Wine&keywords_type=allwords&keyw… - Older bugs bugs should be fixed first. - More Popular programs should be take higher priority -- Tony Lambregts

Dec. 1, 2004

Re: Bug Busters

by Joel Konkle-Parker

James Hawkins wrote: > I have a totally non-original idea for sessions called Bug Busters > where, at a designated time, a group of wine developers would get > together on #winehackers (or some other channel). We would pick a bug > (or maybe more) from wine's bug tracker and work together to fix the > bug(s). This would serve several good purposed. First, we would be > giving more attention to wine's bugzilla and getting rid of a lot of > those bugs. Second, many newcomers can witness and take part in the > wine development process. I'm sure everyone can remember how daunting > it is to jump into wine development. Anyway, if anyone has any ideas > or would like to take part in this, let me know and we'll get this > started. Sounds like a great idea. I've been trying to get into Wine development, but haven't been able to get my foot firmly planted anywhere. The whole thing is just too complex. I'd gladly join a BB session, if only to get some insight into how things work. -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jjk3(a)msstate.edu]

Dec. 1, 2004

Re: Bug Busters

by James Hawkins

On Tue, 30 Nov 2004 23:58:59 -0500, Adam Babcock <adam(a)nemesys.ca> wrote: > James Hawkins wrote: > > > > I have a totally non-original idea for sessions called Bug Busters > > where, at a designated time, a group of wine developers would get > > together on #winehackers (or some other channel). We would pick a bug > > (or maybe more) from wine's bug tracker and work together to fix the > > bug(s). This would serve several good purposed. First, we would be > > giving more attention to wine's bugzilla and getting rid of a lot of > > those bugs. Second, many newcomers can witness and take part in the > > wine development process. I'm sure everyone can remember how daunting > > it is to jump into wine development. Anyway, if anyone has any ideas > > or would like to take part in this, let me know and we'll get this > > started. > > > > This is a good idea, same idea as Gentoo Bug Days, and those have been > extremely successful. > Awesome, I think it could be really successful with wine too. -- James Hawkins

Dec. 1, 2004

Re: Bug Busters

by Adam Babcock

James Hawkins wrote: > I have a totally non-original idea for sessions called Bug Busters > where, at a designated time, a group of wine developers would get > together on #winehackers (or some other channel). We would pick a bug > (or maybe more) from wine's bug tracker and work together to fix the > bug(s). This would serve several good purposed. First, we would be > giving more attention to wine's bugzilla and getting rid of a lot of > those bugs. Second, many newcomers can witness and take part in the > wine development process. I'm sure everyone can remember how daunting > it is to jump into wine development. Anyway, if anyone has any ideas > or would like to take part in this, let me know and we'll get this > started. > This is a good idea, same idea as Gentoo Bug Days, and those have been extremely successful.

Dec. 1, 2004

Bug Busters

by James Hawkins

I have a totally non-original idea for sessions called Bug Busters where, at a designated time, a group of wine developers would get together on #winehackers (or some other channel). We would pick a bug (or maybe more) from wine's bug tracker and work together to fix the bug(s). This would serve several good purposed. First, we would be giving more attention to wine's bugzilla and getting rid of a lot of those bugs. Second, many newcomers can witness and take part in the wine development process. I'm sure everyone can remember how daunting it is to jump into wine development. Anyway, if anyone has any ideas or would like to take part in this, let me know and we'll get this started. -- James Hawkins

Dec. 1, 2004

Re: Wine book : Ira Krakow introduction

by Ira Krakow

Brian, thank you for all your hard work getting the ball rolling and for your kind words about me. I totally agree with you about Prentice Hall's professionalism and that they "get it". I want to introduce myself briefly to the group. I am an independent Windows (and DOS before that) database applications developer with nearly 20 years experience. I've developed applications in Visual Basic, Visual C++, Java, Access, PowerBuilder, and OpenInsight, among others, using back ends such as SQL Server and Oracle. My customers have included a wide variety of businesses, from small 5 person shops to departments of Fortune 500 companies. I have also developed Web-based applications using Active Server Pages. In the process, I have had to dig deep into the advanced features of many of these programs, such as the Win32 API. I also am an experienced technical writer and computer book author. I wrote the online help for OpenInsight, which included examples from the Windows API, OLE and ActiveX controls, ODBC configurations, etc. A long time ago (1985) I wrote a computer book (LOTUS 1-2-3 SELF-TAUGHT) which sold 50,000 copies. I also wrote the networking chapter of a Java book in 1996. Go to amazon.com, type in Ira Krakow, and you'll be able to buy them! In the Linux world, I'm a relative newbie. I've only seriously gotten into Linux for the past 3 months. I'm very excited about Wine/Winelib as the way to bridge between Windows and Linux applications. My goal is to show other Windows developers how to port their applications over and escape from the clutches of Microsoft. Brian has a wealth of knowledge and is a pleasure to talk with. I'm thrilled to be teaming up with him and I'm sure we'll produce a book that will find its audience quickly. I've been lurking on the wine-related groups for 2 months and have been impressed with the depth of knowledge and willingness to share that you have. As I get up to speed in winelib, I'm sure I'll have questions. Actually, I have one now - note that Chapter 12 is a "Case Study ... Porting", with content to be determined. Has anyone done a port of some substantial Windows code to Linux using Winelib? What do you think should be covered in this chapter? Please feel free to contact me at ikrakow_1999(a)yahoo.com about this or any related topic. Thank you for your attention. I look forward to (virtually) meeting all of you. Sincerely, Ira Krakow ikrakow_1999(a)yahoo.com

Dec. 1, 2004

Wine book

by Brian Vincent

Just wanted to give everyone a heads up.. I followed up with Jeremy's email a few months ago about a publisher wanting to put together a book on Wine. Yep, I have no life and 400 pages can't be that hard to write. Well, we started the ball rolling and now it looks like it's going to happen. I should be signing the contract in a few days. There's lots of details I thought you guys might be interested in. You'll find the chapter outlines[1] at the bottom of this email. This book is oriented at users and Winelib developers. It's not a book about how to hack Wine internals. One thing I'll try to keep in mind as I'm writing is how to entice people to get involved with development. I think it's important to try to get people involved in the community. I'm not going to be writing this alone. Ira Krakow, a Boston native, will be writing the Winelib parts. I didn't feel comfortable doing those and Ira had approached the publisher separately about doing a book on porting Windows apps. We've chatted a few times and I'm confident that given his experience he'll do well. I'm cc:ing him on this email by way of introduction and I'm sure at some point in the future he'll have a question or two (or 50.) The publisher is Prentice-Hall. Thus far they've been excellent to work with and they really seem to just "get it" when it comes to open source projects. Specifically, this book will fall into their Bruce Perens' Open Source Series [2]. After the book is published, it will be available for a short time only in a dead tree version. After a few months it will be available under the Open Publication License [3]. It's a good license and contains many things I think are important. Also, I'd like to thank everyone who reviewed the initial proposal. That process happened really fast and I wasn't even aware it had been sent out for review until after you guys got the emails. There was lots of good feedback in there and I incorporated a lot of it in the final proposal that got approved (you may even notice some changes in the chapters below as a result.) Some other things you guys mentioned aren't specifically in this chapter outline, but I made some notes as to what needs to be addressed. Thanks again. Anyone who didn't see that proposal, you didn't miss much. It was lots of marketspeak. The key is the chapter outline below, so if you have any comments about what I'm overlooking, _please_ let me know. [1] Chapter outlines: Title: "Wine: Running Windows Applications on Linux" [4] 1. Wine Introduction[15 pages] What is Wine? How Can Wine Help You? An Introduction to Windows Components Overview of Wine's Components Recent Changes to Wine A History of the Wine Project How Can You Get Wine? 2. Installing Wine [20 pages] System Requirements Bundled Versions Downloading Packaged Versions Accessing CVS Compiling and Installing Wine Uninstalling Wine 3. Configuring Wine [35 pages] Introduction to Winecfg Windows Versions Libraries: Native vs. Builtin Application Settings Drive Configuration Serial and Parallel Ports Network Shares Fonts Printing Database Access 4. Installing Applications [35 pages] Basic Installation Common Installation Pitfalls Resources to Help With Installation Adding Native Libraries Installing Games Copy Protection Pitfalls Using Native DirectX 5. Installing Common Programs [35 pages] Microsoft Office Adobe Photoshop File Utilities Peer-to-Peer Applications Further Help: The Wine Application Database 6. Linux, Wine, and Windows Integration [40 pages] Integrating with Desktop Environments KDE and GNOME Integration Wine Tools Introduction Wineshelllink Wineprefixcreate Regedit Understanding the Wine Registry Changing the Registry Importing an Existing Registry Using an Existing Windows Partition 7. Enterprise Deployment [30 pages] Licensing Considerations Understanding Windows and Wine Security Automating Deployment of Applications Scripting Wine Citrix Killer: Wine and the Linux Terminal Server Project Performance Tweaks Reporting Bugs and Working with Developers 8. Commercial Alternatives: CodeWeaver's CrossOver Office [25 pages] Introduction to CrossOver Office Downloading and Installing CrossOver Configuring CrossOver Installing Applications with CrossOver 9. Commercial Alternatives: TransGaming's Cedega [25 pages] Introduction to Cedega Downloading and Installing Cedega Configuring Cedega Installing Games with Cedega 10. Introduction to Winelib [20 pages] Introduction to Winelib Licensing Considerations Portability Considerations Getting Started Understanding the Winelib toolkit A Roadmap for Porting Installation of the MinGW Compiler 11. Using Winelib for Porting [45 pages] Installation of the MinGW compiler Moving From Visual Studio to MinGW Tips and Tricks for Changing Compilers Moving Development to Linux Using Winemaker Using the Wine Resource Compiler Using the Wine Message Compiler Linking it Together: winegcc Debugging with the Wine debugger 12. Case Study: Porting a To-Be-Determined Application [30 pages] 13. Advanced Porting Techniques [25 pages] C++ Problems Working with Microsoft Foundation Classes Working with Templates Moving From Visual Studio to MinGW 14. dvanced Library Techniques [20 pages] Getting Started: Why Share Libraries? Using Linux Libraries with Winelib Applications Using Windows Libraries with Winelib Applications Why Wine is not a Shared Library [2] Peren's Open Source Series info: http://phptr.com/promotion/1484?redir=1 [3] OPL license: http://www.opencontent.org/openpub/ a good discussion of it: http://lwn.net/Articles/108250/ [4] With regards to the title, I'll be sure to mention in Wine runs on other operating systems. PS. This still leaves the door open for someone to write an O'Reilly book. PPS. I'd like to think this won't affect WWN because I really have no life. However, that's not too realistic. Hopefully WWN won't suffer too much. - Brian Vincent

Dec. 1, 2004