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

Re: Regression in wineconsole

by Eric Pouech

> In the past (upto the middle of November) wineconsole was quite happy > with "clean 10". Does anyone have a suggestion on what should I do. does the font server use the old fonts ? or only the newest ones ? the issue we have here is with freetype (or the wine interface) which doesn't see fixed size fonts as fixed size fonts A+

Dec. 6, 2002

Winedbg and gcc 3.2

by Alberto Massari

Hi everybody, a few weeks ago I changed my build machine from a RedHat 7.2 + gcc 2.9x to a Mandrake 9.0 + gcc 3.2, and I noticed that I was unable to debug the Wine libraries (I got messages like "No debug information in ELF '/usr/local/lib/wine/xxxx.dll.so'), while gdb worked just fine. So today I digged a little bit and I found that winedbg supports the "stabs" debug format, and looks for the ".stabs" segment in the binary. The copy of gcc 3.2 I have (gcc-3.2-1mdk) doesn't produce this segment unless I replace the -g option with -gstabs. My questions at this point are: - is this behavior typical of every gcc 3.2? or it's only Mandrake that does it? - is somebody going to change the "configure" script to detect such a situation and specify "-gstabs" instead of "-g"? (I would volunteer myself, but I am not expert in this field... I just hacked my copy to make it work in my tree) - or should winedbg be improved to understand more debug formats, so that it can handle whatever informations the "-g" option spits out? Thanks, Alberto P.S. Please don't flame me if I said something naive....

Dec. 6, 2002

Re: strcat+strcat+strcat == baaad"

by Dimitrie O. Paun

On December 5, 2002 11:16 am, Alexandre Julliard wrote: > It's the kind of thinking that leads to having an exception > handler inside strlen() like Windows does. It's just plain wrong. <nod/>. This is generally true for other things as well: 1. Many places in our code where we have invariant like pointer p is never NULL, yet we always have: if (!p) return NULL; /* or whatever error condition */ Such a check is harmful (hides bugs), slow (useless runtime check), bloat (more generated code), ugly (clutters the code), at the very least. Just Don't Do It (TM) -- let the code crash. 2. ZeroMemory when we don't need to, when we pass struct internally, yet same functions can be called externally with no guarantee that the struct has unused field zeroed out. 3. In general, we have all sort of 'defensive programming' checks for invariants. Problem is, we never going to catch bugs in this area this way. Just use assert() if you feel a check is needed. In short, this defensive programming crap is just that: crap. -- Dimi.

Dec. 6, 2002

Re: Registering DLL's

by Dimitrie O. Paun

On December 6, 2002 10:18 am, you wrote: > You guys have got the ReactOS regedit based on Wine Regedit although it is > read only atm. If someone is still planning on adopting it, then that will > solve this part of the problem. I was looking into it, but it requires a bit of work until is ready for integration. However, I don't think this is what Alexandre had in mind. Jaco was working on a cool too, I don't know what the status of that is: http://www.dssd.ca/wine/winecfg1.png http://www.dssd.ca/wine/winecfg2.png -- Dimi.

Dec. 6, 2002

Re: Registering DLL's

by Steven Edwards

--- Alexandre Julliard <julliard(a)winehq.com> wrote: > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > C.1 Merge configuration into the registry > > > > Any gochas? What would it take? > > Not much, it basically means making the Wine/Config branch into a > normal registry branch. It's more a user interface issue, we need > tools to edit it because you don't want to make users dig through > system.reg manually. You guys have got the ReactOS regedit based on Wine Regedit although it is read only atm. If someone is still planning on adopting it, then that will solve this part of the problem. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Dec. 6, 2002

RE: Cabinet FDICreate()

by Patrik Stridvall

> The MSXML4 .msi package dies with : > > fixme:cabinet:FDICreate (0x525bee, 0x525bf3, 0x52668d, 0x525e99, > 0x525bf8, 0x525fb9, 0x526042, -1, 0x54a2a8): stub > > Is this scheduled to be implemented as part of the cabinet merge in > work? IIRC Greg Turner volunteer to do it however, also said I might take a while before getting around to do it. I, who did the stub, personally, haven't got much time to do it either. So don't hold you breath, unless you volunteer. Implementing it is not that hard I think especially since we got cabextract licensed under the LGPL for us. If not, install and use the native cabinet.dll instead.

Dec. 6, 2002

Re: Unicode question

by Ove Kaaven

On Fri, 6 Dec 2002, Rolf Kalbermatter wrote: > I have finally found most of the string manipulation functions which work > for Unicode but when it comes down to simple character comparison I'm a > little bit in the dark here. > > Some code snippets elsewhere in wine make me believe that for the english > charset WCHAR == char is actually mostly true. However I wonder if this > can be relied on in code. For instance the Unicode version of ParseField > would in that case look like this but I really want the opinion of someone > else on, if the code > > if (*src++ == ',') nField--; > > is actually working as expected on all systems independent of the actually > used charsets for the local languages. It should. All the current code in Wine assumes that ASCII is the common denominator on any system it's built on (a reasonable assumption, pretty much all charsets used today incorporate ASCII); porting Wine to a non-ASCII system is going to be next to impossible. Still, the code above should work in any case as long as the *compiler* respects ASCII (since ASCII is a subset of Unicode), it doesn't matter what charset the actual *user* use.

Dec. 6, 2002

what to do with include/wine/obj_base.h?

by Ove Kaaven

I've submitted a patch to move the API prototypes out of obj_base.h, and I'd now be ready to submit unknwn.idl and unknwn.h, which would also supersede the interfaces defined in there, but I'm unsure about what to do with the remainder of it, namely the ICOM_* macros in there. Note that there's a shortcoming of those macros, they don't handle array arguments. Such arguments are binary-compatible with pointer arguments though, so it's not a serious shortcoming for Wine and widl (which could easily convert array args in IDL to pointer args in C), but it's a little ugly and may have source-compatibility issues if widl is used by Winelib code that implements interfaces with such method args. There are standard COM interfaces with this problem too, e.g. IPropertyStorage, but since such interfaces are implemented by Wine and not by app code, there's unlikely to be source-compatibility issues there. So the options include 1) keep using obj_base.h as it is, let widl use those macros as is (and convert array args to pointer args), include it into unknwn.h 2) move ICOM macros to include/objbase.h, and dispose of obj_base.h 3) make widl use the MS-style macros in objbase.h (but I'm not sure what to do about ICOM_MSVTABLE_COMPAT and ICOM_USE_COM_INTERFACE_ATTRIBUTE in this case) 4) make widl not use macros at all, but emit full C and C++ definitions directly (this is what midl.exe does, it seems) 5) make widl support any of the above with a command-line option, so that Wine headers uses 1 or 2, while Winelib apps get to use 3 or 4. 6) redesign the ICOM macros (but I doubt anyone's going to volunteer for that unless tied to a chair supervised by an ancient master of torture with a cat-o'-nine-tails in his toolbox, there's too much code to change)

Dec. 6, 2002

Cabinet FDICreate()

by Mike Hearn

