September 2003 - Wine-Devel

"Start menu" (continued ...)
by Robert van Herk Sept. 30, 2003

Sept. 30, 2003

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 Sept. 30, 2003

Sept. 30, 2003

> 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 Sept. 30, 2003

Sept. 30, 2003

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 Sept. 30, 2003

Sept. 30, 2003

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: Start menu (especially for Alexandre Julliard)
by Mike McCormack Sept. 30, 2003

Sept. 30, 2003

Robert van Herk wrote: > Mike McCormack wrote: > >> Ideally, you'd want to write a Gnome VFS module that calls shell32.dll >> and queries the shell name space to generate the start menu the same >> way Windows does. You need to use some RPC mechanism to do that, as >> you can't link wine dlls directly into your gnome vfs module. > > > Oof, that sounds hard to do ;-). > > Does this mean that this module would rather be a "Windows" program (or > Wine program if you like), than a Linux programme? Because I guess that > with a Win32 program it would be easier to access shell32.dll. Although > that would not blend so well into your Linux environment I guess... > > Or maybe it is possible to write a thin Windows deamon that kinda serves > the icons and links to a Linux program? Maybe they can talk though > std/in std/out so that they could be piped together? > > Any ideas on that? What I'm talking about would be, like you say, a Windows daemon that servers the icons and pathes. The client and server would communicate with each other via a pipe or something like that. The client(s) would be a gnome vfs library, the KDE equivilent, or perhaps even plugins for other desktops. To make it easier, i guess you could just make the windows daemon enumerate the .lnk files in Windows/Start Menu first, then once you have that working, make it query the shell instead. The appropriate code from Gnome to look at is in the gnome cvs: :pserver:anonymous(a)anoncvs.gnome.org:/cvs/gnome the module names are: gnome-vfs gnome-vfs-extras gnome-panel I was looking at xml-rpc for the protocol to use on the pipe, but that might be a bit of an overkill, and it could be easier to write the protocol yourself. http://www.xmlrpc.com/directory/1568/implementations If you are going to use xml-rpc, make sure to choose an implementation that is LGPL compatible. Mike

2 1

RE: Wineconf 2004, otherwise known as...
by Steven Edwards Sept. 30, 2003

Sept. 30, 2003

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 Sept. 30, 2003

Sept. 30, 2003

...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 Sept. 30, 2003

Sept. 30, 2003

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 Sept. 30, 2003

Sept. 30, 2003

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 Sept. 30, 2003

Sept. 30, 2003

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