Re: Fix comctl32 tests
Dimitrie O. Paun [EMAIL PROTECTED] writes: ChangeLog DPA_Create is exported by ordinal only, do not import it by name. That shouldn't be necessary, it's automatically handled when resolving the import. That's probably a bug in the mingw import library. -- Alexandre Julliard [EMAIL PROTECTED]
Re: faq merge #2 -- Alexandre please look over the first patch :)
Tom [EMAIL PROTECTED] writes: changelog merge from lostwages faq It doesn't build here, that's because of the '' in the rpmseek.com URL, I'm not sure what's the correct way to escape that: documentation/faq.sgml:1386:93:E: general entity cx not defined and no default entity documentation/faq.sgml:1781:26:E: an attribute value must be a literal unless it contains only name characters documentation/faq.sgml:1781:61:E: end tag for element A which is not open documentation/faq.sgml:1786:14:E: end tag for ULINK omitted, but its declaration does not permit this -- Alexandre Julliard [EMAIL PROTECTED]
Re: Janitorial: Include statements should use instead of
Andrey Warkentin [EMAIL PROTECTED] writes: Currently done: wine/controls/* and wine/dlls/gdi/* (with the exception of wine/dlls/gdi/tests/generated.c) ChangeLog Include statements use instead of in files in wine/controls and wine/dlls/gdi This was discussed already, there's no reason to change the C files, only the headers actually matter (and these are fixed now). -- Alexandre Julliard [EMAIL PROTECTED]
Re: Move Wine internal headers
Vincent Béron [EMAIL PROTECTED] writes: Changelog: Move the Wine internal headers to includedir/wine/wine rather than includedir/wine. Why do you want to do that? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Move Wine internal headers
Vincent Béron [EMAIL PROTECTED] writes: winegcc doesn't include eg /usr/include, so the headers referencing internal ones (mostly OLE related) fail. I thought it was cleaner to move wine internal stuff than to break down the includedir variable in Makefile to get to the parent of /usr/include/wine, ie /usr/include. OK, I see. I think the idea with winegcc at this point is that if you install Wine in a non-standard directory, you have to specify the include path yourself, just like you need to ensure the Wine tools are in your PATH. Besides, this shouldn't be an issue once the standard includes are fixed to no longer reference the wine/obj_* ones. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Move Wine internal headers
Steven Edwards [EMAIL PROTECTED] writes: I was also thinking about submitting a patch to move any of the *16 headers and internal headers that dont exist in the PSDK to include/wine. Is this ok? The 16-bit headers should already be in include/wine; if we have missed some then sure it's ok to move them. The internal headers will be removed, and in the meantime I think it's best to keep them where they are. -- Alexandre Julliard [EMAIL PROTECTED]
Re: LoadModule16 regression?
Jukka Heinonen [EMAIL PROTECTED] writes:
MSDN documentation on Win32 version of LoadModule states
that path should not be stripped but I'm not sure how Win16
version is supposed to work. It probably uses different
search order if path is not present, anyway.
Yes, Win16 is somewhat different, the module path is stripped and only
the base name is used when looking for an existing module. But of
course we should only strip the full path after the file has been
opened... this should fix it:
Index: dlls/kernel/ne_module.c
===
RCS file: /home/winehq/opt/cvs-commit/wine/dlls/kernel/ne_module.c,v
retrieving revision 1.5
diff -u -p -r1.5 ne_module.c
--- dlls/kernel/ne_module.c 27 Aug 2003 03:16:56 - 1.5
+++ dlls/kernel/ne_module.c 30 Aug 2003 18:37:13 -
@@ -1162,22 +1162,23 @@ static HINSTANCE16 MODULE_LoadModule16(
enum loadorder_type loadorder[LOADORDER_NTYPES];
int i;
const char *filetype = ;
-const char *ptr;
+const char *ptr, *basename;
/* strip path information */
-if (libname[0] libname[1] == ':') libname += 2; /* strip drive specification
*/
-if ((ptr = strrchr( libname, '\\' ))) libname = ptr + 1;
-if ((ptr = strrchr( libname, '/' ))) libname = ptr + 1;
+basename = libname;
+if (basename[0] basename[1] == ':') basename += 2; /* strip drive
specification */
+if ((ptr = strrchr( basename, '\\' ))) basename = ptr + 1;
+if ((ptr = strrchr( basename, '/' ))) basename = ptr + 1;
-if (is_builtin_present(libname))
+if (is_builtin_present(basename))
{
-TRACE( forcing loadorder to builtin for %s\n, debugstr_a(libname) );
+TRACE( forcing loadorder to builtin for %s\n, debugstr_a(basename) );
/* force builtin loadorder since the dll is already in memory */
loadorder[0] = LOADORDER_BI;
loadorder[1] = LOADORDER_INVALID;
}
-else MODULE_GetLoadOrder(loadorder, libname, FALSE);
+else MODULE_GetLoadOrder(loadorder, basename, FALSE);
for(i = 0; i LOADORDER_NTYPES; i++)
{
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: patch for non x86 specific code in BuildSpec16File.
[EMAIL PROTECTED] writes: (See attached file: patch_spec16_x86_specific) Why do you want to do that? It will generate a lot of functions that will never be used. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [resend] Allow use of MAP_TRYFIXED for better mmap()
Todd Vierling [EMAIL PROTECTED] writes: I have a feeling we're just on different mental wavelengths here. MAP_TRYFIXED is not an optional feature. If the #define exists, the feature exists -- for the OS version used to compile, and all later versions. You are still thinking only about source distributions. The problem is when you want to ship a binary: the only way to build a binary that works for everybody is to build it on an old OS version; that's the way it is on all systems (it's the same way on Linux, at least WRT libc). Then, since you built that binary on an old OS, it will not use MAP_TRYFIXED, no matter what kernel it runs on. Basically you have to sacrifice performance to gain portability; even if 99% of your users have a new kernel, your binary still cannot take advantage of that. With a run-time check you don't have to sacrifice anything, the binary is still portable everywhere, but can also use MAP_TRYFIXED for better performance if it exists in the running kernel. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [resend] Allow use of MAP_TRYFIXED for better mmap()
Jon Bright [EMAIL PROTECTED] writes: Except that if you build it on a machine which knows about MAP_TRYFIXED at all, the resulting binary's not likely to run on older machines... You don't need the machine to know about it, that's the whole point. Of course that means you need to define the symbol yourself if it's not defined already. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [resend] Allow use of MAP_TRYFIXED for better mmap()
Todd Vierling [EMAIL PROTECTED] writes: You have to bend over backwards to do the runtime check, and you sacrifice *maintainability* with the extra normally-dead code added to Wine. I don't see a need to jump through extra hoops in this case. I think that run-time checks are more maintainable that compile-time checks, since it means the code gets exercised on all machines, so if you break it it gets noticed at once. If you break something that's inside a rarely used #ifdef block you may not find the problem until 6 months later. It's also a lot easier to follow the code if you don't have to wonder which parts of it are actually compiled in. Anyway it doesn't really matter for that specific issue, if you don't feel the performance gain is worth the trouble that's your call. I was just raising a general point that checking run-time features with #ifdef is not a good idea, no matter how much autoconf encourages that style. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [resend] Allow use of MAP_TRYFIXED for better mmap()
Todd Vierling [EMAIL PROTECTED] writes: I definitely don't want to reproduce apt-to-change parts of the OS in an application just because it *might* be built on an earlier version of that OS. If an app is built on the earlier OS version, the user should expect to be missing features. Unix users accept this as a fact of life. But like it or not, this is changing. Maybe not for NetBSD yet, but there are many people at least on Linux who are not primarily Unix users, and who want things to work without having to mess with configure or upgrading system headers. This is doubly true for Wine, since real Unix users don't need Windows apps, our primary audience is Windows users who are used to downloading binaries that just work. And so we have a responsibility to make sure that it's the case for them, even if it means departing from the One True Unix Way. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
Dimitrie O. Paun [EMAIL PROTECTED] writes: Keeping these 3 task separate does not mean they will be lost and forgoten -- I volunteer to keep track of them independently. In fact, we'll get more work done this way, because different people enjoy working on different bits. Defining exactly what we want winecfg to do will help Mike get the job done faster. Defining explicitly and granularly the paramter cleanup tasks will allow others (not interested in winecfg work) pick up pieces and run with them. Sure, they are separate tasks, it's more an issue of in which order we do things. If we are going to change things in the config tree, then it's a lot easier to do before winecfg is used, otherwise we need to add a lot of backwards compatibility code in there; so I think throwing the switch for winecfg should be one of the last things we do, once the rest is at least well under way. That doesn't prevent working on winecfg, we can do at least 95% of it without having to make it edit the primary config tree. Also once the config is in the registry it becomes inconvenient to modify by hand, so it implies we first need write support in regedit, and a working default configuration so that regedit/winecfg can actually start without requiring config changes. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
Dimitrie O. Paun [EMAIL PROTECTED] writes: What kind of backwards compatibility code are you afraid we're going to need? Well, if when cleaning things up we find out that some key should be moved/renamed/using a different syntax, then we need to have winecfg deal with both formats and be able to convert back and forth; while right now we can just say edit your config and change this. Basically, it's easier to break things before people get used to having a nice interface that does everything for them ;-) -- Alexandre Julliard [EMAIL PROTECTED]
Re: [winecfg 1.1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
Mike Hearn [EMAIL PROTECTED] writes: If we want to do that, it's worth deciding now, as it affects how winecfg operates. At the moment changes to the GUI are moved to and fro the structure in bulk, then the struct is saved to the registry, again in bulk. That lets us do OK/Cancel. If we want instant apply, that complicates things. It should definitely be possible to apply a subset of changes; we don't want to rewrite the full config everytime a change is made. If I toggle the managed flag for instance I expect that specific key to be written to the registry, nothing else. Yes, it will complicate the implementation a bit... -- Alexandre Julliard [EMAIL PROTECTED]
Re: [winecfg 1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
Mike Hearn [EMAIL PROTECTED] writes: - Change registry key used to WineHQ\Wine Is that so that you can test the code? In that case Wine\WineCfg would be preferable I think. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [winecfg 1] Implement saveConfigValue(), style changes, codecleanup, UI alignment
Mike Hearn [EMAIL PROTECTED] writes: The idea was: - many parts of Wine may want to store settings in that part of the registry, not just the main emulation engine. So, winemine, notepad, other various apps etc. - The standard on Windows seems to be Vendor\Product. That's what we do, the vendor is Wine followed by the app name. At least winemine and winedbg use that already. -- Alexandre Julliard [EMAIL PROTECTED]
Re: make crosstest working again
Jakob Eriksson [EMAIL PROTECTED] writes: This patch makes make crosstest work again. I made it work by correcting incorrect linking options for some tests and by removing the tests altogether in some cases. You should get a more recent mingw that has an ntdll import library, it will probably work much better then (yes there is still an issue with libuuid, but removing tests is clearly not the right fix). -- Alexandre Julliard [EMAIL PROTECTED]
Re: [winecfg 2] Merge X11DRV dialog code from Mark, bugfixes
Mike Hearn [EMAIL PROTECTED] writes: - Merge X11DRV dialog code from Mark - Move X11DRV dialog init code to a separate file - Link with Xlib to get XParseGeometry winecfg is supposed to be a windows app, it must not depend on Xlib. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [resend] Allow use of MAP_TRYFIXED for better mmap()
Todd Vierling [EMAIL PROTECTED] writes: In general, this holds true with other applications on NetBSD. If a feature appears in the C headers, it is assumed to exist. The patch is in line with NetBSD's compatibility principles. Of course this implies that everybody builds all their apps from source. But if that's what NetBSD people expect then it's OK with me. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [resend] Allow use of MAP_TRYFIXED for better mmap()
Todd Vierling [EMAIL PROTECTED] writes: No, it implies that a built binary requires a kernel at least as new as the .h files used when building. This is NetBSD (and SysV and ...) standard practice, and is the foundation of how autoconf tests work. The common practice of Linux users shuffling back and forth on kernel versions is a glaring exception to this common-sense rule. 8-) It's not really a question of shuffling back and forth, it's that different users have different kernels; so if you want to ship a binary that works for everybody, with your method you have to stick to the lowest common denominator. With run-time checks you can have a binary that takes advantage of new kernel features, while still running everywhere. Obviously it's a bit more complex to implement, so you only want to do that where there's a real gain in using the new features; still I think the concept applies for all platforms. -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH - winnt.h move non-standard language IDs to wine/port.h
Dimitrie O. Paun [EMAIL PROTECTED] writes: I agree with this, but the two issues are completely orthogonal. One deals with how we organize extensions, one on how to use them. I am 100% with you that a portable implementation is better -- it is in fact the same pattern adopted by 'configure'. However, this says nothing about where to place such extensions. In fact, I would argue that placing such extension in explicitly designated headers will actually help Winelib developers. For one, it will make it a lot more explicit when they will have to use the portable pattern you were advocating. Otherwise, if development happens user Winelib, this can be easily missed. Moreover, it allows projects to easily enforce (by giving them the means to trivially check were Wine extensions are being used) certain policies about when/where/how Wine extensions are acceptable. For portability, people will have to simply do: #ifdef __WINE__ #include wine/extensions.h #endif just like they do with HAVE_XXX_H tests. It fits in rather well, no? I don't agree that the issues are orthogonal, I think that how we organize the extensions very much depends on how we want people to use them. Also I think your approach does not encourage the right pattern, it actually suggests using #ifdef __WINE__ everywhere. I think the main question is whether or not we want to encourage use of the extensions. If we want to encourage it, then they should be in the default headers; if you need some magic incantation to make them available nobody will bother. Now, if we'd rather encourage portable code that doesn't use extensions, then IMO we shouldn't export them at all, and let people who really want them go to the trouble of copying them from Wine internal headers. There's also the issue of backwards compatibility; many of the extensions are for things that aren't documented by Microsoft at this point, but that may become documented one day. If that happens and the extension is already in the standard headers then it's completely transparent; but if it's in wine/extensions.h then we'll have trouble keeping everything in sync. -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH - winnt.h move non-standard language IDs to wine/port.h
Dimitrie O. Paun [EMAIL PROTECTED] writes: Well, first off, it's not clear that we provide any worthwhile extensions to warant all the complications. In fact, due to the scattered nature of said extensions, I don't even have a good idea of what extensions we have and if they are worthwhile. BTW, any user (that is app developer) will be in the same situation. Second, I don't think a simple include qualifies to the rank of magic incantation -- it's the least obtrusive way of letting people know they are using something non-standard. Thirdly, the backwards compatibility you mention is a big can of worm, and I think it's a bit of a red herring -- binary compatibility will most likely be busted anyway, what are the chances we're going to pick the same binary value as MS? For things we invent ourselves the chances are pretty small, but most extensions are for undocumented stuff, where the values/function names/etc. are defined by MS already, only they are not part of the normal headers; winternl.h is a good example of that. I have to admit I play the devil's advocate role in this debate. From my POV the biggest benefit is that we'll have a _simple_ rule for our headers: keep them as close as possible to the MS' one. Not a simple task, and experience has shown that the simple the rule/principle, the easier to understand and implement. We've learned the hard way many atimes that playing smart does not pay. There are places where it's worth doing, but it's far from clear that we have such a compelling reason to break this principle in this case. The problem is that the as close as possible rule also implies not creating new headers; so either way we are breaking the rule, and IMO it's better to keep a few extra definitions in the normal headers, close to where they belong (for instance the extra LANG_* constants next to the other LANG_ stuff) than splitting them to a separate header. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [RESEND] Sync (47): shlwapi tests
Francois Gouget [EMAIL PROTECTED] writes: On Sun, 24 Aug 2003, Jon Griffiths wrote: [...] Note that a regression is something that used to work, and now doesn't. So any regression testing should only report failures for tests that used to work and now don't. New tests that fail, or those that have never succeeded, _aren't_ regressions, and shouldn't be marked These are not regression tests but conformance tests. They should report anything that does not conform to the Windows behavior as an error. I disagree, as far as I'm concerned they are definitely regression tests. If we only wanted to check conformance then it would be OK for tests to fail everywhere we are not compatible; it's because the tests must be usable to find regressions that we cannot have failing ones in the tree. And that's why we have the todo_wine macro to mark tests that are expected to fail. -- Alexandre Julliard [EMAIL PROTECTED]
Re: remove some __WINESRC__es
Dimitrie O. Paun [EMAIL PROTECTED] writes: No need to clutter the header files with these tests. We have enough of a review process in place to avoid such things, and in any way, things like #ifdef __WINESRC__ # undef UNICODE #endif /* __WINESRC__ */ simply encourage bad coding, hides problems, and it's confusing. I agree for UNICODE, but not for NEAR, FAR etc. Allowing them in Wine will actually encourage bad coding, since we will see FAR pointers pop up all over the place. A better approach would be to #define them to something like do_not_use_this when building Wine. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [RESEND] Sync (47): shlwapi tests
Jon Griffiths [EMAIL PROTECTED] writes: Any problems with this one? You said yourself that the some of the tests are currently failing; I cannot commit tests that fail, that would make the regression test suite useless. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Usage of remove_timeout_user in the wineserver
Mike Hearn [EMAIL PROTECTED] writes: Basically the callback for the timeout is called, and the callback (for instance in set_next_timer:queue.c) calls remove_timeout_user() which does a free( user ), but at the end of handle_timeout() it also performs a free, so I think the same timeout struct is freed twice. That shouldn't happen, the timeout can be either handled or removed, but not both. Exactly where do you see this happen? Do we somewhere call remove_timeout_user while handling the timeout? -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH - winnt.h move non-standard language IDs to wine/port.h
Dimitrie O. Paun [EMAIL PROTECTED] writes: I think this will make the mingw work a lot simpler. And in general, it will make things a lot more explicit in terms of what is standard and what is a Wine extension, and this is good. Do we get the go ahead? :) No, actually the more I think about it the less I like it. The problem with that approach is that if an app uses wine/extensions.h, not only you can't it build under Windows without somehow obtaining the Wine header first, but once you compile it it will use all sorts of extensions that won't work under Windows. IMO it's better to leave the extensions in the normal headers and make the code deal with missing definitions in case you are building under Windows. So instead of importing the definition of say LANG_GAELIC from some Wine header, you wrap that code in a #ifdef LANG_GAELIC, and then the app can build and run correctly both on Windows and Wine. We could also wrap the extensions with #ifndef WINE_NO_EXTENSIONS in our headers so that you can define that symbol when building under Wine to make sure your code is portable. -- Alexandre Julliard [EMAIL PROTECTED]
Re: patch 6
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Added my email next to my name in cmdlgtst /It.rc It's better to avoid putting email addresses in source files, they quickly become obsolete and nobody ever bothers to update them. Just put your name there, and people who want to mail you can look up your most recent address in the Changelog. -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH - winnt.h move non-standard language IDs to wine/port.h
Dimitrie O. Paun [EMAIL PROTECTED] writes: We still have a few (hard to remove) #ifdef __WINESRC__ in our headers. We all agree they should be removed, but they are not trivially removable right now. I say we should move all such extensions to a wine/internal.h header. This will accomplish a few things: -- make the task of compiling with other headers a lot easier. This will further result in more portability and header fixes for our standard headers, which is a Good Thing(TM). -- the wine/internal.h include should be included only from .c files, thus explicitly marking such offenders, and providing a list of things that need to be addressed. -- the wine/internal.h header itself will serve as a quick TODO for people interested in fixing these. The last two points will also make it easier to see where we're using undesirable extensions. Whatdayasay? I don't think the problem is so much with internal definitions, pretty much all of them are gone at this point. The problem is really with extensions that we want to make available to applications too, like the extra languages. We could have a wine/extensions.h header, but I'm not convinced we can really move everything there without creating a big mess. -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH try 2 - build libwine_unicode with w32api headers
Steven Edwards [EMAIL PROTECTED] writes: Ok now with clean w32api headers from CVS we can build unicode. This shouldnt break cross compiling or the *nix build but if it does please let me know. Also you can change WINVER = 0x0500 to whatever as long as it is higher. It seems to me the w32api headers should define WINVER to the higher version that is supported, defining it in the app should only be necessary if you want compatibility with older versions IMO. -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH - some build fixes for w32api headers
Steven Edwards [EMAIL PROTECTED] writes: Changelog: Fixes for building with w32api headers on Mingw Why do you need to add stdarg.h everywhere? AFAICS it should be already included by the headers that require it. As a general note, it's a very good thing to test with other headers, but make sure that the problem is really on the Wine side before making changes. Being compatible with w32api is not a goal in itself for Wine, we have to be compatible with Microsoft; and if the Wine code works with the Microsoft headers but not with w32api then the bug is in w32api and should be fixed there. And in the case where the bug is really in Wine, this means there's an incompatibility in the Wine headers, since it builds fine with them and it shouldn't. So this means we have to fix the Wine headers too, not only the C files. -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH - some build fixes for w32api headers
Steven Edwards [EMAIL PROTECTED] writes: --- Alexandre Julliard [EMAIL PROTECTED] wrote: Why do you need to add stdarg.h everywhere? AFAICS it should be already included by the headers that require it. While the WINE winbase.h includes these lines w32api and the copy of SP3 for MS_VC6 does not. #ifndef RC_INVOKED #include stdarg.h #endif OK, then the patch is correct, but you should also remove that stdarg.h from the Wine headers, to make sure that the problem doesn't come back. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Build broken due to -lpthread
Gerald Pfeifer [EMAIL PROTECTED] writes: Wine fails to build on FreeBSD 4.8 with the following failure mode: /usr/bin/gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D_REENTRANT -fPIC -D__WINESRC__ -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o glu32.spec.o glu32.spec.c /usr/bin/gcc -shared -Wl,-Bsymbolic,-z,defs glu32.spec.oglu.o glu32.dll.dbg.o -o glu32.dll.so -L../../dlls -L../../libs/wine -lwine -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11 -lGL -lGLU -lpthread -L../../libs/port -lwine_port -lm -lc /usr/libexec/elf/ld: cannot find -lpthread So what's the right way to link with libpthread on FreeBSD? -- Alexandre Julliard [EMAIL PROTECTED]
Re: REGRESSION: environment variables no longer possible
Dmitry Timoshkov [EMAIL PROTECTED] writes: Actually it's just the format of the Wine config has changed. Now all environment variables should be surrounded by the percent signes (%HOME%), and are handled by the normal registry code. Alexandre has changed the sample config as well. Actually the format of the config has not really changed, most entries have been behaving that way for a long time already. I just made the drives part of the config behave like all the other entries. Attached patch is rather useless, but however it makes the old profile code be consistent with the new behaviour. A better approach is to completely remove environment handling from profile.c. Yes, I think environment handling should be left to the application. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Parse error when trying to build imagehlp with the w32apiheaders
Steven Edwards [EMAIL PROTECTED] writes: Does anyone have any idea as to what is going on here. I dont really see why mingw has a problem. access.c: In function `ImageUnload': access.c:204: parse error before LOADED_IMAGE access.c:210: parse error before LOADED_IMAGE make1: *** [access.o] Error 1 It looks like the mingw headers are missing the CONTAINING_RECORD macro. -- Alexandre Julliard [EMAIL PROTECTED]
Re: REGRESSION: environment variables no longer possible
Dimitrie O. Paun [EMAIL PROTECTED] writes: While this makes sense from a separation perspective, it will prove to be very inconvenient in practice. For decent integration we need access to the environment, and having wrapper over wrapper to do these things is not convenient. I don't see why it would be any different than running under Windows. If the app supports environment variables in its .ini file under Windows then it will support them under Wine, otherwise it won't. I don't think we should magically expand things in .ini files. Environment variables in the Wine config file itself are supported, as long as you use the Windows syntax. -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH - msvcrt.spec exports
Steven Edwards [EMAIL PROTECTED] writes: This is untested on *nix build. With this we can build and link regression tests on Mingw again. Changelog: Casper Hornstrup chorns_at_users.sourceforge.net Fix export definition _onexit and atexit. This is wrong, _onexit and atexit are functions, not variables. The bug is in Mingw. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Small cleanup
Dimitrie O. Paun [EMAIL PROTECTED] writes: Sorry, I don't quite understand: these defines are present only when compiling user32. Now, how do we know what defines MS uses to compile their user32? How can this ever be relevant to us? We know because the defines are used in the Microsoft headers for the dllimport stuff. We don't need them for that purpose, but we could still use them for something else, like optimizations. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Small cleanup
Dimitrie O. Paun [EMAIL PROTECTED] writes: ChangeLog Remove unused defines. The idea is to have the same defines as Windows; even though we don't actually need them at this point we might want to someday. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [X11DRV] Re-add support for the 'UseXShm' config key.
Lionel Ulmer [EMAIL PROTECTED] writes: Well, sometimes, in some rare debugging cases, it's useful to have it, yeah. But is it useful enough to justify exposing it, documenting it, explaining to users they shouldn't touch it, etc.? IOW do you use it often enough that it's painful for you to have to modify the source and rebuild to disable it? -- Alexandre Julliard [EMAIL PROTECTED]
Re: cab_G_00-pre1 (RFC)
Gregory M. Turner [EMAIL PROTECTED] writes: Would love to hear if I have not done things in a properly SETUPAPI way, i.e., am I supposed to be performing certain logging or memory allocation rituals, anything like that? One ritual is that you should not use msvcrt from other dlls, this will cause trouble with apps that use the Unix libc. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Accept SIZE_MAXIMIZED as one of statuses of MDI windows
Dmitry Timoshkov [EMAIL PROTECTED] writes: @@ -1070,9 +1072,10 @@ STATUSBAR_WMSize (STATUSWINDOWINFO *info width = parent_rect.right - parent_rect.left; x = parent_rect.left; y = parent_rect.bottom - infoPtr-height; -MoveWindow (infoPtr-Self, parent_rect.left, - parent_rect.bottom - infoPtr-height, - width, infoPtr-height, TRUE); +SetWindowPos(infoPtr-Self, HWND_TOP, + parent_rect.left, parent_rect.bottom - infoPtr-height, + width, infoPtr-height, SWP_NOZORDER); + What is this change for? -- Alexandre Julliard [EMAIL PROTECTED]
Re: [resend 3rd time ] SetMenu patch
Oleg Prokhorov [EMAIL PROTECTED] writes: Cause: SetMenu was limited to update client/non-client only if window is visible, while MS Windows SetMenu updates it anyway. Changelog: SetMenu always updates client/non-client. This causes a SetWindowPos to happen during window creation, before the window is properly initialized, with bad results. This will need more work I'm afraid. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Implement a typelib loader cache
Mike Hearn [EMAIL PROTECTED] writes: ChangeLog: Implement a typelib loader cache You'll need to protect the list with a critical section. Also it's probably better to store the list directly in the typelib structure instead of allocating a separate object. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Add support for CS_NOCLOSE
Dmitry Timoshkov [EMAIL PROTECTED] writes: Hello, Changelog: Dmitry Timoshkov [EMAIL PROTECTED] Add support for CS_NOCLOSE. This is implemented already in MENU_InitSysMenuPopup; if it doesn't work right it should be fixed there. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/ scheduler/pthread.c dlls/ntdll/sysdeps.c
Rein Klazes [EMAIL PROTECTED] writes: This causes thread related failures on my Debian unstable system using glibc 2.3.2 (nptl not enabled). For example his is Agent after calling WSAAsyncGetHostByName: | Unhandled exception: page fault on read access to 0xdbdbdbe3 in 32-bit code (0x402ddfaa). | In 32-bit mode. | 0x402ddfaa (NTDLL.DLL.memcpy+0x65fe6 in libc.so.6): testb $0x1,0x8(%eax) | Wine-dbgbt | Backtrace: | =0 0x402ddfaa (NTDLL.DLL.memcpy+0x65fe6 in libc.so.6) (ebp=42302e38) | 1 0x402e0195 (NTDLL.DLL.memcpy+0x681d1 in libc.so.6) (ebp=42302e98) | 2 0x4175b8d7 (_async_queryfun+0x1d3(arg=0x4041e480) [async.c:401] in ws2_32.dll.so) (ebp=42302f14) | 3 0x400a0e93 (THREAD_Start+0xd3 [thread.c:1622] in libntdll.dll.so) (ebp=42302fe0) | 4 0x400ba9e3 (SYSDEPS_StartThread+0x27(teb=0x42303000) [sysdeps.c:154] in libntdll.dll.so) (ebp=42302ff4) | 5 0x402cf217 (NTDLL.DLL.memcpy+0x57253 in libc.so.6) (ebp=) (it crashes inside gethostbyname(), without obvious reason). I think this should be fixed in current CVS, please give it a try and let me know how it works. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/ windows/winproc.c windows/win.c windows/ ...
Dimitrie O. Paun [EMAIL PROTECTED] writes: Can we use the C99 initializers, like they do in the Linux kernel? I think they'll do a better job in this case. This one looks a bit too cryptic for me. I don't think we want to depend on C99 features, no. It could be made clearer with comments etc., but that declaration is just a magic incantation that's not going to change, so IMO it doesn't really matter if it's a bit cryptic. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Accept SIZE_MAXIMIZED as one of statuses of MDI windows
Dmitry Timoshkov [EMAIL PROTECTED] writes: HWND_TOP of course should be replaced by 0 since SWP_NOZORDER is specified. The change is aimed to be a simple optimization. Then you'd need to add SWP_NOACTIVATE for it to be identical to the previous code; but I don't think this kind of micro-optimization is useful, if all we want is to move the window it's clearer to use MoveWindow IMO. -- Alexandre Julliard [EMAIL PROTECTED]
Re: dmusic loader question
Dustin Navea [EMAIL PROTECTED] writes: --- Rok Mandeljc [EMAIL PROTECTED] wrote: BTW, is it illegal to use MSDN examples to implement stuff in wine (EULA...)? Fortunately, AFAIK, it is not illegal. It is only illegal to reverse engineer a compiled file, or to use copyrighted source obtained through other methods without the author's consent.. Well it's certainly illegal to directly copy code from the MSDN examples; please don't do that. -- Alexandre Julliard [EMAIL PROTECTED]
Re: cards.dll, first patch
Jonathan Wilson [EMAIL PROTECTED] writes: No code or images have been taken from anything thats (c) microsoft although studying cards.dll in IDA did help me to figure out how it all works :) That's not a good idea at all. Your code is obviously a straight transcription of the disassembled code, with lots of magic numbers and meaningless variable names. That is not an acceptable way of implementing something for Wine. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Make aclocal.m4:WINE_GET_SONAME more flexible
Todd Vierling [EMAIL PROTECTED] writes: The following patch to aclocal.m4 (will require a run of autoconf after changing to pick up the change) will make WINE_GET_SONAME work on NetBSD, and likely the other *BSDs. It is still Linux compatible -- in fact, this new incarnation returns the fully qualified path to the shared object, eliminating fears of runtime linking path searches. I don't think that's a good idea. There is no guarantee that the full path is valid on other systems, and we don't want to bypass the user's LD_LIBRARY_PATH settings. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Make aclocal.m4:WINE_GET_SONAME more flexible
Todd Vierling [EMAIL PROTECTED] writes: Nor is there a guarantee that the non-full path is ABI compatible on other systems, which was the point of allowing the full path (for system libraries, mind you, not Wine's own) through. I don't see why it wouldn't be ABI compatible; that's the whole point of finding the soname, so that we get the proper version of the library. The full path is completely irrelevant; when you dynamically link an app the linker doesn't store the full path to the system libraries either, just the soname. That's exactly what we are doing here. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/. configure.ac configure
Marcus Meissner [EMAIL PROTECTED] writes: Which file/functions gets broken by strict aliasing? Well, everywhere we get an aliasing warning, there is potential for it to be miscompiled. And the Windows API is so bad at using correct types that I'm not sure we can really hope to ever have strict aliasing do the right thing. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Define WINEPREFIX if it doesn't exist
Dmitry Timoshkov [EMAIL PROTECTED] writes: But in order to read ~/.wine/config WINEPREFIX should be either already detected or any default value used. Why not use that value everywhere else? After all, what is the problem with using a default value, which actually is being already used? The problem is that you can't depend on it being set, because Wine is supposed to work fine without it. Setting it in the wrapper script won't change that, because the wrapper is only used when running from inside the source tree. But that would effectively invalidate all the efforts to make Wine easily configurable. There are situations when somebody wants by changing single environment variable get completely different Wine environment: with distinct registry, config, win.ini, .ppd and other files... On the contrary, it's even easier to configure if you don't have to install generic.ppd at all and it just uses the global one. You could still specify it in the config file if you really wanted, but you shouldn't have to. Of course if you want multiple Wine environments with different generic.ppd files then you need to tweak the config; but that's definitely not the standard case. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Define WINEPREFIX if it doesn't exist
Dmitry Timoshkov [EMAIL PROTECTED] writes: How about the following solution: do not set WINEPREFIX in the startup script, just add it to the Wine environment (possibly even not propagating it to the Unix environment) in the case it wasn't already set? I don't think we want to modify the environment unless really necessary, and IMO it's not necessary in that case. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Define WINEPREFIX if it doesn't exist
Dmitry Timoshkov [EMAIL PROTECTED] writes: Define WINEPREFIX if it doesn't exist. Why do you need that? -- Alexandre Julliard [EMAIL PROTECTED]
Re: [resend] Ensure ole32.dll gets correct version number
Mike Hearn [EMAIL PROTECTED] writes: The primary motivation for this bugfix was to enable the DCOM98 installer to work again correctly. It requires at least 4.something, otherwise it refuses to install. As our OLE framework isn't yet up to scratch for some tasks, being able to install it is important (hopefully once I finish digesting Oves work maybe it will be less important). You may be able to install it by playing with the load order (i.e. set ole32 to native only). Having a bogus version in the builtin is going to force everybody to install the native, which is not what we want. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Mach-O Support in WineLib Loader (2) dlopen
Pierre d'Herbemont [EMAIL PROTECTED] writes: On the previous patch I would like your comment on the way to force ntdll to be loaded as RTLD_GLOBAL. Ntdll can't be built currently as a dynamic library (loadable at runtime). By the way I would like to now why is ntdll linked to dlls? Maybe this patch could apply to linux and others also, on a proper way. kernel32 is linked to ntdll because dll separation is not finished; hopefully this will be fixed soon. -- Alexandre Julliard [EMAIL PROTECTED]
Re: new utillity for wine, genguid
Jonathan Wilson [EMAIL PROTECTED] writes: ok, is this better? Included as one big patch Also, added blank line, changed coding to 4 spaces instead of tab and, changed options to use what you suggested. It looks good, but I'm not convinced we really need that in Wine, there are Unix tools that can generate UUIDs. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Define WINEPREFIX if it doesn't exist
Dmitry Timoshkov [EMAIL PROTECTED] writes: Why does wineps complain that it couldn't load %WINEPREFIX%/generic.ppd specified in the config in the case WINEPREFIX is not set in my environment? Because WINEPREFIX is not set of course. The solution is not to set it unconditionally, but to fix your config and/or wineps to do the right thing when WINEPREFIX is not set. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Define WINEPREFIX if it doesn't exist
Dmitry Timoshkov [EMAIL PROTECTED] writes: I'm not sure what do you mean by the right thing here. Do you mean that I'm not allowed to use WINEPREFIX in the config, or you mean that every single dll should have its own ExpandEnvironmentStrings implementation? Something else? Well, you cannot use WINEPREFIX in the config file that is in ~/.wine/config, since it can potentially be used without the prefix being set. The easiest is to replace %WINEPREFIX% by %HOME%/.wine in that specific config file. A more elaborate solution would be to make wineps look in the prefix dir when it gets a relative dir, like the drive config code does. I'm not convinced we want to do that though, IMO it would be better to install generic.ppd globally and make wineps default to something like $(libdir)/generic.ppd. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Define WINEPREFIX if it doesn't exist
Dmitry Timoshkov [EMAIL PROTECTED] writes: I have several Wine trees locally, and start up scripts some of them set WINEPREFIX to a non default value. In order to avoid setting it in my ~/.profile I'd prefer that each Wine start up script sets this either to each own unique value or, if it has no special preferences, set it to the default one. I still don't see why you want that, if it's not set Wine will use the default one already. -- Alexandre Julliard [EMAIL PROTECTED]
Re: More Red Hat b0rkage?
Mike Hearn [EMAIL PROTECTED] writes: I know Wine has some issues with some kernel security patches and memory regions. Can anybody confirm that this won't cause issues: It will, but there's a 'chstk' tool (that hopefully RedHat is shipping along with their kernel) that lets you set a flag in the Wine binary to make it go back to normal stack behavior. -- Alexandre Julliard [EMAIL PROTECTED]
Re: PATCH: shlwapi
Marcus Meissner [EMAIL PROTECTED] writes: Changelog: Numbers without prefix are int (32bit signed). If you want long long (64bit signed), append LL. LL is not portable, this needs to be done with casts. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [resend] Ensure ole32.dll gets correct version number
Mike Hearn [EMAIL PROTECTED] writes: diff -u -r1.1 version.rc --- dlls/ole32/version.rc 28 Mar 2003 19:33:04 - 1.1 +++ dlls/ole32/version.rc 13 Jul 2003 13:09:17 - @@ -21,4 +21,8 @@ #define WINE_OLESELFREGISTER #define WINE_FILENAME_STR ole32.dll +#define WINE_FILEVERSION_STR 2.0 +#define WINE_FILEVERSION 2,0,0,0 + #include wine/wine_common_ver.rc Version 2.0 is awfully old for ole32.dll. Why do you need that? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Sync (29): msvcrt cpp
Jon Griffiths [EMAIL PROTECTED] writes: +dlls/msvcrt/cpp.c Use exception as the base for all exception derived classes. Implement type_info methods correctly. Add static RTTI for exported objects. Throw exceptions when run time casts fail. Why did you remove all the structure definitions for the derived classes? I think it's much clearer to have a separate C type for each class instead of having everything be an exception object. -- Alexandre Julliard [EMAIL PROTECTED]
Re: System tray integration take 5
Mike Hearn [EMAIL PROTECTED] writes: +#define MAX_TRAY_ICONS 256 +int undockedTrayIconsCount = 0; +static HWND undockedTrayIcons[MAX_TRAY_ICONS]; /* stores HWNDs of undocked tray windows when a + NETWM tray window appears, we can dock */ You shouldn't use a global array here. This is not thread safe, plus you'd need to keep track of window destruction to remove them from the array. The right way IMO would be to walk the window tree checking for WS_EX_TRAYWINDOW at the time a tray window appears. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Mach-O Support in WineLib Loader (2) dlopen
Pierre d'Herbemont [EMAIL PROTECTED] writes: This patch provides Mach-O support in WineLib. As Mach-O doesn't have init and fini section, it adds support for it in dlopen. A new file mach-o.c is created. It contains functions which add support for init, and fini section. Isn't there any way to have an init function? How does Mach-O support C++ constructors? -- Alexandre Julliard [EMAIL PROTECTED]
Re: update Re: My wine turned to vinegar... vanilla wine isn'tbroken, is it?
Gregory M. Turner [EMAIL PROTECTED] writes: Of course, this is totally my fault for having two ntdll's in my library path... and thank goodness for make uninstall, which made fixing this easy... but, under the circumstances, shouldn't the loader be loading just /one/ ntdll, even if it's the wrong one or whatever? It's because ntdll is looked for both in WINEDLLPATH (for explicit dlopen calls) and in LD_LIBRARY_PATH (when ld.so loads dependencies), and if that yields two different files then both get loaded, with bad results as you have noticed. This will be fixed once kernel32 dll separation is finished. -- Alexandre Julliard [EMAIL PROTECTED]
Re: something I intend working on that will help make wine morecomplete
Francois Gouget [EMAIL PROTECTED] writes: IMHO the more complete our spec files the better. Even if we just add stubs. In many cases apps will check for a function existence and call it if it exists, so adding a stub can actually break things compared to not having the function at all. If you want to add all these stubs then I'd suggest commenting them out until they either get implemented, or we find an app that really needs the entry point. -- Alexandre Julliard [EMAIL PROTECTED]
Re: something I intend working on that will help make wine morecomplete
Francois Gouget [EMAIL PROTECTED] writes: We already have a lot of stubs in the spec files. Does it mean we should comment them out? Of course, that too could break applications. For functions that exist in all versions of Windows, clearly there's no point in commenting them out since apps won't have fallbacks. But for functions that have been added recently it's usually better to leave them commented out until they are needed; and in fact that's how it's done already in some of the spec files. IMHO we should add all the stubs we want and comment out only those that are confirmed to cause an application to crash. And preferably after trying to implement the stub which is of course the best solution. There is little difference between a stub and a commented out entry point, so there's no real reason to add stubs unless an app requires the entry point (in which case we'll get an error message). Adding stubs for everything will only cause more crashes without improving other apps. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Sync(20): ntdll/tests/rtlstr.c
Jon Griffiths [EMAIL PROTECTED] writes: I'm aware of that, but it doesn't come by default with visual studio.net enterprise edition. I don't see why we should require a ddk download in order to compile the tests- IMO they should work out of the box with a standard install of the tools. It's actually part of the SDK, and I think it's perfectly reasonable to require that you have an up to date SDK to build the tests. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Once again: Wine without X?
Eric Pouech [EMAIL PROTECTED] writes: It wouldn't be very difficult to set the User32 Driver on a pgm per pgm basis. Actually that's far from trivial, since many things access windows from other processes and depend on these using the same graphics driver. The right fix is to delay x11drv initialization until we really need it. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Sync(1): include/winerror.h
Jon Griffiths [EMAIL PROTECTED] writes: This patch casts hresult errors into HRESULTs as per the native headers. The native headers don't have a _HR_() macro, so we shouldn't have one either. Please do normal casts instead. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Sync (31): winbuild relay
Jon Griffiths [EMAIL PROTECTED] writes: +tools/winebuild/relay.c Remove redundant multiple calls to fprintf() There's no reason to do that. The existing code is just fine, and much easier to modify. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Sync (37): shlwapi regstream
Jon Griffiths [EMAIL PROTECTED] writes: +#ifdef __WINE_USE_MSVCRT +#define FS_I64 %I64d +#define FS_UI64 %I64u +#else +#define FS_I64 %lld +#define FS_UI64 %llu +#endif Please don't do that, it's not portable anyway. Simply print high and low part separately with something like %lx%08lx. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Sync(18): msvcrt cpp exceptions
Jon Griffiths [EMAIL PROTECTED] writes: +dlls/msvcrt/cppexcept.c strip dump code when NO_TRACE_MSGS is defined The compiler should optimize this out, and even if it doesn't that's no big deal. It certainly doesn't justify adding #ifdefs. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Sync(20): ntdll/tests/rtlstr.c
Jon Griffiths [EMAIL PROTECTED] writes:
+/* Define the undocumented types we need here as there is no native header */
+typedef struct _STRING {
+ USHORT Length;
+ USHORT MaximumLength;
+ PCHAR Buffer;
+} STRING, *PSTRING;
+typedef const STRING *PCANSI_STRING;
Actually there is a native winternl.h that defines these. You may need
to upgrade your headers.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Sync (44): documentation/Makefile.in
Jon Griffiths [EMAIL PROTECTED] writes: Yup, sadly, its too late for that. I think this is a bug in earlier db2htmls where it 'forgets' that it has decended into a directory to make the html and should adjust any relative dir paths accordingly. Later versions (correctly) fix the bug, so its more of a backwards compatability issue than having to support a bunch of truly incompatable versions, AFAICS. There's no reason to worry about being compatible with broken versions of the script; very few people need to generate the documentation, and these people can upgrade to a properly working script. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Sync (32): winbuild msvcrt
Jon Griffiths [EMAIL PROTECTED] writes: - Functions exported by name only should not be given ordinal numbers in the .def output, so that link.exe can fill up empy ordinal slots and create a valid export table. Not doing this leads to an incorrect export table without any warnings or errors during the build. We use the ordinal to generate the proper hint in the import table, so this is not a good idea. - We need the stub functions to be present in the final dll file, or our ordinal functions cannot be accessed. This is because link.exe requires that all ordinals be present in order to generate a correct ordinal export table. This in turn requires that the .spec.c files compile correctly under msvc, in order to get the stub functions included in the link. However, we obviously don't need the pe header or export tables that winebuild generates, since link.exe (and any other PE linker, for that matter) does this work for us. The .spec.c file must not be used on Windows IMO. If the MS linker is really that brain damaged then you'll need to make sure you have valid functions for all entry points, or use a better linker (mingw should work AFAIK). - Several symbols are expected to be exported as private and by name only, or they generate warnings when creating the .lib and .exp files for the dll. This requires identifying said symbols, and correctly generating and parsing the PRIVATE flag in .def files. I'd suggest specifying that in the spec file instead of hard-coding the symbols in winebuild. Also please try to split your patch, there are clearly different changes in there, it would be a lot easier to analyze them independently. -- Alexandre Julliard [EMAIL PROTECTED]
Re: PPC CPU Detection in configure
Pierre d'Herbemont [EMAIL PROTECTED] writes: Darwin's default gcc doesn't know the __PPC__ and the __powerpc__ flags, but knows the __ppc__ and the __POWERPC__ flags, no luck :( . So I think we should defined them in configure, I dont think it is a problem on the linux side, is it? No but we should pick one and use the same everywhere. I'd suggest __powerpc__. -- Alexandre Julliard [EMAIL PROTECTED]
Re: API tracking and documentation
Steven Edwards [EMAIL PROTECTED] writes: Hello, The ReactOS project is interested in making a change to WINE the function commented that would make API tracking a little nicer. We have implemented a web page like the mono project has that shows the implemented and unimplemented functions in the API. Will the WINE project accept patches to the comments to support this type of tracking system? It would be nice because you guys could implement the same thing on your website. If the answer is no it is REALLY going to be a PITA for us to diff our sources to yours for every function. I don't think we want to clutter up the source code with this kind of thing. We already have a status page on winehq.com, and while the percentages are still very approximative, at least they have some meaning. Doing statistics on the number of implemented/unimplemented functions is useless, it doesn't give any information about how well the dll will behave in real use. But if you really want to do that it should be easy to maintain a list of functions in a separate file; or you can simply grep for 'stub' in the spec files. -- Alexandre Julliard [EMAIL PROTECTED]
Re: LoadLibrary problem
Dimitrie O. Paun [EMAIL PROTECTED] writes: I'm back from my vacation! :) Welcome back! The wrapper simply does a LoadLibrary for this DLL, and this LoadLibrary call fails. Here is the relevant part of a --debugmsg +module,+server Any ideas? LoadLibrary doesn't support loading a .so directly at this point. You need to pass it the .dll name and make sure the corresponding .so can be found somewhere in WINEDLLPATH. Or you need to add .so support to LoadLibrary... -- Alexandre Julliard [EMAIL PROTECTED]
Re: CPU detection work
Mike Hearn [EMAIL PROTECTED] writes: ChangeLog: - Move performance frequency code to misc/cpu.c - New function, get_cpu_speed() - Make MHz registry key and QueryPerformanceFrequency use it I was hoping you would merge the CPU speed detection with the rest of the CPU info code, there's really no reason to parse /proc/cpuinfo twice. Also the value that QueryPerformanceFrequency returns needs to match the behavior of QueryPerformanceCounter, you can't simply divide it by 1000. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Question about improving debugging on Mingw build
Steven Edwards [EMAIL PROTECTED] writes: I am interested in improving debugging for dlls built with either Mingw or MS_VC if that is ever fixed. We are to the point now where a lot of needed dlls can be built with little or no changes and so I would like to start doing some major testing on Windows and ReactOS but I am unable to see TRACE/WARN/ERR and FIXME messages. Can we make libwine debug channels use OutputDebugString or one of the *printf functions or hell even MessageBox on Windows? The default implementation in libwine is doing a printf to stderr. Why doesn't this work for you? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Question about improving debugging on Mingw build
Steven Edwards [EMAIL PROTECTED] writes: The last time I tested I couldnt get anything to work but now FIXME and ERROR do. I guess maybe I did something wrong the last time I tried to test. Are the TRACE and WARN messages only for WINEserver? Those still dont show up for me. They are off by default, they are switched on by the --debugmsg flag, which of course doesn't work for you... you can simulate it by calling wine_dbg_parse_options() from somewhere in the app startup code. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Documentation spelling fixes 2 of 2
Tom Wickline [EMAIL PROTECTED] writes: I have spell checked most/all of the Docs :-) After these patches go in ill re-check everything again just incase I over looked something. Please don't send a separate patch for each file, that's a real pain to apply. Just send one big patch containing all the changes. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [RESENT] Subject: Release GWL_ID with DestroyMenue, eventually
Uwe Bonnes [EMAIL PROTECTED] writes: wine/controls/menu.c: DestroyMenu Release GWL_ID of lppop-hWnd if it is the same hMenu we are going to destroy This lets Capital Eimkommenssteuer 2003 (Infotax Steuer02) access it's Menu bar. This is wrong, Windows doesn't do this, and it causes trouble. We tried it once already and we had to back it out. The correct fix is to change the menu handles management to behave more like window handles. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [RESENT]: Fixed winedbg example configuration
BiGgUn [EMAIL PROTECTED] writes: Changelog: Reorder lines for a typical winedbg configuration. Your patch is wrapped; but anyway I don't see any reason to change that, keys are sorted when registry files are saved so the order doesn't matter. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Don't set stacking order against unvisible windows
Mike Hearn [EMAIL PROTECTED] writes: However, I think it unbreaks InstallShield, which is a fantastically common application. It might be a case of a lesser of two evils decision. No it's a correct vs. wrong decision. The existing code is correct and there's no reason to break it, even if doing that happens to mask another bug. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [RESENT]Don't add empty lines when writing out profile files
Uwe Bonnes [EMAIL PROTECTED] writes: Changelog: wine/files/profile.c: PROFILE_Save Don't add lines for empty sections This will cause us to delete keys that are before the first section header, I don't think that's correct. Why do you need that? -- Alexandre Julliard [EMAIL PROTECTED]
Re: iphlpapi Solaris fixes
Robert Lunnon [EMAIL PROTECTED] writes:
@@ -787,7 +789,11 @@ DWORD getInterfaceMtuByName(const char *
if ((ioctl(fd, SIOCGIFMTU, ifr)))
ret = ERROR_INVALID_DATA;
else {
+#if !defined sun
*mtu = ifr.ifr_mtu;
+#else
+ *mtu=ifr.ifr_metric;
+ #endif
You should add a configure check for the structure field.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [dx61] d3d9 guid + d3d9 header fixes
Raphaël Junqueira [EMAIL PROTECTED] writes:
Index: include/d3d9types.h
===
RCS file: /home/wine/wine/include/d3d9types.h,v
retrieving revision 1.2
diff -u -r1.2 d3d9types.h
--- include/d3d9types.h 24 Jun 2003 19:26:51 - 1.2
+++ include/d3d9types.h 27 Jun 2003 22:14:40 -
@@ -1131,8 +1131,10 @@
typedef struct _D3DADAPTER_IDENTIFIER9 {
charDriver[MAX_DEVICE_IDENTIFIER_STRING];
charDescription[MAX_DEVICE_IDENTIFIER_STRING];
-charDeviceName[32]; /* Device name for GDI (ex.
\\.\DISPLAY1) */
-LARGE_INTEGER DriverVersion;
+charDeviceName[32];
+DWORD DriverVersionLowPart;
+DWORD DriverVersionHighPart;
+
Isn't DriverVersionLow/HighPart supposed to be for 16-bit code? Why
do you need to use that instead of DriverVersion?
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Memory Protection Wierdness
Robert Lunnon [EMAIL PROTECTED] writes: But of course this code doesn't reset the page protections to allow the access. I Doctored this code so it would always allow the access and the installer then completed OK, But worms itself will not run yet Q. Should all views have handlers ? Under What Conditions would they not ??? No, most views don't need handlers. Except in specific cases like guard pages or DIB handling, if a given page is marked as no access then we very much want to crash if it is accessed. Resetting the protections on all accesses would make page protections completely useless. You'll need to investigate where that page comes from and why it's not accessible. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Mac OS X Support : Asm syntax support [Fixed]
Pierre d'Herbemont [EMAIL PROTECTED] writes: Hum... If my memory is well I do use PPC_SYM in order to convert delay_imports to _delay_imports on darwin target. the assembler syntax requires it. Yes, that's exactly what __ASM_NAME is supposed to do. If you want, but for me it seems that it is clearer this way. because you endup with things like: fprintf((output, \li PPC_REG(1) , 0\\n\\n); fprintf(outfile, \t\\\tlis PC_REG(9) PPC_LOW(delay_imports+%d,9)\\n\\n, pos); But in fact it is also readable. If you prefer this way I'll do what you like ;) IMO it would be more readable with a separate function, and then something like: fprintf( output, li %s,0, ppc_reg(1) ); -- Alexandre Julliard [EMAIL PROTECTED]
Re: [dx61] d3d9 guid + d3d9 header fixes
Raphaël Junqueira [EMAIL PROTECTED] writes: Yes, they are here for 16bit drivers. But for me its more easier to play that way than with LARGE_INTEGERs. I'll fix it when the code will work. I'm not sure I like that idea, I'm worried that if code starts depending on that it will be a pain to fix later on. If you want to write the code using 16-bit fields you can do that locally, but I'd prefer that you then fix it before submitting, so that we don't need to put wrong headers in CVS. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Don't set stacking order against unvisible windows
Uwe Bonnes [EMAIL PROTECTED] writes: Changelog: dlls/x11drv/window.c: X11DRV_sync_whole_window_position Don't specify a stacking order agains unvisible windows This will break other things. The right fix is to make the desktop option work correctly across processes. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine.texinfo.diff
Tom Wickline [EMAIL PROTECTED] writes: Changelog Change Copyright from 1997,1998 to 1997-2003 There's no reason to do that, this file hasn't really changed in a long time. -- Alexandre Julliard [EMAIL PROTECTED]
Re: XEMBED System tray support
Mike Hearn [EMAIL PROTECTED] writes: + /* now set sync the X11 window rects to the win32 window rects, + so the shell tray code can properly align the icon */ + + + XTranslateCoordinates(display, data-whole_window, root_window, + 0, 0, x, y, child); + XGetWindowAttributes(display, data-whole_window, attrs); + + wine_tsx11_unlock(); + + r.left = x; + r.top = y; + r.right = r.left + attrs.width; + r.bottom = r.top + attrs.height; + + WIN_SetRectangles(hwnd, r, r); This completely bypasses the normal window size handling, I don't think that's a good idea. Positions changes should be handled by the standard ConfigureNotify processing. -- Alexandre Julliard [EMAIL PROTECTED]
