September 2003 - Wine-Devel

Re: PATCH: stop crashes in desktop mode

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > is_window_managed returns false if none of the conditions match. Is it > the case that one of the conditions will always cause it to return true? For windows that need to be managed yes. Even in managed mode there are some windows that are never managed, like menus, tooltips, etc. That's what is_window_managed is for. -- Alexandre Julliard julliard(a)winehq.com

Sept. 30, 2003

Re: PATCH: stop crashes in desktop mode

by Lionel Ulmer

> > IIRC it does not support Xrender at all. > > Yes that would need to be fixed. Well, the biggest problem would be how to have direct rendering for GL in a Xnest environment. I have absolutely no idea if this is possible without hacks. And then you would also need to add RandR support to Xnest to have the recent Desktop resize option working. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Sept. 30, 2003

Re: PATCH: stop crashes in desktop mode

by Mike Hearn

On Tue, 2003-09-30 at 18:13, Alexandre Julliard wrote: > The default is managed mode, and has been for a long time now. I'm confused then - [mike(a)littlegreen x11drv]$ cvs diff window.c Index: window.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/window.c,v retrieving revision 1.57 diff -u -r1.57 window.c --- window.c 5 Sep 2003 23:08:26 -0000 1.57 +++ window.c 30 Sep 2003 19:57:35 -0000 @@ -90,7 +90,7 @@ if ((win->dwStyle & WS_CAPTION) == WS_CAPTION) return TRUE; if (win->dwStyle & WS_THICKFRAME) return TRUE; /* default: not managed */ - return FALSE; + return TRUE; } is_window_managed returns false if none of the conditions match. Is it the case that one of the conditions will always cause it to return true?

Sept. 30, 2003

"Start menu" (continued ...)

by Robert van Herk

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

Sept. 30, 2003

Re: Updated winetests.exe

by Ferenc Wagner

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > -- we should include in the master file and the test output > some sort of unique identifier (a MD5 sum of sorts?) so > we make sure we correlate the test output with the correct > master file. I thought the build tag (which can be any one-line string) was enough. Why do we need anything else? > -- you have to be able to deal (how?) with tests results > that arrive before the master file. This is impossible, I would reject them. > -- a simple to generate format would be: [...] > > KEY:<the uuid> > *** <dll> (section repeated for each DLL) > * <dlls/<dll>/tests/file.c>:<CVS version> (multiple times, for each file) > <any errors/warnings generated during compilation, verbatim> > > <output of 'wine dlls/<dll>/tests/<dll>_test.exe.so> In general, this sounds almost OK, although I do not see why it would be simple to generate. We should accomodate both MSVC and MinGW, right? Their outputs are different. And some asterisks might be useful to separate the compiler and test output. But I think it is rather hard (Jakob?) and not sure whether it is worth the effort. Apart from the compiler output everything can be generated from the build tree (and I have the shell script for that), and since the build procedure is not automated, Jakob could simply copy some relevant output into dsound.dll.txt, possibly add some comments, tar it up with the master file and send it to WinHQ. >> One more thing, I really do not >> have the faintest idea about how to integrate this into the >> WineHQ page. There may be reasons there, too, like eg. the >> need to notify the system about a new build, which could be >> done by uploading the information skeleton... > > Well, this is what I'm thinking: > -- master file and test results are emailed to wine-tests(a)winehq.org > this is simple to do, Jakob should just change the submit method > to email, and it should work. In fact, Jakob why don't we start > doing that, to see how it works? > -- We need to integrate your processing script with sendmail, just > like mailman is. This way, when an email arrives on the wine-tests > list, you get to process it right away. The result template could > be placed right in the website, if Jer is OK with the idea. > Jer, do you have any special requirements for this stuff?

Sept. 30, 2003

Re: Question about WineX licences

by Dimitrie O. Paun

On September 30, 2003 11:51 am, Ove Kaaven wrote: > And it's "impossible" because the patch we're talking about does not > actually implement copy protection. It only makes Wine implement certain > Windows quirks. For Wine not to implement these quirks in certain APIs > may be considered bugs, and how do you abstract away bugfixes? Well, these should just be contributed back... :) That would be in the spirit of cooperation we're trying to promote. > Anyway, if you're really insistent, perhaps you can get Gav to let you > sign a NDA and see the code for yourself, then come up with a way to > abstract it, but you'd have to talk to him about it. I'd be interesting, but I don't think I want to sign any NDA. You guys know the problem a lot better than I do, it seems to be there's simply lack of political will. I mean, some of the stuff you guys doing may be hard to abstract, but I doubt that we can't "free" most of the DLLs of such copy protection hacks. In other words, you're saying this stuff touches a lot of DLLs ATM, so those can't be shared with Wine. Maybe the 20/80 rule applies here as well, in the sense that with 20% of the work, 80% of these DLLs can be freed. -- Dimi.

Sept. 30, 2003

Re: Script to compile Wine programs on Windows

by Dimitrie O. Paun