Hi, The MSXML4 .msi package dies with : fixme:cabinet:FDICreate (0x525bee, 0x525bf3, 0x52668d, 0x525e99, 0x525bf8, 0x525fb9, 0x526042, -1, 0x54a2a8): stub Is this scheduled to be implemented as part of the cabinet merge in work? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Dec. 6, 2002

Re: Unicode question

by Alberto Massari

Hi Rolf, your code should work fine. The beauty of Unicode characters is that you are guaranteed that their size is always the same (well, this would be correct if you use 32-bit Unicode characters, aka UCS-4; but everybody settles for UCS-2, that uses 16-bit characters, and works for almost all languages in the world). So, once you have a WCHAR (=unsigned int), you can use the ++ and -- operator and you know you are going to the next or previous character; on the other hand, using ++ and -- on a char* buffer doesn't guarantee you that you are seeing the next character, as you can be looking at the second byte of a multi-byte character. This is the reason why string manipulation routines should be done in Unicode... Alberto

Dec. 6, 2002

Unicode question

by Rolf Kalbermatter

Hello, In trying to get shell32 a little bit more Unicodified I came across this function ParseFieldA which is taken from shellord.c. I'm quite unfamiliar with Unicode so I still have to learn a lot. I have finally found most of the string manipulation functions which work for Unicode but when it comes down to simple character comparison I'm a little bit in the dark here. Some code snippets elsewhere in wine make me believe that for the english charset WCHAR == char is actually mostly true. However I wonder if this can be relied on in code. For instance the Unicode version of ParseField would in that case look like this but I really want the opinion of someone else on, if the code if (*src++ == ',') nField--; is actually working as expected on all systems independent of the actually used charsets for the local languages. And has anyone a good idea what the semi-stub would mean for this function? Maybe that it should ignore commas in quoted strings? /************************************************************************* * ParseFieldW [internal] * * copies a field from a ',' delimited string * * first field is nField = 1 */ DWORD WINAPI ParseFieldW(LPCWSTR src, DWORD nField, LPWSTR dst, DWORD len) { WARN("(%s,0x%08lx,%p,%ld) semi-stub.\n", debugstr_w(src), nField, dst, len); if (!src || !src[0] || !dst || !len) return 0; /* skip n fields delimited by ',' */ while (nField > 1) { if (*src == 0x0) return FALSE; if (*src++ == ',') nField--; } /* copy part till the next ',' to dst */ while ( *src != 0x0 && *src != ',' && (len--)>0 ) *(dst++) = *(src++); /* finalize the string */ *dst = 0x0; return TRUE; } Rolf Kalbermatter

Dec. 6, 2002

Re: wine/tools Makefile.in .cvsignore mingwrap.c

by Dimitrie O. Paun

On December 5, 2002 02:12 pm, Alexandre Julliard wrote: > ChangeSet ID: 6503 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/12/05 13:12:13 > > Modified files: > tools : Makefile.in .cvsignore > Added files: > tools : mingwrap.c > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > New MinGW wrapper that makes gcc on Linux behave like MinGW on > Windows, using the Wine headers. I'm afraid this (from Makefile.in) can't quite work: mingwrap: mingwrap.o $(CC) $(CFLAGS) -DINCLUDEDIR="$(includedir)" -o mingwrap mingwrap.o You're passing the -D to an already compiled file... -- Dimi.

Dec. 6, 2002

Re: Loading Autorun.inf on CD's

by Dustin Navea

Question is, does it work with wine? If so, how? I must be blind because I dont see any documentation on how to set it up to load wine when it calls an exe. Plus the method I was speaking about above includes loading up a .inf file, not just autorun.exe... -Dustin ----- Original Message ----- From: "Sylvain Petreolle" <spetreolle(a)yahoo.fr> To: "Dustin Navea" <speeddymon(a)sbcglobal.net>; "Wine Developers" <wine-devel(a)winehq.com> Sent: Friday, December 06, 2002 12:20 AM Subject: Re: Loading Autorun.inf on CD's > Doesnt exist that already ? > http://freshmeat.net/projects/autorun/ > http://parzelle.de/Linux/Applications/kautorun > > > Now that got me thinking, wine doesnt have any method to check .inf > > files > > right now and load an installer if it finds one on a CD. > > ===== > Sylvain Petreolle > spetreolle(a)users.sourceforge.net > Fight against Spam ! http://www.euro.cauce.org/en/index.html > ICQ #170597259 > > "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. > > ___________________________________________________________ > Soyez solidaire soutenez l'action du Téléthon avec Yahoo! France. > http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_id =1309 >

Dec. 6, 2002

[RFC] winewrap

by Dimitrie O. Paun

