September 2003 - Wine-devel

Re: PATCH: stop crashes in desktop mode
by Alexandre Julliard 01 Oct '03

01 Oct '03

Alex Pasadyn <ajp(a)mail.utexas.edu> writes: > This patch just puts in a simple check that traps this condition so > Wine doesn't crash. I don't know enough about what that code is > supposed to be doing to fix it properly. (This is certainly better > enough on my system though as it longer crashes!) If someone wants to > describe what "should" happen there I can look into really fixing it. The real problem is that we create one X desktop window in each process, while there is only one desktop window in the Windows sense. So anything that depends on the X desktop window to be shared is broken. The right fix is to manage the X desktop in a separate process. -- Alexandre Julliard julliard(a)winehq.com

7 14

"Start menu" (continued ...)
by Robert van Herk 01 Oct '03

01 Oct '03

Hi all... As I understand, right now there are various "standards" on how to write menus for Linux, that are incompatible. That would mean that writing a "grand unified ;-)" start menu client as I discussed before is currently impossible. What could be made already though, is a Wine deamon that talks to shell32.dll internally and input/outputs with pipes to some linux client, in order to serve the start menu items. This would link the Windows start menu to Linux, in a tidy way. So the idea is that the Windows program's output could be piped to some Linux client that actually creates the menu dynamically, so it stays in continuous synchronization with your Start menu directory. The Linux client cannot be made unified yet, but I suppose I could at least write a client for KDE. It wouldn't be to messy to add other clients later for other desktop enviroments, since the deamon does not have to change in order to do so. That is, only the neccesairy thingies change. From looking at the help files I suppose KPanelAppMenu could do the trick. Would such a system be appreciated by the you people? Or do you think I should wait untill a better standarization is available? Or do you think creating a Windows deamon and a Linux client is too much overkill for such a feature? Also, if this feature would be handy, does anyone have expirience with the KPanelAppMenu? I can't get the thingy to work yet... Grtz, Robert

2 1

Re: Script to compile Wine programs on Windows
by Dimitrie O. Paun 30 Sep '03

30 Sep '03

> I don't think that's a real problem, these files don't change > often. It certainly doesn't justify adding a complicated > infrastructure to deal with it. Indeed, I said, and I let it go. But thinking a little more about it, I don't see how you solve the problem with the manual stuff. As I understand it, the problem we need to solve is as follows: -- store rule in Make.rules.in -- handle multiple .rc files per Makefile -- rebuild .res file automatically if .rc or .bmp change Now, in my proposal we have: In Make.rules .rc.extract: bin2res $< && touch $@ %.res: %.rc %.extract $(WRC) -o $@ $< In make depend: bitmap1.bmp bitmap2.bmp bitmap3.bmp: rsrc.extract rsrc.res: bitmap1.bmp bitmap2.bmp bitmap3.bmp rsrc.extract: rsrc.rc The only complication here is the .extract file which allows us to split the dependencies from the rules. The complicated stuff are the dependencies, but you need those anyway. A simple marker file is a small price to pay for the convenience... If you think we can keep it simpler, can you please tell me a bit more of what you have in mind? How are we going to use that $(RCBINARIES) if we have more than one .rc file per Makefile? -- Dimi.

4 7

Re: PATCH: server/trace.c cleanup (RETRY)
by Alexandre Julliard 30 Sep '03