On September 29, 2003 03:33 pm, Alexandre Julliard wrote: > No it won't, that's why we need to change bin2res to generate only a > single file at a time, otherwise it breaks parallel makes. OK, how about this: ChangeLog Teach bin2res to deal with one file at a time. Index: tools/bin2res.c =================================================================== RCS file: /var/cvs/wine/tools/bin2res.c,v retrieving revision 1.16 diff -u -r1.16 bin2res.c --- tools/bin2res.c 18 Sep 2003 20:53:10 -0000 1.16 +++ tools/bin2res.c 30 Sep 2003 18:04:45 -0000 @@ -33,9 +33,11 @@ #endif static const char* help = - "Usage: bin2res [-x] | [-a] [-f] [-h] <rsrc.rc>\n" + "Usage: bin2res [OPTIONS] <rsrc.rc>\n" " -a archive binaries into the <rsrc.rc> file\n" " -x extract binaries from the <rsrc.rc> file\n" + " -i <filename> archive the named file into the <rsrc.rc> file\n" + " -o <filename> extract the named file from the <rsrc.rc> file\n" " -f force processing of older resources\n" " -h print this help screen and exit\n" "\n" @@ -55,7 +57,8 @@ " bin2res -x myrsrc.rc\n" "Binary files newer than the .rc file are not overwritten.\n" "\n" - "To force processing of all resources, use the -f flag.\n"; + "To force processing of all resources, use the -f flag.\n" + "To process a particular file, use the -i/-o options.\n"; void usage(void) { @@ -118,7 +121,7 @@ return res_file_name; } -int process_resources(const char* input_file_name, int inserting, int force_processing) +int process_resources(const char* input_file_name, const char* specific_file_name, int inserting, int force_processing) { char buffer[2048], tmp_file_name[PATH_MAX]; const char *res_file_name; @@ -147,7 +150,8 @@ { if (inserting) fprintf(ftmp, "%s", buffer); if (!(res_file_name = parse_marker(buffer, &res_last_update))) continue; - if (!force_processing && ((rc_last_update < res_last_update) == !inserting)) + if ( (specific_file_name && strcmp(specific_file_name, res_file_name)) || + (!force_processing && ((rc_last_update < res_last_update) == !inserting)) ) { printf("skipping '%s'\n", res_file_name); continue; @@ -188,9 +192,10 @@ { int convert_dir = 0, optc; int force_overwrite = 0; - const char* input_file_name; + const char* input_file_name = 0; + const char* specific_file_name = 0; - while((optc = getopt(argc, argv, "axfh")) != EOF) + while((optc = getopt(argc, argv, "axi:o:fh")) != EOF) { switch(optc) { @@ -199,6 +204,14 @@ if (convert_dir) usage(); convert_dir = optc; break; + case 'i': + case 'o': + if (specific_file_name) usage(); + specific_file_name = optarg; + optc = ((optc == 'i') ? 'a' : 'x'); + if (convert_dir && convert_dir != optc) usage(); + convert_dir = optc; + break; case 'f': force_overwrite = 1; break; @@ -216,7 +229,8 @@ if (!convert_dir) usage(); - if (!process_resources(input_file_name, convert_dir == 'a', force_overwrite)) + if (!process_resources(input_file_name, specific_file_name, + convert_dir == 'a', force_overwrite)) { perror("Processing failed"); exit(1); -- Dimi.

Sept. 30, 2003

PATCH: tools/make_requests (was: PATCH: server/trace.c cleanup)

by Gerald Pfeifer

On Tue, 30 Sep 2003, Alexandre Julliard wrote: > That code is generated, there's no point in fixing it. You need to > change tools/make_requests. Here we go. ;-) (I never had a look at this script before, and it's not documented too much, but it seems I found the right place to patch nevertheless, and the script definitely seems nice.) Gerald ChangeLog: Properly handle time_t in DO_DUMP_FUNC. Index: make_requests =================================================================== RCS file: /home/wine/wine/tools/make_requests,v retrieving revision 1.36 diff -u -3 -p -r1.36 make_requests --- make_requests 2 Apr 2003 22:48:59 -0000 1.36 +++ make_requests 30 Sep 2003 17:57:53 -0000 @@ -269,6 +269,9 @@ sub DO_DUMP_FUNC push @trace_lines, " fprintf( stderr, \" $var=$formats{$type}"; push @trace_lines, "," if ($#_ > 0); push @trace_lines, "\", "; + # In the case of time_t we need to cast the parameter to + # long to match the associated "%ld" printf modifier. + push @trace_lines, "(long)" if( $type eq "time_t" ); push @trace_lines, "req->$var );\n"; } }

Sept. 30, 2003

Re: PATCH: server/trace.c cleanup (RETRY)

by Gerald Pfeifer

On Tue, 30 Sep 2003, Alexandre Julliard wrote: > That code is generated, there's no point in fixing it. You need to > change tools/make_requests. Thanks for the hint; I'll give it a try. However, server/registry.c doesn't seem to be generated, so I believe the patch below is fine as is? Gerald -------- forwarded message -------- From: Gerald Pfeifer <gerald(a)pfeifer.com> To: wine-patches(a)winehq.com Date: Sun, 21 Sep 2003 22:36:05 +0200 (CEST) Subject: PATCH: server/registry.c Similar to the previous one. Gerald ChangeLog: Properly cast parameters to fprintf(...,"%ld",...) to long. Index: registry.c =================================================================== RCS file: /home/wine/wine/server/registry.c,v retrieving revision 1.53 diff -u -3 -p -r1.53 registry.c --- registry.c 7 Sep 2003 05:08:14 -0000 1.53 +++ registry.c 21 Sep 2003 20:35:08 -0000 @@ -265,7 +265,7 @@ static void save_subkeys( const struct k { fprintf( f, "\n[" ); if (key != base) dump_path( key, base, f ); - fprintf( f, "] %ld\n", key->modif ); + fprintf( f, "] %ld\n", (long)key->modif ); for (i = 0; i <= key->last_value; i++) dump_value( &key->values[i], f ); } for (i = 0; i <= key->last_subkey; i++) save_subkeys( key->subkeys[i], base, f );

Sept. 30, 2003

Re: shlwapi 405/406

by Alexandre Julliard

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > Hmm, I think any programmer who thinks a static function in one of > the implementation files of a given dll can possibly be part of the > exported Win32 API has larger problems than just confusion over what > the API covers ... Static functions can definitely be part of the API. The best example is function pointers in COM interfaces. -- Alexandre Julliard julliard(a)winehq.com

Sept. 30, 2003