Hi folks, Here is the first cut at winewrap, as described here: http://www.dssd.ca/wine/Winelib-Apps.html What it does at the moment: -- invokes winebuild to create the .spec.c file -- compiles the .spec.s file -- links in everything, and generates the .exe.so file What remains to be done: -- generate the actual executable. One possible option is to modify wineapploader so we simply symlink to it. I have a version of this around. Is this acceptable? Comments welcomes. /* * Wine wrapper: takes care of internal details for linking. * * Copyright 2002 Dimitrie O. Paun * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include "config.h" #include "wine/port.h" #include <stdio.h> #include <string.h> #include <stdarg.h> #include <stdlib.h> #include <sys/param.h> #include <sys/wait.h> #ifdef HAVE_UNISTD_H # include <unistd.h> #endif #ifndef WINEDLLS #define WINEDLLS "/usr/local/lib/wine" #endif static char *output_name; static char **lib_files, **res_files, **obj_files; static int nb_lib_files, nb_res_files, nb_obj_files; void error(const char *s, ...) { va_list ap; va_start(ap, s); fprintf(stderr, "Error: "); vfprintf(stderr, s, ap); fprintf(stderr, "\n"); va_end(ap); exit(2); } char *strmake(const char *fmt, ...) { int n, size = 100; char *p; va_list ap; if ((p = malloc (size)) == NULL) return NULL; while (1) { va_start(ap, fmt); n = vsnprintf (p, size, fmt, ap); va_end(ap); if (n > -1 && n < size) return p; if (n > -1) size *= 2; if ((p = realloc (p, size)) == NULL) return NULL; } } void spawn(char *const argv[]) { int pid, status, i; for(i = 0; argv[i]; i++) printf("%s ", argv[i]); printf("\n"); if ((pid = fork()) == 0) execvp(argv[0], argv); else if (wait(&status) > 0) { if (WEXITSTATUS(status) == 0) return; else error("%s failed.", argv[0]); } perror(0); exit(1); } int main(int argc, char **argv) { char *library = 0; int i, j, len, is_object, no_opt = 0; char cmd[PATH_MAX]; char **spec_args, **comp_args, **link_args; for (i = 1; i < argc; i++) { if (!no_opt && argv[i][0] == '-') { switch (argv[i][1]) { case 'o': if (argv[i][2]) output_name = strdup(argv[i]+ 2); else if (i + 1 < argc) output_name = strdup(argv[++i]); else error("The -o switch takes an argument\n."); len = strlen(output_name); if (len > 4 && strcmp(output_name + len - 4, ".exe") == 0) output_name[len - 4] = 0; break; case 'l': if (argv[i][2]) library = argv[i]+ 2; else if (i + 1 < argc) library = argv[++i]; else error("The -l switch takes an argument\n."); if (strcmp(library, "winspool") == 0) library = "winspool.drv"; lib_files = realloc( lib_files, (nb_lib_files+1) * sizeof(*lib_files) ); lib_files[nb_lib_files++] = strdup(library); break; case '-': if (argv[i][2]) error("No long option supported\n"); no_opt = 1; break; default: error("Unknown option -%c\n", argv[i][1]); } continue; } /* it's a filename, not an option: test if it is a resource */ snprintf(cmd, sizeof(cmd), "readelf -V %s >/dev/null 2>/dev/null", argv[i]); is_object = (system(cmd) == 0); /* add it to its respective list */ if (is_object) { obj_files = realloc( obj_files, (nb_obj_files+1) * sizeof(*obj_files) ); obj_files[nb_obj_files++] = strdup(argv[i]); } else { res_files = realloc( res_files, (nb_res_files+1) * sizeof(*res_files) ); res_files[nb_res_files++] = strdup(argv[i]); } } /* build winebuild's argument list */ spec_args = malloc( (nb_lib_files + nb_obj_files + nb_res_files * 2 + 20) * sizeof (char *) ); j = 0; spec_args[j++] = "winebuild"; spec_args[j++] = "-fPIC"; spec_args[j++] = "-o"; spec_args[j++] = strmake("%s.spec.c", output_name); spec_args[j++] = "--exe"; spec_args[j++] = strmake("%s.exe", output_name); spec_args[j++] = "-m"; spec_args[j++] = "gui"; for (i = 0; i < nb_res_files; i++) { spec_args[j++] = "-r"; spec_args[j++] = res_files[i]; } for (i = 0; i < nb_obj_files; i++) spec_args[j++] = obj_files[i]; spec_args[j++] = "-L" WINEDLLS; for (i = 0; i < nb_lib_files; i++) spec_args[j++] = strmake("-l%s", lib_files[i]); spec_args[j++] = "-lmsvcrt"; spec_args[j] = 0; /* build gcc's argument list */ comp_args = malloc (20 * sizeof (char *) ); j = 0; comp_args[j++] = "gcc"; comp_args[j++] = "-fPIC"; comp_args[j++] = "-c"; comp_args[j++] = strmake("%s.spec.c", output_name); /* build ld's argument list */ link_args = malloc( (nb_obj_files + 20) * sizeof (char *) ); j = 0; link_args[j++] = "gcc"; link_args[j++] = "-shared"; link_args[j++] = "-Wl,-Bsymbolic"; link_args[j++] = "-lwine"; link_args[j++] = "-lm"; link_args[j++] = "-o"; link_args[j++] = strmake("%s.exe.so", output_name); link_args[j++] = strmake("%s.spec.o", output_name); for (i = 0; i < nb_obj_files; i++) link_args[j++] = obj_files[i]; link_args[j] = 0; /* run winebuild to get the .spec.c file */ spawn(spec_args); /* compile the .spec.c file */ spawn(comp_args); /* run gcc to link */ spawn(link_args); return 0; } -- Dimi.

Dec. 6, 2002

Re: Loading Autorun.inf on CD's

by Sylvain Petreolle

Doesnt exist that already ? http://freshmeat.net/projects/autorun/ http://parzelle.de/Linux/Applications/kautorun > Now that got me thinking, wine doesnt have any method to check .inf > files > right now and load an installer if it finds one on a CD. ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

Dec. 6, 2002

Re: Loading Autorun.inf on CD's

by Dustin Navea

----- Original Message ----- From: "Dustin Navea" <speeddymon(a)sbcglobal.net> To: "Wine Developers" <wine-devel(a)winehq.com> Sent: Thursday, December 05, 2002 11:37 PM Subject: Loading Autorun.inf on CD's > Hey guys, > > I was browsing through the forums on franksworld.net and noticed this post: > > http://www.frankscorner.org/wineforum/viewthread.php?tid=158 > > Now that got me thinking, wine doesnt have any method to check .inf files > right now and load an installer if it finds one on a CD. I was wondering, > what do you guys think it would take to get that supported? I know that we > would probably have to associate .inf files with wine and/or have some sort > of a wine cd detector that actively monitors cd's for autorun files, but > what would need to be added to wine itself to parse an autorun file, so that > we could create the loader later? > > -Dustin > I just thought of one thing we could do.. I bet we could make a bash script that gets called by wine (is that possible) that parses the config to check the cd path first and then checks the cd path for any autorun files, if one exists, it parses it and loads up the correct binary. Now, if that isnt a good idea, or someone thinks we should do it in the code, feel free to flame me. We still would have to have an active monitoring program though that watches for cd's to be inserted and then that calls up the script, but we could always ask the autofs guys if they would be willing to add wine load support for inf files to their perl scripts, so that if a user has autofs installed, it uses wine.. --Dustin P.S. Call me crazy if you want to, but it was just an idea..

Dec. 5, 2002

Loading Autorun.inf on CD's

by Dustin Navea

Hey guys, I was browsing through the forums on franksworld.net and noticed this post: http://www.frankscorner.org/wineforum/viewthread.php?tid=158 Now that got me thinking, wine doesnt have any method to check .inf files right now and load an installer if it finds one on a CD. I was wondering, what do you guys think it would take to get that supported? I know that we would probably have to associate .inf files with wine and/or have some sort of a wine cd detector that actively monitors cd's for autorun files, but what would need to be added to wine itself to parse an autorun file, so that we could create the loader later? -Dustin

Dec. 5, 2002

[Alsa] A simple test for IDirectSound.GetCaps.

by Sylvain Petreolle

Running the dsound test using winealsa.drv, the program hangs and try to call the debugger. [syl(a)snoop dsound]$ make test make[1]: Entre dans le répertoire `/home/wine/dlls/dsound/tests' ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c && touch dsound.ok err:ntdll:RtlpWaitForCriticalSection section 0x400ec230 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=0876cdc8 wine: Unhandled exception, starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x400ec230 "../../loader/module.c: loader_section" wait timed out, retrying (60 sec) tid=0876cdc8 err:seh:EXC_DefaultHandling Unhandled exception code c0000194 flags 0 addr 0x400bb478 make[1]: Quitte le répertoire `/home/wine/dlls/dsound/tests' According to http://www.delphifaq.com/fq/q1061.shtml, exception c0000194 is STATUS_POSSIBLE_DEADLOCK. How could I debug the tests ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

Dec. 5, 2002

Re: GDI RestoreDC()

by Francois Gouget

On 5 Dec 2002, Mike Hearn wrote: [...] > I can't figure out what ffffffff would be as an int though :( Would it > be negative or positive? For a 32 bit signed int, 0xffffffff == -1. See: http://burks.brighton.ac.uk/burks/foldoc/42/120.htm -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 145 = 1! + 4! + 5!

Dec. 5, 2002

Re: WineBuild/WineLib <-> MFC

by Francois Gouget

jaymz(a)free.fr wrote: [...] > What's the exact syntact to correctly export class static variable from > a dll ? Exporting a variable is not the problem, what you did is fine. It will work if you try to access this variable from a native Windows dll. The problem is that winebuild does not know how to *import* a variable from another builtin library. For more details see this thread: http://www.winehq.com/hypermail/wine-devel/2002/12/0005.html That means you have to link with the MFC library in the Unix sense to get these variable references resolved correctly. -- Francois Gouget fgouget(a)codeweavers.com