30 Sep '03

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > [ 2nd attempt. I really don't see any viable alternative to these > casts; keeping the status quo certainly seems bad. ] That code is generated, there's no point in fixing it. You need to change tools/make_requests. -- Alexandre Julliard julliard(a)winehq.com

2 2

RE: shlwapi 405/406
by Robert Shearman 30 Sep '03

30 Sep '03

Hi, Just a few comments on an otherwise good patch: > -static BOOL URL_JustLocation(LPCWSTR str) > +static BOOL WINAPI URL_JustLocation(LPCWSTR str) ... > -static LPCWSTR URL_ScanID(LPCWSTR start, LPDWORD size, > WINE_URL_SCAN_TYPE type) > +static LPCWSTR WINAPI URL_ScanID(LPCWSTR start, LPDWORD size, > WINE_URL_SCAN_TYPE type) Is there any reason for changing the calling convention of these two functions? > +/**************************************************************** > ********* > + * MLBuildResURLA [SHLWAPI.406] > + * > + * See MLBuildResURLA. > + */ > +HRESULT WINAPI MLBuildResURLW(LPCWSTR lpszLibName, HMODULE hMod, > DWORD dwFlags, > + LPCWSTR lpszRes, LPWSTR lpszDest, > DWORD dwDestLen) > +{ > + static const WCHAR szRes[] = { 'r','e','s',':','/','/','\0' }; > +#define szResLen (sizeof(szRes)/sizeof(WCHAR) - sizeof(WCHAR)) Should this not be #define szResLen (sizeof(szRes)/sizeof(WCHAR) - 1) ? > + HRESULT hRet = E_FAIL; > + > + TRACE("(%s,%p,0x%08lx,%s,%p,%ld)\n", debugstr_w(lpszLibName), > hMod, dwFlags, > + debugstr_w(lpszRes), lpszDest, dwDestLen); > + > + if (!lpszLibName || !hMod || hMod == INVALID_HANDLE_VALUE || > !lpszRes || > + !lpszDest || (dwFlags && dwFlags != 2)) > + return E_INVALIDARG; > + > + if (dwDestLen >= szResLen + 1) > + { > + dwDestLen -= (szResLen + 1); > + memcpy(lpszDest, szRes, sizeof(lpszDest)); > + > + hMod = MLLoadLibraryW(lpszLibName, hMod, dwFlags); > + > + if (hMod) > + { > + WCHAR szBuff[MAX_PATH]; > + > + if (GetModuleFileNameW(hMod, szBuff, sizeof(szBuff)/sizeof(WCHAR))) > + { > + DWORD dwPathLen = strlenW(szBuff) + 1; > + > + if (dwDestLen >= dwPathLen) > + { > + DWORD dwResLen; > + > + dwDestLen -= dwPathLen; > + memcpy(lpszDest + szResLen, szBuff, dwPathLen * sizeof(WCHAR)); > + > + dwResLen = strlenW(lpszRes) + 1; > + if (dwDestLen >= dwResLen + 1) > + { > + lpszDest[szResLen + dwPathLen + dwResLen] = '/'; > + memcpy(lpszDest + szResLen + dwPathLen, lpszRes, > dwResLen * sizeof(WCHAR)); > + hRet = S_OK; > + } > + } > + } > + MLFreeLibrary(hMod); > + } > + } > + return hRet; > +} Rob

4 8

RE: Wineconf 2004, otherwise known as...
by Steven Edwards 30 Sep '03

30 Sep '03

Hey Jer, I will try to be there. I can't speak for the rest of the ReactOS developers but I think we may have one or two that would like to come. I have always wanted to see the Russian Winter so I guess St. Paul in January is good practice. Thanks Steven > -----Original Message----- > From: wine-devel-admin(a)winehq.org > [mailto:wine-devel-admin(a)winehq.org]On > Behalf Of Jeremy White > Sent: Friday, September 26, 2003 5:41 PM > To: wine-devel(a)winehq.com > Subject: Wineconf 2004, otherwise known as... > > > ...making good on my threat. > > We are making plans to host Wineconf 2004, > in St. Paul, MN, during January 2004. > > This is the last chance for someone in Europe to volunteer > to organize it in their neck of the woods... > > Otherwise, we plan to provide: > * A meeting space for 2 days > * Arrangements for moderately price hotel rooms > * Advice on transportation, which should be straightforward > * A meal or two, and drinks for at least one evening > * We'll have all CodeWeavers Wine hackers in town for the event > * Free buttons for the St. Paul Winter Carnival: > http://www.winter-carnival.com/ > <grin> > > What we will expect you to provide: > * Your airfare (sorry, no IPO money for us) > * Your hotel room > * A laptop with wireless > * Long underwear and Parkas > > What I don't know yet: > * We may need to charge some sort of modest fee, > depending on how the budget and our bank account > look. We're willing to shoulder some costs, > but we may need extra help. We'll also plan on > using the Wine party fund to help cover some costs. > * Exact dates; my thinking is to do it in conjunction > with a weekend (e.g. Fri/Sat or Sun/Mon), but > I want to see what meeting space cost/availability > looks like before I pick. Right now, Fri Jan 16th/ > Sat Jan 17th are looking good (note that LinuxWorld NY > is the following week for those that might be able > to get their employer to sponsor the trip Stateside). > > > Thoughts? Comments? > > If you think you would come, please email me privately; > I'd like to get a rough count to help with planning. > > Cheers, > > Jeremy __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

5 5

Wineconf 2004, otherwise known as...
by Jeremy White 30 Sep '03

30 Sep '03

...making good on my threat. We are making plans to host Wineconf 2004, in St. Paul, MN, during January 2004. This is the last chance for someone in Europe to volunteer to organize it in their neck of the woods... Otherwise, we plan to provide: * A meeting space for 2 days * Arrangements for moderately price hotel rooms * Advice on transportation, which should be straightforward * A meal or two, and drinks for at least one evening * We'll have all CodeWeavers Wine hackers in town for the event * Free buttons for the St. Paul Winter Carnival: http://www.winter-carnival.com/ <grin> What we will expect you to provide: * Your airfare (sorry, no IPO money for us) * Your hotel room * A laptop with wireless * Long underwear and Parkas What I don't know yet: * We may need to charge some sort of modest fee, depending on how the budget and our bank account look. We're willing to shoulder some costs, but we may need extra help. We'll also plan on using the Wine party fund to help cover some costs. * Exact dates; my thinking is to do it in conjunction with a weekend (e.g. Fri/Sat or Sun/Mon), but I want to see what meeting space cost/availability looks like before I pick. Right now, Fri Jan 16th/ Sat Jan 17th are looking good (note that LinuxWorld NY is the following week for those that might be able to get their employer to sponsor the trip Stateside). Thoughts? Comments? If you think you would come, please email me privately; I'd like to get a rough count to help with planning. Cheers, Jeremy

9 12

[ANN] Conformance testing campaign
by Ferenc Wagner 30 Sep '03

30 Sep '03

Greetings! Hereby I ask people who have access to real Windows machines to help me gather information about the behaviour of cross- compiled conformance tests on the different platforms. Please go to http://afavant.elte.hu/~wferi/wine for details. If you can build the tests in the Wine tree by MSVC, then packaging the compiled binaries would also mean a valuable addition. You will also find a packaging script on the page. Thanks for your time, Feri.

9 39

wine & ccache
by Dimitrie O. Paun 30 Sep '03

30 Sep '03

Hi folks, Just wanted to let people know that ccache works rather well with wine. On my lowly 600MHz Pentium box, it takes about 1h to compile, after a make clean. Second time through it takes about 1/4h to do the same thing, 75% faster! (As an added bonus, CPU utilization dropped from 86% to 60%) A nice thing would be to also be able to generate a top Makefile that knows all about the project, and we no longer do the recursive descent. It takes my box almost 20 seconds to do a 'make -s' after a full build. Not sure how doable this is, but I'm sure that things would be way faster if everything would be in one big Makefile. Probably I'm just going to end up buying a faster box before this gets implemented though :) How long does it take to do a 'time make -s' after a full build on one of the beefier boxes? -- Dimi.

6 8

Start menu (especially for Alexandre Julliard)
by Robert van Herk 30 Sep '03

30 Sep '03

OK people, As I understand (from the explanation by Russell Howe (thanx:-))), there is a script called wineshelllink that is supposed to install the created start menu items in your KDE menu. First of all: this script does not seem to do anything on my installation (Slackware 9). Are there known problems with this script? Second: from looking at the script it seems that this menu is not synchronized with the actual contents of your start menu, which would seem more fancy to me. Because Windows users will be aquainted with the fact that the Start menu directory actually contains the contents of the start menu. What I would propose is a system in which the contents of the wine menu would be in continuous synchronization with your start menu. That would mean: * Less error prone coding (no need for extra scripts etc) * More forward functionality (moving in the folder will actually result in moving in the menu as well) * Better support for applications (links that are not written through api calls will actually show up as well) * Ability to copy links between Windows installation and Wine installation Wouldn't you agree such a system would be better? Grtz, Robert

2 1