Dec. 5, 2002

Re: [RFC] wrc & windres

by Dimitrie O. Paun

On December 5, 2002 12:07 pm, Alexandre Julliard wrote: > But maybe a better approach would be to simply output the .res > into a .o and have winebuild check the file header to recognize when > an object file is a .res in disguise; this way you don't need an > intermediate .res. I thought about that too, but I was a bit worried to bend things this much. But it's certainly simple to implement, and avoids a bunch of problems. Moreover, on the outside chance someone tries to use the .o files as object file, ld will complain about that, so there's no danger to it. I'll proceed this way. > > BTW, storing the .res content in the .o file has the small benefit > > that resource compilation happens at the expected place in the > > build process, but I guess we can defer it to winewrap, no problem. > > Not sure what you mean here; the .res is already compiled anyway. Indeed, if we go by the above. But if I were to simply touch myfile.o when myfile.rc was given to wrc, then in winewrap I would have had the .rc -> .res conversion. But nevermind, this is no longer an issue. -- Dimi.

Dec. 5, 2002

Re: [RFC] wrc & windres

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Well, that's the idea, really. But I have to find a way to mark the > special .o files somehow. I don't think just touching them works, > because of possible separate source and build trees. I think it would work, the .res is going to be in the build tree too. You could also create a symlink if you are concerned about that. But maybe a better approach would be to simply output the .res into a .o and have winebuild check the file header to recognize when an object file is a .res in disguise; this way you don't need an intermediate .res. > BTW, storing the .res content in the .o file has the small benefit > that resource compilation happens at the expected place in the > build process, but I guess we can defer it to winewrap, no problem. Not sure what you mean here; the .res is already compiled anyway. -- Alexandre Julliard julliard(a)winehq.com

Dec. 5, 2002

Re: [RFC] wrc & windres

by Dimitrie O. Paun

On December 5, 2002 11:19 am, Alexandre Julliard wrote: > If you can make it clean enough sure; but I'm not convinced this is > possible, especially if you are playing with ELF sections. If it's To be honest, I've never worked directly with ELF section, it was just an idea to store that info somewhere. > going to be an awful hack then I much prefer the approach of creating > a dummy .o and handling that in the wrapper tool. Well, that's the idea, really. But I have to find a way to mark the special .o files somehow. I don't think just touching them works, because of possible separate source and build trees. At a minimum I have to store the .res/.rc file name in it, and I figured if I do that, I might as well store the .res content. But if you have a better suggestion on how to store some info in a .o file that we can than easily detect in the winewrap tool, I'm all ears. BTW, storing the .res content in the .o file has the small benefit that resource compilation happens at the expected place in the build process, but I guess we can defer it to winewrap, no problem. > It's still ugly but at least it's much less complexity to maintain > for such an IMO minor feature. It does look like a minor feature, but it's probably less work than to mess around with the Makefiles of say Mozilla. If this is ugly, the alternative is plain nasty. :) -- Dimi.

Dec. 5, 2002

Re: [RFC] wrc & windres

by Joerg Mayer

On Thu, Dec 05, 2002 at 09:51:18AM -0600, Jeff Smith wrote: > Here is an alternative idea for dealing with command-line > incompatibility: create a link 'windres' pointing to 'wrc'. > In the program, we could determine how the program was > invoked and handle the command-line options accordingly. I like this hack much better than the previous one :) Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Dec. 5, 2002

Re: [RFC] wrc & windres

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > So now the big question: Alexandre, are patches that implement these > ideas acceptable? If you can make it clean enough sure; but I'm not convinced this is possible, especially if you are playing with ELF sections. If it's going to be an awful hack then I much prefer the approach of creating a dummy .o and handling that in the wrapper tool. It's still ugly but at least it's much less complexity to maintain for such an IMO minor feature. -- Alexandre Julliard julliard(a)winehq.com

Dec. 5, 2002

Re: strcat+strcat+strcat == baaad"

by Alexandre Julliard

vkxzjq6lg(a)cswebmail.com writes: > Wine also needs to remember that hostile Windows program developers may > deliberately try to break programs under wine by passing invalid parameters. > Even if wine doesn't check all of those, it shouldn't die when it happens. Yes it should, just like glibc should crash if you pass it bad pointers. What you are suggesting is the Microsoft approach: swipe bugs under the rug and let the app stumble along a bit further before dying, possibly corrupting files in the process. It's the kind of thinking that leads to having an exception handler inside strlen() like Windows does. It's just plain wrong. (Of course we have to be compatible, and we have to hide bugs where actual applications depend on Windows doing it; but that doesn't mean it's the right philosophy) -- Alexandre Julliard julliard(a)winehq.com

Dec. 5, 2002

Re: [RFC] wrc & windres

by Dimitrie O. Paun

On December 5, 2002 10:51 am, Jeff Smith wrote: > This should technically work, unless we find some reason > to 'mix' command line options, in which case we we would > have to start 'blending' the two syntaxes. Please note > that I am not familiar with the command line options of > either program. If there more many conflicts, I'd agree with you, but ATM at the moment it looks real simple to just mix the commands (that is, also support windres commands in wrc). > <snip> > > >The modification will typically be: > >-WINDRES=windres > >+WINDRES=wrc > > WINDRES would not have to be changed using this method. Creating a symlink is orthogonal to this problem. Even if we mix the commands, we can still create the symlink, but I don't think it's really necessary. In fact, we shouldn't probably do it, as windres can be compiled to exists on Linux also. -- Dimi.

Dec. 5, 2002

Re: [RFC] wrc & windres

by Jeff Smith

>From: "Dimitrie O. Paun" <dpaun(a)rogers.com> >Hi folks, > >As we discussed here a few weeks ago, there is good reason >to have a windres compatible mode for wrc. <snip> >That being said, what would it take to (1) keep the current wrc >behavior, and (2) make it compatible with windres? Here is an alternative idea for dealing with command-line incompatibility: create a link 'windres' pointing to 'wrc'. In the program, we could determine how the program was invoked and handle the command-line options accordingly. This should technically work, unless we find some reason to 'mix' command line options, in which case we we would have to start 'blending' the two syntaxes. Please note that I am not familiar with the command line options of either program. <snip> >The modification will typically be: >-WINDRES=windres >+WINDRES=wrc WINDRES would not have to be changed using this method. -- Jeff S. _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

Dec. 5, 2002

Re: possible memory corruption

by steve.lustbader＠philips.com

>>>>>> "steve" == steve lustbader <steve.lustbader(a)philips.com> writes: > > steve> When I try to load a window in my app that has a treeview in it, > steve> it crashes immediately, before the window even gets displayed. > steve> This is the end of the backtrace: > > Try running with native commctrl to see if the corruption comes from our > commctrl implementation. Then run with --debugmsg +relay,+heap. Wine will > check on every heap manipulation to see if the heap is still okay. Then >look what corrupted the heap. It works fine with a native (WinXP) comctl32.dll. I'll post the +relay,+heap output shortly. -Steve

Dec. 5, 2002

Re: possible memory corruption

by Uwe Bonnes

>>>>> "steve" == steve lustbader <steve.lustbader(a)philips.com> writes: steve> When I try to load a window in my app that has a treeview in it, steve> it crashes immediately, before the window even gets displayed. steve> This is the end of the backtrace: Try running with native commctrl to see if the corruption comes from our commctrl implementation. Then run with --debugmsg +relay,+heap. Wine will check on every heap manipulation to see if the heap is still okay. Then look what corrupted the heap. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 5, 2002

possible memory corruption

by steve.lustbader＠philips.com

When I try to load a window in my app that has a treeview in it, it crashes immediately, before the window even gets displayed. This is the end of the backtrace: 0x400d6377 (HEAP_FindFreeBlock+0x3b [heap.c:608] in libntdll.dll.so): movl 0x0(%edx),%eax 608 DWORD arena_size = (pArena->size & ARENA_SIZE_MASK) + Wine-dbg>bt Backtrace: =>0 0x400d6377 (HEAP_FindFreeBlock+0x3b(heap=0x41230000, size=0x108, ppSubHeap=0x406e1af4) [heap.c:608] in libntdll.dll.so) (ebp=406e1adc) 1 0x400d6df5 (RtlAllocateHeap+0x71(heap=0x41230000, flags=0xa, size=0x104) [heap.c:1028] in libntdll.dll.so) (ebp=406e1b04) 2 0x40b283e2 (COMCTL32_Alloc+0x4a(dwSize=0x104) [comctl32undoc.c:352] in comctl32.dll.so) (ebp=406e1b24) 3 0x40b732bb (TREEVIEW_UpdateDispInfo+0x227(infoPtr=0x41230838, wineItem=0x41232060, mask=0x1) [treeview.c:762] in comctl32.dll.so) (ebp=406e1ba4) 4 0x40b73d94 (TREEVIEW_InsertItemA+0x324(infoPtr=0x41230838, lParam=0x406e1be8) [treeview.c:1318] in comctl32.dll.so) (ebp=406e1bd8) 5 0x40b73eb6 (TREEVIEW_InsertItemW+0xb2(infoPtr=0x41230838, lParam=0x406e1f08) [treeview.c:1389] in comctl32.dll.so) (ebp=406e1c34) 6 0x40b79881 (TREEVIEW_WindowProc+0x6a5(hwnd=0x2006a, uMsg=0x1132, wParam=0x0, lParam=0x406e1f08) [treeview.c:5237] in comctl32.dll.so) (ebp=406e1c50) 7 0x408ec923 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=406e1c74) 8 0x408ec9ae (WINPROC_CallWndProc+0x82(proc=0x40b791dc, hwnd=0x2006a, msg=0x1132, wParam=0x0, lParam=0x406e1f08) [winproc.c:183] in user32.dll.so) (ebp=406e1ca4) I had thought originally that it might be a treeview problem, since the crash happens based on calls from treeview, but Dimi says that it's probably memory getting corrupted somewhere. What trace would be helpful to debug this? Thanks, Steve, PS - I had previously posted a +treeview trace a couple of weeks ago. Here it is again, just in case it's helpful: <App starting up> trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register trace:treeview:TREEVIEW_Register <I press button to open dialog containing treeview> trace:treeview:TREEVIEW_Create wnd 0x2006a, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_Create wnd 0x20068, style 40010027 trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_SetFont 0x3a6a 0 trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): <null item> trace:treeview:TREEVIEW_InsertItemA parent 0x41230a98 position 0xffff0002: '<callback>' trace:treeview:TREEVIEW_DoSetItem setting callback, item 0x41232060 trace:treeview:TREEVIEW_InsertItemA new item 0x41232060; parent 0x41230a98, mask 5 trace:treeview:TREEVIEW_GetNextItem flags:3, item 0x41232060;returns (nil) wine: Unhandled exception, starting debugger...

Dec. 5, 2002

Re: [RFC] wrc & windres

by Dimitrie O. Paun

On December 5, 2002 04:33 am, Dmitry Timoshkov wrote: > Only one small suggestion: instead of .wine.resources section > name use simple .rsrc, which should not conflict with anything else > in the ELF world and is just a native name for resources in the Win32 > world. Sure, this is no problem. I was thinking of a wine specific name because we don't put the resources in there as the native Win32 does, it's a Wine specific thing. Maybe in the future we will want to stick stuff in .o file in native format, and then we would use .rsrc, without conflicting with this method (and thus maintaining backwards compatibility). -- Dimi.

Dec. 5, 2002

GDI RestoreDC()

by Mike Hearn

Hi all, I think I've traced the problem with the Adobe SVG plugin not reliably rendering: This is from a good run (when I use an svg file I know will render OK): 080746b8:Call kernel32.LOCAL_Free(0000019f,00001aca) ret=40948f6b 080746b8:Ret kernel32.LOCAL_Free() retval=00000000 ret=40948f6b trace:gdi:GDI_FreeObject (0x1aca): leave 1 080746b8:Ret gdi32.DeleteObject() retval=00000001 ret=5300a17c 080746b8:Call gdi32.BitBlt(000008a8,00000000,00000000,0000008c,0000008c,00000ba0,00000000,00000000,00cc0020) ret=5300a1ae As you can see, it appears to perform the BitBlt call correctly, those parameters look correct. Here is the same section from a bad run: 080746b8:Call kernel32.LOCAL_Free(0000019f,00001ac2) ret=40948f6b 080746b8:Ret kernel32.LOCAL_Free() retval=00000000 ret=40948f6b trace:gdi:GDI_FreeObject (0x1ac2): leave 1 080746b8:Ret gdi32.DeleteObject() retval=00000001 ret=5301b3df 080746b8:Call gdi32.RestoreDC(000008a8,ffffffff) ret=53018c68 It doesn't call BitBlt at all, not now, not later, not at all. Instead, it calls RestoreDC for no apparently good reason. That last argument looks highly suspicious, in that MSDN says it's an int which when positive identifies a state and when negative identifies a "step", ie -1 would restore the last state from the stack. I can't figure out what ffffffff would be as an int though :( Would it be negative or positive? Either way, is this an intelligent sort of value for the parameter to have? The MSDN docs are here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcon… I can't figure out why it would suddenly call RestoreDC and then seemingly go off on a tangent (the traces match up until that point), rather than do a BitBlt like it's supposed to. The SVG files vary only in that the "good" one has some interactivity (but it's not triggered at startup). Does anybody have any ideas? I'm fresh out for today. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Dec. 5, 2002

Re: valgrind and wine

by Aric Stewart

Ok to get WINE to work at all i had to disable the sanity checks here is what Julian Steward send me on how to do that. >> ok here are the lines of the log. >> >> SYSCALL-POST[2403,1] read ( 5, 0x43CA2C7C, 64 ) --> 64 >> SYSCALL[2403,1](175): sigprocmask ( 2, 0x43CA2BE4, 0x0 ) >> SYSCALL[2403,1](123): modify_ldt ( 1, 0x43CA2D4C, 16 ) >> SYSCALL[2403,1](192): mmap2 ( 0x1000, 1110016, 7, 34, -1, 0 ) > > > Looks sensible to me. > > >> --2403-- post-syscall: >> --2403-- probable sanity check failure for syscall number 192 >> >> >> how would i go about disabling that sanity check. I scanned the code for >> a few minutes but it was not obvious to me. > > > At mc_main.c:2114 > make SK_(cheap_sanity_check) always return True. This was with 1.1.0 I have a very simple test program that only contained an edit control and i had that coming up with valgrind just fine. when i tried to valgrind Microsoft Word 2000 i had the exceptions thrown. I am very interested in what progress people make on this. I just have not had time to go any further on it. -aric Dan Kegel wrote: > Aric Stewart wrote: > >> I have actually worked a little with Julian Steward on this problem >> just before 1.1.0 I actually have a build of valgrind here on my >> laptop with works with very simple wine applications. I remember there >> was one hack i had to do to the valgrind source to disable some of its >> sanity checking. >> >> I could not get valgrind to work with more advanced wine programs >> because i kept getting >> >> trace:seh:EXC_RtlRaiseException code=eedfade flags=1 addr=0x402e1a30 >> >> if you want to work with valgrind i will did up how i turned off the >> sanity checking with 1.1.0 and see if you can get it working. > > > Yes, please do document how you got valgrind to start working > with Wine! Maybe somebody bright with time on their hands will > be able to solve the issue you ran into. > > Thanks, > Dan >

Dec. 5, 2002

RE: Remnants of -DSTRICT Conversion

by Patrik Stridvall

> Just a small request. Could someone write a script that would > remove one of > the last remnants of the -DSTRICT conversion. It is a little > issue with lots > of 0x%p's everywhere (mainly in NTDLL registry functions) > which need to be > replaced by just %p's. Sure here is the script: find . -name \*.c | xargs perl -i -pe 's/0x%p/%p/g' and as a bonus to Alexandre here is the patch. --8<--- *** strict * dlls/commdlg/filedlg95.c, dlls/ntdll/file.c, dlls/ntdll/heap.c, dlls/ntdll/misc.c, dlls/ntdll/nt.c, dlls/ntdll/om.c, dlls/ntdll/reg.c, dlls/ntdll/sec.c, dlls/ntdll/sync.c, loader/module.c, scheduler/process.c, scheduler/thread.c, win32/device.c: Replace 0x%p with %p.

Dec. 5, 2002

Remnants of -DSTRICT Conversion

by Robert Shearman

Hi all, Just a small request. Could someone write a script that would remove one of the last remnants of the -DSTRICT conversion. It is a little issue with lots of 0x%p's everywhere (mainly in NTDLL registry functions) which need to be replaced by just %p's. Thanks, Rob

Dec. 5, 2002

WineBuild/WineLib <-> MFC

by jaymz＠free.fr

Going further into the MFC dll handling, I raised the following issue: I have two dynamic libs (mfc.dll.so and myapp.dll.so), both loaded by the wrapper (myapp.exe.so). The problem is that global or static class variables are badly exported from mfc.dll.so to myapp.dll.so. Here's an example: In mfc.dll.so, let assume that I export a global integer variable named myVar. I add @ extern myVar myVar in mfc.dll.spec. When I do a GetProcAddress of myVar from the wrapper, the returned address is good, but when I link my application, myVar is undefined (WineBuild did not include it in myapp.dll.spec.c). If I add instead in the spec file something like @ stdcall myVar() myVar, it's still good when using GetProcAdress, I can now link my application, but at runtime, the address of the variable is not the good one, so I'm using corrupted data ! Therefore, when the app runs, all static data are in fact not or badly initialized and it crashes. What's the exact syntact to correctly export class static variable from a dll ? Thanks a lot for your attention.

Dec. 5, 2002

Re: [RFC] wrc & windres

by Dmitry Timoshkov

"Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > Conversion to .o files > ---------------------- > As Alexandre pointed out in here: > http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html > generating .o files in proper format is non-trivial. And since > I'm willing to do the work, there's no chance I'm going to propose > something difficult to implement! :) > > What I have in mind is quite simple: store the .res file, as a byte > array, in a .wine.resources ELF section, and have winebuild pick it > up from there (as an alternative to getting it directly from the > .res file, so current behavior is conserved). I have no objections to the most things, they look quite reasonable to me. Only one small suggestion: instead of .wine.resources section name use simple .rsrc, which should not conflict with anything else in the ELF world and is just a native name for resources in the Win32 world. -- Dmitry.

Dec. 5, 2002

[RFC] wrc & windres

by Dimitrie O. Paun

Hi folks, As we discussed here a few weeks ago, there is good reason to have a windres compatible mode for wrc. Needless to say, this will greatly ease porting apps that use windres to Winelib. More information about the issues at hand can be found in this thread: http://www.winehq.com/hypermail/wine-devel/2002/11/index.html#1518 These messages in particular deal with this problem: http://www.winehq.com/hypermail/wine-devel/2002/11/1546.html http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html http://www.winehq.com/hypermail/wine-devel/2002/11/1551.html http://www.winehq.com/hypermail/wine-devel/2002/11/1552.html http://www.winehq.com/hypermail/wine-devel/2002/11/1555.html That being said, what would it take to (1) keep the current wrc behavior, and (2) make it compatible with windres? First, windres supports any conversions between .rc, .res, .o files, whereas wrc supports only .rc -> .res. It would be interesting (from the Winelib point of view) to also support .rc and .res -> .o. The other transformations supported by windres (.o -> .res -> .rc) are not as interesting, as they are not used in the build process. With that in mind, what do we need to do to have said compatibility? Well there are two things: 1. Support windres command line options 2. Add conversion of .rc and .res to .o I will treat each of these below. Command line compatibility -------------------------- Luckily, there is only one (seldom used) option that conflicts: -I. Moreover, it has a long format name in windres as well, which can be used instead. In other words, it should be very simple to add support for the windres options to wrc (most of them will just get ignored). In other words we can support windres's options while keeping full backwords compatibility. Having this compatibility makes sense as long as we support the conversion to .o files as well. Assuming we can do that, I would say this is something we should have. Conversion to .o files ---------------------- As Alexandre pointed out in here: http://www.winehq.com/hypermail/wine-devel/2002/11/1550.html generating .o files in proper format is non-trivial. And since I'm willing to do the work, there's no chance I'm going to propose something difficult to implement! :) What I have in mind is quite simple: store the .res file, as a byte array, in a .wine.resources ELF section, and have winebuild pick it up from there (as an alternative to getting it directly from the .res file, so current behavior is conserved). With these two changes, we eliminate the biggest nastiness of getting apps compiled with Winelib. The modification will typically be: -WINDRES=windres +WINDRES=wrc Moreover, the solution is: o Simple to implement o Fully backwards compatible with current Wine practice o Fully compatible with Win32 apps using the MinGW toolchain o Supports multiple resource files, etc. So now the big question: Alexandre, are patches that implement these ideas acceptable? Sorry for the long message, and thanks for reading this far. -- Dimi.

Dec. 5, 2002

re: Dll separation question

by Dan Kegel

Martin.Wilck(a)fujitsu-siemens.com wrote: > when writing code for DLL X, which functions from other DLLs may I call? As a Wine outsider, let me make a wild guess: To a first approximation, a nice way of thinking about it might be Write new DLLs using only published Microsoft APIs already implemented in other Wine DLLs. Ideally, new DLLs would work as replacements if compiled and run on a real Windows box. (although of course a whole lot of DLLs probably can't meet that strict definition.) - Dan

Dec. 5, 2002

RE: strcat+strcat+strcat == baaad"

by vkxzjq6lg＠cswebmail.com

> -----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin(a)winehq.com]On > Behalf Of Alexandre Julliard > Sent: Monday, December 02, 2002 9:03 AM > To: Shachar Shemesh > Cc: David Laight; David Fraser; Shachar Shemesh; Francois Gouget; > wine-devel(a)winehq.com > Subject: Re: strcat+strcat+strcat == baaad > > > Shachar Shemesh <winehebhaim(a)sun.consumer.org.il> writes: > > > I suggest implementing strlcat and strlcpy, as in OpenBSD. > I can write > > them, but I'm not sure where to place them. They should either be > > inlined (as in - implemented in an include file as a static > func), or > > in some library that will be linked (statically, I hope). Ideas? > > We don't need that, there are Windows API functions like lstrcpyn that > can be used for that. And in any case the right approach to writing > correct and secure code is not to truncate every string in sight to > some fixed buffer size; it's to make sure you allocate buffers of the > right size, and then you can use standard strcpy/strcat/sprintf/etc. > without worrying about lengths. You're right in theory but you're partly wrong in practice. Some time back I changed a shared library which had been used by ten or so developers for about eight years. I changed all possible unspecified length string copies and concatenates to versions with length limits. The programs using the library crashed less and displayed bad output less. Nobody noticed any speed change there might have been. We all had access to all of the source code involved and none of it was deliberately hostile to the library. The changes caught things the application programmers had missed in their testing and odd or corrupt data which ended up in the databases and made them less harmful. It was then also easier to follow up and fix "the program displayed xyz trash here" than it was to fix "my PC crashed" or "your program died". As programmers we all try to follow the limits and take care with buffer sizes and lengths and validation. We all fail and we all fail to catch every time we fail. That's just the nature of bugs and what we do. Buffer length issues are particularly hard to find and no realistic testing for a project the size of wine will catch them all. Wine also needs to remember that hostile Windows program developers may deliberately try to break programs under wine by passing invalid parameters. Even if wine doesn't check all of those, it shouldn't die when it happens. At least one company has an interest in breaking wine when running its programs and coding defensively is a prudent thing. Performance is unknown and won't be known until any possible shared function is implemented. Just announce it with the length parameter and do it with a define. Let the person who implements it decide whether to use strcat, strlcat or whatever in the first implementation, a function or inline or whatever. Six months or a year from now someone can try different implementations to see whether there is a speed difference. Then they can do something about selecting the most efficient. It's an issue, so deal with it, but there's no way to know today which will be the best implementation because it depends on the data and it is obvious that nobody knows the data well enough to be certain which will work best. If you don't like the strlcat implementeation, then you can try it with strcat and tell everyone how much faster it is when the l is ignored. Or not. Even if the l is eventually ignored in production, having it around offers the opportunity to turn it on with a compile option and/or to use it for assert sanity checking in a debug build. Finally, hi.:) Just started monitoring this list because I'm helping to get a Windows application (OzWin) working under wine. James Day ___________________________________________________ The ALL NEW CS2000 from CompuServe Better! Faster! More Powerful! 250 FREE hours! Sign-on Now! http://www.compuserve.com/trycsrv/cs2000/webmail/

Dec. 5, 2002

Re: Use COMSPEC command interpreter to run .bat files.

by Sylvain Petreolle

Ok, in this case we must change all stuff going into system32, as the sample config file specifies c:\windows\system as path too. > COMSPEC is set in directory.c to point to the windows system > directory, this is correct and should not be changed. The bug is that > wineinstall puts stuff in windows/system32 but specifies > windows/system as system dir in the config file. Index: wineinstall =================================================================== RCS file: /home/wine/wine/tools/wineinstall,v retrieving revision 1.49 diff -u -r1.49 wineinstall --- wineinstall 22 Nov 2002 20:44:13 -0000 1.49 +++ wineinstall 5 Dec 2002 02:07:10 -0000 @@ -132,14 +132,14 @@ link_app notepad "$CROOT/windows/notepad.exe" link_app regedit "$CROOT/windows/regedit.exe" link_app rundll32 "$CROOT/windows/rundll32.exe" - link_app wcmd "$CROOT/windows/system32/cmd.exe" - link_app control "$CROOT/windows/system32/control.exe" - link_app winhelp "$CROOT/windows/system32/help.exe" - link_app notepad "$CROOT/windows/system32/notepad.exe" - link_app progman "$CROOT/windows/system32/progman.exe" - link_app regsvr32 "$CROOT/windows/system32/regsvr32.exe" - link_app winemine "$CROOT/windows/system32/winmine.exe" - link_app winver "$CROOT/windows/system32/winver.exe" + link_app wcmd "$CROOT/windows/system/wcmd.exe" + link_app control "$CROOT/windows/system/control.exe" + link_app winhelp "$CROOT/windows/system/help.exe" + link_app notepad "$CROOT/windows/system/notepad.exe" + link_app progman "$CROOT/windows/system/progman.exe" + link_app regsvr32 "$CROOT/windows/system/regsvr32.exe" + link_app winemine "$CROOT/windows/system/winmine.exe" + link_app winver "$CROOT/windows/system/winver.exe" link_app uninstaller "$CROOT/windows/uninstall.exe" link_app winhelp "$CROOT/windows/winhelp.exe" link_app winhelp "$CROOT/windows/winhlp32.exe" ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

Dec. 4, 2002

Re: Registering DLL's

by Alexandre Julliard

"John K. Hohm" <jhohm(a)acm.org> writes: > I posted my idea for representing the registration data, accidentally from > "jhohm(a)happyhappy.dyndns.org" rather than my usual "jhohm(a)acm.org" (see > http://www.winehq.com/hypermail/wine-devel/2002/11/1409.html) but I haven't > gotten any responses, not even "looks fine" or "you are a moron". I guess I'll > just start submitting patches, then. Sorry, I must have missed that one. I don't really like the ASCII description of the registry keys; I think it would be better to do it at a more symbolic level. For instance you shouldn't hardcode the ASCII form of the CLSID, you should have some kind of "register CLSID" function that takes a CLSID and uses StringFromCLSID or whatever to create the corresponding registry key. -- Alexandre Julliard julliard(a)winehq.com

Dec. 4, 2002

Re: Registering DLL's

by John K. Hohm

Alexandre said: > Part of it should be done with DllRegisterServer, the rest can be > handled by the .inf script. And I think it's OK to add the necessary > DllRegisterServer entry points even if the native dll doesn't have > them. I'm glad you feel that way. I created bug 1117, "Make all Wine OLE DLLs self-registerable", and have been working on an implementation. For some reason I can't accept the bug; though I've tried several times, it stays at UNCONFIRMED. What to do about DLLs like ole32.dll that have a native DllRegisterServer but no corresponding DllUnregisterServer? I'm inclined to include it for completeness, though it's unlikely that anyone would ever want to unregister such a basic system DLL. I posted my idea for representing the registration data, accidentally from "jhohm(a)happyhappy.dyndns.org" rather than my usual "jhohm(a)acm.org" (see http://www.winehq.com/hypermail/wine-devel/2002/11/1409.html) but I haven't gotten any responses, not even "looks fine" or "you are a moron". I guess I'll just start submitting patches, then.

Dec. 4, 2002

Re: Wine Janitorial Projects

by Dimitrie O. Paun

On December 4, 2002 04:10 pm, Tony Lambregts wrote: > Well not fogetting about them is sort of what bugzilla is for. So I will > put them into Bugzilla with the keyword tasklist or tasklet as > appropriate. Bugzilla is good at tracking what needs to be done I think > it worked very well for -DSTRICT and these are very much like that. I think Bugzilla to be a very poor choice for a TODO list. Yeah, you can put it in there, but it's buried deep inside, and quite invisible. Please compare the list of tasks Bugzilla gives you to the pages I maintain. But really, this is my subjective opinion, and I am doing the work because I think Bugzilla is doing such a poor job for our TODO lists. Mind you, there's nothing one can do about my problems with Bugzilla: it is the very interface that's the problem. -- Dimi.

Dec. 4, 2002

Re: Registering DLL's

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > C.1 Merge configuration into the registry > > Any gochas? What would it take? Not much, it basically means making the Wine/Config branch into a normal registry branch. It's more a user interface issue, we need tools to edit it because you don't want to make users dig through system.reg manually. > C.5 Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg > > How should this be implemented? See Jeff's questions. Part of it should be done with DllRegisterServer, the rest can be handled by the .inf script. And I think it's OK to add the necessary DllRegisterServer entry points even if the native dll doesn't have them. > C.6 Write wine.inf script to setup a new Wine installation > > Do we have the code that executes .inf scripts? Is this one > just a matter of writing the scripts? It should be, setupapi should support everything we need for that. The main missing feature is the user interface feedback on the install progress, but we can probably live without that at first. -- Alexandre Julliard julliard(a)winehq.com

Dec. 4, 2002

Re: rpc_J_PL4

by Francois Gouget

On Wed, 4 Dec 2002, Greg Turner wrote: > On Wednesday 04 December 2002 02:31 am, Francois Gouget wrote: > > On Wed, 4 Dec 2002, Greg Turner wrote: > > [...] > > > > > Anyhoo, yes, I like something like what you are doing better, it > > > seems that if anything might just break out of the blue, it would > > > be the unicode version, right? So I should have done more like > > > that and that way wine doesn't lose the test. knowing there's no > > > crash involved makes the difference, I guess. > > > > Submitting for inclusion then :-) > > well, if it doesn't crash, I say we'd might as well run the tests but > show traces instead of "ok"'s on failure.... I really wish there was a > "whatever" macro that took the same syntax as "ok" but didn't > constitute failure (or is there? perhaps I should make one?) You probably don't really want to do that. If you replaced all the ok with this macro then it would be very hard to detect errors: one would have to manually inspect the test's output. What you may do is keep using the 'ok' macro but write the condition as follows: rc=function_to_test(); ok(rc==RPC_S_CANNOT_SUPPORT || <rest_of_orignal_condition>,"..."); But if the first call failed with RPC_S_CANNOT_SUPPORT it's probably not worth testing the others. Doing it this way also ensures that our implementation supports all the Unicode functions because if the first call succeeds then all subsequent Unicode calls must succeed too. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

Dec. 4, 2002

Re: rpc_J_PL4

by Greg Turner

On Wednesday 04 December 2002 02:31 am, Francois Gouget wrote: > On Wed, 4 Dec 2002, Greg Turner wrote: > [...] > > > Anyhoo, yes, I like something like what you are doing better, it > > seems that if anything might just break out of the blue, it would > > be the unicode version, right? So I should have done more like > > that and that way wine doesn't lose the test. knowing there's no > > crash involved makes the difference, I guess. > > Submitting for inclusion then :-) well, if it doesn't crash, I say we'd might as well run the tests but show traces instead of "ok"'s on failure.... I really wish there was a "whatever" macro that took the same syntax as "ok" but didn't constitute failure (or is there? perhaps I should make one?) Anyhow, until I make my mind up or whatever, Francois' patch is fine by me, considered rpc_J_PL4-r0 if it's OK to call it X11. -gmt

Dec. 4, 2002

Re: Wine Janitorial Projects

by Tony Lambregts

Dimitrie O. Paun wrote: >Hi folks, > >The Wine Janitorial Project section has grown to the point >where a separate page is warranted. It's been *greatly* >enhanced, hopefully making the tasks a lot more explicit, >easier to understand, and track. The first release of this >page is available at: > http://www.dssd.ca/wine/Wine-Janitorial-0.1.html > >As you are probably used to by now, the working version >can be found here: > http://www.dssd.ca/wine/Wine-Janitorial.html > >Please feel free to suggest new projects for the list. >There are many things to cleanup in the tree, and having >them available on an easy to read page increase the changes >of (1) someone picking them up, and (2) us not forgeting them. > Well not fogetting about them is sort of what bugzilla is for. So I will put them into Bugzilla with the keyword tasklist or tasklet as appropriate. Bugzilla is good at tracking what needs to be done I think it worked very well for -DSTRICT and these are very much like that. > >So let me know if you come across anything that you feel should >be on the list. Also, if you're working on something big, I can >mark your name there so we can avoid duplicated work. > >Last but not least, there are a lot of small, self contained, >and easy to get into tasks listed there. If you feel like getting >your feet a bit wet in Wine development, this is an ideal >opportunity to start, and get to know the project a little better. >Just ask for help if you are new, and would like some help to >get you started. > > > You should probably have a link to the tasklets/tasklist at the bottom of the page. -- Tony Lambregts

Dec. 4, 2002

Re: Registering DLL's

by Jeff Smith

>From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > >On December 4, 2002 01:36 pm, Jeff Smith wrote: > > Does anyone have any better ideas on what the "Right Way" to tackle > > this item is? I am sure that adding external functions that do not > > exist in native versions is *not* the way. > >This was Alexandre's idea. Alexandre, a more detailed brain dump on >the configuration stuff would be useful. For example: > >C.1 Merge configuration into the registry > >Any gochas? What would it take? > >C.5 Make Wine's DLLs register themselves to avoid manual merging of the >winedefault.reg > >How should this be implemented? See Jeff's questions. > >C.6 Write wine.inf script to setup a new Wine installation > >Do we have the code that executes .inf scripts? Is this one >just a matter of writing the scripts? > >-- >Dimi. For those interested, here are a couple of links relating to the INF file format (1), and the SetupAPI (2). I don't know how complete our implementation is, but it can be found under wine/dlls/setupapi. 1.) http://msdn.microsoft.com/library/en-us/install/hh/install/create-inf_4l47.… 2.) http://msdn.microsoft.com/library/en-us/install/hh/install/setupapi_2faf.asp -- Jeff S _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

Dec. 4, 2002