Re: [Fwd: WineTools is in need of some major house cleaning!]
Dear developers and all others reading this list, from Sven Paschukat I was informed about the discussion of removing the WineTools link from the winehq website. I read all remarks made to that hotly discussed topic and I am willing to tell you all a bit about the purpose and history of WineTools as well as I will answer the questions made by Tom Wickline. So this will be a little longish mail and I beg your pardon for that and hope you have enough patience to read it all. To start from the beginning, I took over the remainings of a project winetools initially started by Frank Hendriksen [EMAIL PROTECTED] which was somehow orphaned. The very reason I did that was that in autumn 2004 I had to write an article in the well known German computer magazine c't. After fiddling with wine for a long time only to install a stable IE6 or Office, I found that it was so absolute complicated to describe all the steps needed only to install the IE6 (which is much better now) and that also following these steps was very erroneous, that I started to rewrite the winetools script for the readers of this article. I never meant it to become so famous and wide spread, but the download statistics after only two month showed me that there was a massive demand for such a tool. So this is how it started and it shows very clearly that it was always an installer to make certain important applications easily usable under Linux. It was never meant for testing or developing. It was always meant for the end user being able to use his software. At the time of the first releases it was almost impossible to install or work with many applications without using native DCOM and/or many of the builtin DLLs that come with the IE6. To find a configuration for as many apps as possible was one of the goals. Not to force users (with very low skills) to have many different wine installations *and* many wine user directories was a second goal. So this is the reason why, until now, everything in WineTools is based on this native M$ software (DCOM, IE6). And believe me, no one would be more happy to wipe this DCOM, IE6 and MSI stuff completely from his harddisk than me! So as so many programs rely on parts of M$ software (MFC, VB and MDAC are other important examples) and because to install and use this software leads to so many restrictions in the wine usage, I had to pin wine to the emulation of Win98 and also had to massively tamper around with DLLOverrides. The goal was to built up an environment, that can install and use as many Windows programs as possible. This did in no way regard to the fact that it is not very helpful for the wine developers. It was just a practical decision. From time to time, Sven Paschukat and me are testing wine versions to figure out, whether we can skip some of the M$ stuff. We have not been very successful with that until now, so this is why there are so many remainings of the first start of the project in the concept. But again: This tool is for the average windows user. And believe me, I tested this with my brothers, who are just normal users. And they never ever got a piece of windows software running with wine without my heavy intervention. With WineTools they just need to click on some buttons and got their software downloaded, installed and configured. With an amount of many thousand downloads a month, not calculating the distribution inclusions of WineTools, I get almost the same number of direct mails about problems with the software as are coming into the list. And I get massive positive resonance from users who were for a long time trying to get their stuff running with plain wine and are now happy that it just works with WineTools. I must admit, that there raise problems out of the fact, that the same users are trying to install not WineTools-tested software with the setup of WineTools and coming then to the list. And your are right that this is an undebuggable situation. The only way around that is to smoothly migrate WineTools to more and more builtin features as long as this does not make the programs uninstallable or unusable. Betreff: WineTools is in need of some major house cleaning! Datum: Fri, 30 Dec 2005 03:31:43 -0500 Von: Tom Wickline [EMAIL PROTECTED] An: wine-devel wine-devel@winehq.org Hello Everyone, Anyone who reads the posting on this list already knows that I stood up for the wineTools project and almost made a couple enemies... But me and Vitaliy came to a half way agreement on whether or not we should keep the link on our downloads page to WineTools I feel I need to ask a couple questions here about the future of WineTools. 1) Are the concerns that Vitaliy brought up being looked into? Sven Paschukat suggested to implement a mode for WineTools to install without native components and without that tampering in the registry. This allows automatic installations *and* insight for developers if something goes wrong. We can also add a debugging mode to enable
Re: server: Initial inotify support.
On Tuesday 24 January 2006 10:57, Mike McCormack wrote: This isn't ready yet because it cause a regression test to fail. The failure is related to calling RemoveDirectory on an open directory handle, so isn't a fault in this code. You must be referring to my evil change notification test here? Another interesting case that I didn't test would be moving a directory that has change notifications registered for it. I see you don't map IN_MOVE_SELF, which would allow us to detect this case. Any particular reason for that? -Hans
Re: LostWages: remove third party downloads section from our download page
On 1/23/06, Vitaliy Margolen [EMAIL PROTECTED] wrote: Also Tom told me that he tried to contact winetools author and have not received response from him in almost a month. I see Joachim sent a reply to the list, I suppose we should keep the link and see if we can find neutral ground. Tom Vitaliy.
Re: d3d8: CreateDevice should try the parent if the current window fails
Jan Zerebecki [EMAIL PROTECTED] writes: Changelog: d3d8: CreateDevice should try the parent if the current window fails because it doesn't have the property __wine_x11_whole_window . Fixes bug #4341 . What you really want to use here is GetAncestor(GA_ROOT). -- Alexandre Julliard [EMAIL PROTECTED]
Can't compile with vc7: oleauto.h(229) : error C2719: 'function-parameter': formal parameter with __declspec(align('8')) won't be aligned
A UCLA student trying to compile wine conformance tests on Windows
ran into this:
[Compiling wine tests with VC7 or
the server 2003 sdk gets] this error when compiling.
..\..\..\include\oleauto.h(229) : error C2719: 'function-parameter':
formal parameter with __declspec(align('8')) won't be aligned
(See http://msdn2.microsoft.com/en-us/library/373ak2y1.aspx )
Examining oleauto.h line 229, I saw the bad parameter was
of type DOUBLE.
I then went looking for the typedef for DOUBLE:
~/wine/include$ grep 'typedef.*DOUBLE' *.h
The interesting hit was:
wtypes.h:typedef double DECLSPEC_ALIGN(8) DOUBLE;
The patch that introduced the change was
http://www.winehq.com/hypermail/wine-cvs/2004/05/0027.html
I told him to try replacing DOUBLE and DATE with double
and date in the formal parameters in oleauto.h
for now. Is that generally the right thing to do?
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
Re: wine 0.9.6 segfaults-Found the problem but not the solution (was :Re: wine 0.9.5 - segmentation fault with some apps)
Hi Mike, The problem seems to be with the name of the executable: user.exe (sounds crazy, but it was I could realize after some tests). That's quite possible. user.exe is a 16 bit part of user32.dll, and Wine treats it in a special way. In fact there are a little more with same problem: start.exe and sound.dll (as reported in bugs 3950, 4351 and 4311) You might be able to add a dll override entry in winecfg like this: *user.exe = native, builtin However winecfg does not allow me to input free form strings (at least I try and could not find a way). It does only allow me to navigate throught the file system and choose the application. And the Libraries tab, in winecfg, it is only for DLL's - I guess! (Am I wrong?) The only solution I tried is using vi to edit ~/.wine/user.reg but I think I made a mistake because wien still segfaults. Here is the KEY I have put: [Software\\Wine\\AppDefaults\\*user.exe\\DllOverrides] 1138094570 *=native,builtin I have also tried a variation of it but it still segfaults when calling wine user.exe: [Software\\Wine\\AppDefaults] 1138094570 *user.exe=native,builtin Thanks - Ulisses de Sousa Penna Analista Consultor - Banco do Brasil Fone: +55-61-3310-6320 Fax: +55-61-3310-6435 -
*** No rule to make target `../../dlls/d3d9/tests/d3d9_test.exe.so',
Hello, I compiled the last few wine releases. 0.9.6 gives me a compile error: make[2]: Entering directory `/home/rd/SW.nobackup/wine-0.9.6/programs/winetest' make[2]: *** No rule to make target `../../dlls/d3d9/tests/d3d9_test.exe.so', needed by `d3d9_test.exe.so'. Stop. Any hints are welcome. Thanks, Rainer
Re: *** No rule to make target `../../dlls/d3d9/tests/d3d9_test.exe.so',
Rainer Dorsch wrote: I compiled the last few wine releases. 0.9.6 gives me a compile error: make[2]: Entering directory `/home/rd/SW.nobackup/wine-0.9.6/programs/winetest' make[2]: *** No rule to make target `../../dlls/d3d9/tests/d3d9_test.exe.so', needed by `d3d9_test.exe.so'. Stop. You're missing OpenGL headers/libraries on your system, and d3d9 isn't being build. The winetest's Makefile doesn't account for that case. Mike
Re: wine 0.9.6 segfaults-Found the problem but not the solution (was :Re: wine 0.9.5 - segmentation fault with some apps)
However winecfg does not allow me to input free form strings (at least I try and could not find a way). It does only allow me to navigate throught the file system and choose the application. And the Libraries tab, in winecfg, it is only for DLL's - I guess! (Am I wrong?) No, it can be used for .exes too, you only have to specify the full name(e.g. user.exe for user.exe compared to oleaut for oleaut.dll) I often use it for dplaysvr.exe, so it works Stefan pgpddPQomIR19.pgp Description: PGP signature
Re: *** No rule to make target `../../dlls/d3d9/tests/d3d9_test.exe.so',
On 24/01/06, Mike McCormack [EMAIL PROTECTED] wrote: You're missing OpenGL headers/libraries on your system, and d3d9 isn't being build. The winetest's Makefile doesn't account for that case. Wasn't http://source.winehq.org/git/?p=wine.git;a=commit;h=d00fe021d3add8a207f8881ccc007454d02c3494 supposed to fix that? Looking at http://test.winehq.org/data/200601211000/ they don't appear to get built on Windows.
Re: iphlpapi: remove one IP address per interface restriction
Juan Lang wrote:
+/* Enumerates the IP addresses in the system using SIOCGIFCONF, returning
+ * the count to you in *pcAddresses. It also returns to you the struct ifconf
+ * used by the call to ioctl, so that you may process the addresses further.
+ * Free ifc-ifc_buf using HeapFree.
+ * Returns NO_ERROR on success, something else on failure.
+ */
+static DWORD enumIPAddresses(PDWORD pcAddresses, struct ifconf *ifc)
+{
+ DWORD ret;
+ int fd;
+
+ fd = socket(PF_INET, SOCK_DGRAM, 0);
+ if (fd != -1) {
+int ioctlRet = 0;
+DWORD guessedNumAddresses = 0, numAddresses = 0;
+caddr_t ifPtr;
+
+ret = NO_ERROR;
+ifc-ifc_len = 0;
+ifc-ifc_buf = NULL;
+/* there is no way to know the interface count beforehand,
+ so we need to loop again and again upping our max each time
+ until returned max */
+do {
+ HeapFree(GetProcessHeap(), 0, ifc-ifc_buf);
+ if (guessedNumAddresses == 0)
+guessedNumAddresses = INITIAL_INTERFACES_ASSUMED;
+ else
+guessedNumAddresses *= 2;
+ ifc-ifc_len = sizeof(struct ifreq) * guessedNumAddresses;
+ ifc-ifc_buf = HeapAlloc(GetProcessHeap(), 0, ifc-ifc_len);
+ ioctlRet = ioctl(fd, SIOCGIFCONF, ifc);
+} while (ioctlRet == 0
+ ifc-ifc_len == (sizeof(struct ifreq) * guessedNumAddresses));
+
+if (ioctlRet == 0) {
+ ifPtr = ifc-ifc_buf;
+ while (ifPtr ifPtr ifc-ifc_buf + ifc-ifc_len) {
+numAddresses++;
+ifPtr += ifreq_len((struct ifreq *)ifPtr);
+ }
+}
+else
+ ret = ERROR_INVALID_PARAMETER; /* FIXME: map from errno to Win32 */
+if (!ret)
+ *pcAddresses = numAddresses;
+else
+{
+ HeapFree(GetProcessHeap(), 0, ifc-ifc_buf);
+ ifc-ifc_buf = NULL;
+}
+ }
+ else
+ret = ERROR_NO_SYSTEM_RESOURCES;
+ return ret;
+}
+
You leak an fd in this function.
--
Rob Shearman
Re: *** No rule to make target `../../dlls/d3d9/tests/d3d9_test.exe.so',
On Dienstag 24 Januar 2006 15:18, you wrote: Rainer Dorsch wrote: I compiled the last few wine releases. 0.9.6 gives me a compile error: make[2]: Entering directory `/home/rd/SW.nobackup/wine-0.9.6/programs/winetest' make[2]: *** No rule to make target `../../dlls/d3d9/tests/d3d9_test.exe.so', needed by `d3d9_test.exe.so'. Stop. You're missing OpenGL headers/libraries on your system, and d3d9 isn't being build. The winetest's Makefile doesn't account for that case. Hmmdo you have any file names from the OpenGL header files/libraries? Or better Debian package name? Is it right that configuring with --without-opengl would not help, because this would not impact winetest's Makefile? Is that new in 0.9.6 and was not there at 0.9.5? Thanks, Rainer
Re: [Fwd: WineTools is in need of some major house cleaning!]
Tuesday, January 24, 2006, 2:06:06 AM, Joachim von Thadden wrote: Dear developers and all others reading this list, [skip] I never meant it to become so famous and wide spread, but the download statistics after only two month showed me that there was a massive demand for such a tool. So this is how it started and it shows very clearly that it was always an installer to make certain important applications easily usable under Linux. It was never meant for testing or developing. It was always meant for the end user being able to use his software. The problem with this as I see, is that we as Wine developers creating an environment of one kind. And these tools almost totally override that environment. At the time of the first releases it was almost impossible to install or work with many applications without using native DCOM and/or many of the builtin DLLs that come with the IE6. To find a configuration for as many apps as possible was one of the goals. Not to force users (with very low skills) to have many different wine installations *and* many wine user directories was a second goal. So this is the reason why, until now, everything in WineTools is based on this native M$ software (DCOM, IE6). And believe me, no one would be more happy to wipe this DCOM, IE6 and MSI stuff completely from his harddisk than me! This is not the case anymore. But not thanks to winetools. We never get enough testing of these parts from users. Because they've been told to install m$ components to make anything to work. So as so many programs rely on parts of M$ software (MFC, VB and MDAC are other important examples) and because to install and use this software leads to so many restrictions in the wine usage, I had to pin wine to the emulation of Win98 and also had to massively tamper around with DLLOverrides. The goal was to built up an environment, that can install and use as many Windows programs as possible. This did in no way regard to the fact that it is not very helpful for the wine developers. It was just a practical decision. I'm not aware of any limitations that mfc, vb-runtime and mdac places on the system. In fact most of these components are identical in all windows versions. Also don't forget that now Wine is more win2k like then win9x. From time to time, Sven Paschukat and me are testing wine versions to figure out, whether we can skip some of the M$ stuff. We have not been very successful with that until now, so this is why there are so many remainings of the first start of the project in the concept. But again: This tool is for the average windows user. And believe me, I tested this with my brothers, who are just normal users. And they never ever got a piece of windows software running with wine without my heavy intervention. With WineTools they just need to click on some buttons and got their software downloaded, installed and configured. How often do you guys check if a piece of software can be installed on Wine as-is? Without any additional configuration or native components? The point and click user have to know what they are clicking on, or not be presented with the bad choices. With the way it is _ALL_ new times visiting http://www.winehq.org/site/download have an impressions that winetools are the absolute requirement and download and install them. I can't tell how many times I had to tell the user to vipe their ~/.wine dir and start from scratch _not_ using winetools because what they want to run does not require anything that winetools install. Also I don't see any post from you or Sven about these problems in the bugzilla. How do we know that there are any problems? With an amount of many thousand downloads a month, not calculating the distribution inclusions of WineTools, I get almost the same number of direct mails about problems with the software as are coming into the list. And I get massive positive resonance from users who were for a long time trying to get their stuff running with plain wine and are now happy that it just works with WineTools. Well yeah, you just riding on the back of Wine. As I mentioned before, every single person visiting download page thinks that winetools are something mandatory. Can we see some of those responses? I really like too see what programs run and don't run with and without winetools. Also please redirect all those users to appDB. We need information there available for everyone to see, not in your e-mail box (no offence). I must admit, that there raise problems out of the fact, that the same users are trying to install not WineTools-tested software with the setup of WineTools and coming then to the list. And your are right that this is an undebuggable situation. The only way around that is to smoothly migrate WineTools to more and more builtin features as long as this does not make the programs uninstallable or unusable. There should be _no such software_. The winetools have to setup environment in a
Re: [Fwd: WineTools is in need of some major house cleaning!]
Hm. Felt I needed to offer a counterpoint to Vitaliy's rather enthusiastic response. I support winetools, though I don't use it myself. Not only as a matter of principle (this is open source we're talking about, and one of the beauties is we don't get to constrain how it's used.) Also because it's in line with the aims of the Wine project: run Windows apps. Wine is nice in that it doesn't require you to have any MS license to run Windows apps, but it can use MS software if you have a licensed copy. So winetools offers folks with MS licenses a relatively easy way to get apps to run. Still, while that's nice for the users, it's not so nice for us Wine developers, because it's hard to get widespread testing of things we're improving if they're not being widely used. So, as Vitaliy suggested, it would be nice for us if you guys, who know what problems you encounter running with builtin DLLs, could file bug reports in bugzilla for us. That way at least we have a chance to say, hey, that problem's now fixed, consider using builtin OLE (or whatever) in the next release of winetools. Now for specifics. For instance, you use native advpack in all cases, but that's seen some more work recently. What bugs do you encounter if you use builtin instead? Same with ole32. Ideally, each of the apps that has a native override should have a bug report associated with it, what goes wrong if you use the builtin version instead. Also, the default override, *=native,builtin seems wrong. If we don't have a DLL at all, we use a native version of course. I don't think it should be the policy to assume the Wine version isn't up to snuff by default. This could even cause problems, e.g. I don't believe any native version of netapi32.dll will work on Wine, yet you don't specify to use the builtin version. Also, you direct users to http://winehq.org/site/forums. That's fine since this is community support anyway, and it is often the case that winetools knowledgeable people are around (like you guys.) But it would be nicer if you could be clearer about it. Like, that we developers had nothing to do with it, and may be unfriendly to it if we're in a bad mood, or it's a Tuesday :) It'd also be nice (for us, even though no one actually reads anything these days) if you could be clearer about what it does. That it installs MS components, that it uses these instead of the builtin versions sometimes, that you can change how it does this using winecfg, etc. That'd make it easier for us to help folks that have only used winetools that want support, because often the first question we ask is, what version of wine, and what DLLs are you using? --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [Fwd: WineTools is in need of some major house cleaning!]
I'm not sure we need a counterpoint to Vitaliy. The fact that it took over a month to hear back from the winetools guys seems like reason enough to pull it from the downloads page. Winetools might be a useful tool but we can't have wine's users depending on them if we developers can't get ahold of them and figure out when some of these issues mighe be addressed. Even if these issues are addressed we really should consider the side effects of relying on installing ms components to get applications to run. Chris On 1/24/06, Juan Lang [EMAIL PROTECTED] wrote: Hm. Felt I needed to offer a counterpoint to Vitaliy's rather enthusiastic response. I support winetools, though I don't use it myself. Not only as a matter of principle (this is open source we're talking about, and one of the beauties is we don't get to constrain how it's used.) Also because it's in line with the aims of the Wine project: run Windows apps. Wine is nice in that it doesn't require you to have any MS license to run Windows apps, but it can use MS software if you have a licensed copy. So winetools offers folks with MS licenses a relatively easy way to get apps to run.
Re: Winelib debugging with eclipse in fc4
On Sat, 2006-01-07 at 18:04 +0100, Eric Pouech wrote: Michael Ost wrote: A while back I posted a question about how to get debugging working with eclipse in fedora 4. I am having some success, so if anyone else out there is interested here's how it is set up. you could (not tested) alternatively: - set winegdb --gdb as the name for executing gdb - not reset the AeDebug key - set the executable to be the real exec (+ .so extension if run from the build tree) that should work also Just tried this and eclipse says Exec error: Cannot run winedbg --gdb. winedbg --gdb MYAPP does launch from the command line, however. Any suggestions? BTW winedbg MYAPP ARGS works better. with the --gdb flag MYAPP doesn't terminate properly. But I'll get to that later. you would this way: - keep all the preloader stuff, so that your memory layout is better (and the same than when run from command line) - still be compatible with the segfault stuff Agreed, if I can get it to work! Thanks ... mo
Re: d3d8: CreateDevice should try the parent if the current window fails
On 24/01/06, Jan Zerebecki [EMAIL PROTECTED] wrote: Changelog: d3d8: CreateDevice should try the parent if the current window fails because it doesn't have the property __wine_x11_whole_window . Fixes bug #4341 . Does that happen in wined3d as well? If so, it's probably usefull to fix wined3d as well, considering the idea is to make d3d8 use wined3d eventually.
Re: Winhelp - Derive 6
Felix Möller wrote: Hi, Is winhelp supposed to be able to handle these help files? It is listed in the appdb as gold-supported. no. basically, the external DLL registers back into winhelp to get some extended support that we don't provide yet. Basically, most of the core logic is here, but we have to wrap it into the APIs designed for those winhelp plugin DLLs. You also it some bugs in the decompression scheme for help files. Basically, all of this is rather low priority, but if someone wants to jump in, I can boot strap him on those issues. As we do own Windows 98 licenses, it would be no problem to use real Windows 98 DLLs. Is there a chance to get any further with this approach? Of Which DLLs or programs should I try to use the native ones? run native winhelp.exe (or winhlp32.exe) depending on which exe your app loads There are several other errors I see using derive, but I will have to do some more research. An easy bug is probably that the user just gets a black window after clicking on about wine. may be linked to the external DLL required for some action here. I will do some more investigation. At least with the default log-level wine is not reporting any oddities. well, you got oddity about the missing winhlp plugin architecture -- Eric Pouech
RE: Windows manager
Ok, I think I solved my own problem. In x11drv/window.c we see that full-screen popup windows are managed. If I don't rotate the screen we are no longer a full-screen pop-up. My bad. Phil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Lodwick Sent: Tuesday, January 24, 2006 11:47 AM To: wine-devel@winehq.org Subject: Windows manager I have an application that does not seem to appear to the Window Manager. I am using fvwm. To confirm I am running fbpanel which basically does a: XGetWindowProperty(GDK_DISPLAY(), GDK_ROOT_WINDOW, a_NET_CLIENT_LIST, 0, 0x7fff, 0, XA_WINDOW, ...); and the window never appears on its list. The strange thing is if I rotate the screen in my XF86Config-4 file, the window DOES appear on the list and I can use fbpanel to select the window, bring it to the front, etc. Anybody have an idea as to what difference rotating the screen would make? Thanks, Phil
Re: LostWages: add a note to the WineTools link
On Tue, 2006-01-24 at 21:01 +0100, Sven Paschukat wrote: as Vitaly noted it is not always clear that WineTools is not a requirement for using Wine, so let the users decide if they want to test or just want to use Wine. ... or if you want to get best chances of success ... I'd suggest to remove this wording, that's not (necessary) true. -- Dmitry.
Re: [patch] riched20 conformance test
On Fri, 20 Jan 2006 11:23:40 +0900, Mike McCormack [EMAIL PROTECTED] said: If you're submitting the patch, make sure to send it to [EMAIL PROTECTED] as that's the only place that patches will be picked up from. Will do with this (smaller) patch! * You linked the test with riched20.dll, so the following call should always succeed. Since you're trying to write a test, maybe that's what you want. If you're trying to be safe incase there's a Windows platform that doesn't have RICHED20.DLL, it won't work. Also, you probably want a FreeLibrary() at the end if you have a LoadLibrary. Perhaps you just want GetModuleHandle() instead? + hmoduleRichEdit = LoadLibrary(RICHED20.DLL); It's looking like riched20.lib isn't actually getting linked because the conformance test doesn't directly call any of its functions. [I buy the explanation at http://groups.google.com/group/microsoft.public.vc.language/browse_thread/thread/9a0d302fc2ab344f/e0074604a4fd7d53#e0074604a4fd7d53]. I kept the LoadLibrary() and added its dual. I addressed all the other issues that you brought up (thanks!) and stripped out several of the tests to make a smaller patch. You can find it at http://www.seas.ucla.edu/~kho/wine/patches/riched20_test_20060124.patch It needs an update to the configure script (`autoconf`), or the patch in this post applied: http://www.winehq.org/pipermail/wine-devel/2006-January/044269.html Thanks, Tommy Kho
Re: user: Don't drop owned windows in WIN_EnumChildWindows.
On Tue, 2006-01-24 at 12:56 -0700, Vitaliy Margolen wrote: ChangeLog: user: Don't drop owned windows in WIN_EnumChildWindows. Add few tests to test this. It would be interesting to add IsChild calls in there and see what they return. We have at least one failing test in msg.c, test_DestroyWindow() which shows that our IsChild implementation is not entirely correct. -- Dmitry.
Re: Winelib debugging with eclipse in fc4
Michael Ost wrote: On Sat, 2006-01-07 at 18:04 +0100, Eric Pouech wrote: Michael Ost wrote: A while back I posted a question about how to get debugging working with eclipse in fedora 4. I am having some success, so if anyone else out there is interested here's how it is set up. you could (not tested) alternatively: - set winegdb --gdb as the name for executing gdb - not reset the AeDebug key - set the executable to be the real exec (+ .so extension if run from the build tree) that should work also Just tried this and eclipse says Exec error: Cannot run winedbg --gdb. winedbg --gdb MYAPP does launch from the command line, however. Any suggestions? BTW winedbg MYAPP ARGS works better. with the --gdb flag MYAPP doesn't terminate properly. But I'll get to that later. you mean (about MYAPP ARGS) when run in eclipse (that it does work to some extend, wheread MYAPP fails) ? -- Eric Pouech
Re: wine and jack = segfault? / wine and OSS not working
Then a ran Wine with the OSS-output driver while using a tool called oss2jack (makes a kernel device and re-routes all OSS connections to the jack daemon). Surprisingly that does NOT work, too. Although other OSS apps (skype, et, vlc, cedega (oss) ...) run really *very good* over oss2jack. There is one difference then: Using OSS-output driver, Wine does not segfault! The M$ Media Player just tells me, that it cannot access audio hardware. can you post a +winmm,+oss,+wave trace ? TIA -- Eric Pouech
Re: Winelib debugging with eclipse in fc4
On Tue, 2006-01-24 at 22:27 +0100, Eric Pouech wrote: Michael Ost wrote: BTW winedbg MYAPP ARGS works better. with the --gdb flag MYAPP doesn't terminate properly. But I'll get to that later. you mean (about MYAPP ARGS) when run in eclipse (that it does work to some extend, wheread MYAPP fails) ? No, that running winedbg MYAPP from the command line works. And that winedbg --gdb MYAPP from the command line doesn't terminate properly. I tried those as a way to confirm that what I am asking eclipse to do for debugging actually works from the command line. Cheers... mo
Re: Problem with WineD3D Surface Locking
Did you ever figure this one out? For what it's worth, the program works for me with Mesa and remote X as well (after fixing IWineD3DImpl_FillGLCaps). No, but I haven't tried for quite a while. What did you fix in IWineD3DImpl_FillGLCaps? Stefan pgpc35RaMmWsw.pgp Description: PGP signature
Re: Regarding Implementation of Microsoft Speech SDK using wine
Mike McCormack wrote: Kalpit Shah wrote: I want to implement the Microsoft Speech SDK using wine on Fedora Core 3. How feasible is this.can anyone give me an insight on how do i go about doing this. please give me some orientation. The first step is to familiarize yourself with the Speech SDK's API on Windows. Perhaps write a simple test program that uses it, then try run it on Wine. The test program can later be submitted as part of the Wine regression test suite. Once you've done that, it should be a bit clearer which dll or OLE interface you need to implement to make it work. Someone has made Festival connect to the MS Speech API on Windows; it might be possible to run that Windows port under Wine, or use a similar method to link to the native Linux version (see https://lists.berlios.de/pipermail/festlang-talk/2006-January/000717.html ). Another possiblility would be to use JNI to call the FreeTTS libraries. Is there any reason why a Wine DLL can't dynamically link to Java? -- DLL
Re: HW address w/o connection in iphlpapi
Wait. This works better than getifaddrs. It successfully returns info for down devices on my RH8 based linux box, with my creaky old wine-20050419. (snip) Yikes! It turns out if_nameindex() doesn't return info for down devices, but if_indextoname() does. It's all so touchy... So, attached is an alternate patch using if_indextoname() that does work; my last one doesn't. Just for kicks I also attached a cpp file adapted from MSDN that can do a quick test. To build it do: $ wineg++ -c show-eths.cpp $ wineg++ -o show-eths.exe.so show-eths.o $ wine ./show-eths.exe.so You should get a listing for eth0 whether you boot with an ethernet connection or not. Note that to witness the problem you have to actually reboot with no ethernet connection. Just doing ifdown eth0 isn't enough. Cool, thanks for that. Like I mention in the comments, if_nameindex has the disadvantage that it doesn't handle virtual interfaces. I'll try to hack this up to use a combination of if_nameindex and SIOCGIFCONF if I can, but feel free to beat me to it ;) I'm betting you'll get there first! %) ... mo wine-20050419-muse-ifenum.patch Description: Binary data show-eths.cpp Description: Binary data
Re: HW address w/o connection in iphlpapi
Yikes! It turns out if_nameindex() doesn't return info for down devices, but if_indextoname() does. It's all so touchy... So, attached is an alternate patch using if_indextoname() that does work; my last one doesn't. Really? It works for me. You mean boot with no link, or what? I did that, and if_nameindex still returned eth0. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [Fwd: WineTools is in need of some major house cleaning!]
Am Tue, Jan 24, 2006 at 09:20:56AM -0700 schrieb Vitaliy Margolen: How often do you guys check if a piece of software can be installed on Wine as-is? Without any additional configuration or native components? With every major release. The point and click user have to know what they are clicking on, or not be presented with the bad choices. With the way it is _ALL_ new times visiting http://www.winehq.org/site/download have an impressions that winetools are the absolute requirement and download and install them. I do not know whether this is true. Me myself never looked into the third party section. I also do not see why anyone will think out of the title 3rd Party Tools that WineTools is an absolute requirement. I can't tell how many times I had to tell the user to vipe their ~/.wine dir and start from scratch _not_ using winetools because what they want to run does not require anything that winetools install. Also I don't see any post from you or Sven about these problems in the bugzilla. How do we know that there are any problems? With an amount of many thousand downloads a month, not calculating the distribution inclusions of WineTools, I get almost the same number of direct mails about problems with the software as are coming into the list. And I get massive positive resonance from users who were for a long time trying to get their stuff running with plain wine and are now happy that it just works with WineTools. Well yeah, you just riding on the back of Wine. As I mentioned before, Thank you! Your are such a polite person. And you are reading so well. I never stated that I get positive resonance for Wine. And I never aimed to get the cheers for Wine. Think what you are posting! every single person visiting download page thinks that winetools are something mandatory. And I don't see that as I mentioned. Can we see some of those responses? I really like too see what programs run and don't run with and without winetools. Also please redirect all those users to appDB. We need information there available for everyone to see, not in your e-mail box (no offence). The questions I get are almost all about WineTools, not about crashing programs. Most users of WineTools install only what they can with WineTools as of a lack of skill on the command line. The ones that really want to get a program running with what ever setup come to the list. I must admit, that there raise problems out of the fact, that the same users are trying to install not WineTools-tested software with the setup of WineTools and coming then to the list. And your are right that this is an undebuggable situation. The only way around that is to smoothly migrate WineTools to more and more builtin features as long as this does not make the programs uninstallable or unusable. There should be _no such software_. The winetools have to setup Well, you will allow that there other opinions in the world, will you? environment in a such a way that it is unified! If you saying that all you did is tinkered with lots of stuff to get few applications to work, this in not good. Wine is not cedega designed to run games and games You will not be able to force people to use wine for what *you* think is right. It is good for what it is working for. only. That just proves my point that environment you have setup with winetools is less flexible and more restrictive then Wine itself. I am sure it is. So it might only work for the few apps it is meant for. And that is the only purpose. Betreff: WineTools is in need of some major house cleaning! Datum: Fri, 30 Dec 2005 03:31:43 -0500 Von: Tom Wickline [EMAIL PROTECTED] An: wine-devel wine-devel@winehq.org I first would like to ask you if this is the standard response time? If Wine changes something big that brakes Wine, how long will that take for you or Sven to fix winetools? I had holidays and many things to do after returning home. And as we are not commercial we do not have a standard response time. We also do not test every new version of Wine, because the stock of programs supported by WineTools need some time to test. So as Cedega or CrossOver do we stick on a version with our setup for a while. Hello Everyone, Anyone who reads the posting on this list already knows that I stood up for the wineTools project and almost made a couple enemies... But me and Vitaliy came to a half way agreement on whether or not we should keep the link on our downloads page to WineTools I feel I need to ask a couple questions here about the future of WineTools. 1) Are the concerns that Vitaliy brought up being looked into? Sven Paschukat suggested to implement a mode for WineTools to install without native components and without that tampering in the registry. This allows automatic installations *and* insight for developers if something goes wrong. We can also add a debugging mode to enable the logging
Re: HW address w/o connection in iphlpapi
Really? It works for me. You mean boot with no link, or what? I did that, and if_nameindex still returned eth0. Right. if_nameindex does not return eth0 if I boot up without an ethernet connection. Maybe this is a system dependent thing? I am running on a RH8 based system. The if_nameindex code looked a little nicer, but a loop on if_indextoname() is not so bad. - mo
Re: [Fwd: WineTools is in need of some major house cleaning!]
Am Tue, Jan 24, 2006 at 09:16:21AM -0800 schrieb Juan Lang: I support winetools, though I don't use it myself. Not only as a matter of principle (this is open source we're talking about, and one of the beauties is we don't get to constrain how it's used.) Also because it's in line with the aims of the Wine project: run Windows apps. Wine is nice in that it doesn't require you to have any MS license to run Windows apps, but it can use MS software if you have a licensed copy. So winetools offers folks with MS licenses a relatively easy way to get apps to run. That's the point. Still, while that's nice for the users, it's not so nice for us Wine developers, because it's hard to get widespread testing of things we're improving if they're not being widely used. So, as Vitaliy suggested, it would be nice for us if you guys, who know what problems you encounter running with builtin DLLs, could file bug reports in bugzilla for us. That way at least we have a chance to say, hey, that problem's now fixed, consider using builtin OLE (or whatever) in the next release of winetools. While migrating we will do so. Now for specifics. For instance, you use native advpack in all cases, but that's seen some more work recently. What bugs do you encounter if you use builtin instead? Same with ole32. Ideally, each of the apps that has a native override should have a bug report associated with it, what goes wrong if you use the builtin version instead. Also, the default override, *=native,builtin seems wrong. If we don't have a DLL at all, we use a native version of course. I don't think it should be the policy to assume the Wine version isn't up to snuff by default. This could even cause problems, e.g. I don't believe any native version of netapi32.dll will work on Wine, yet you don't specify to use the builtin version. We will investigate that during the next tests. Also, you direct users to http://winehq.org/site/forums. That's fine since this is community support anyway, and it is often the case that winetools knowledgeable people are around (like you guys.) But it would be nicer if you could be clearer about it. Like, that we developers had nothing to do with it, and may be unfriendly to it if we're in a bad mood, or it's a Tuesday :) I made a suggestion for a prominent dialog box at startup in my last mail. It'd also be nice (for us, even though no one actually reads anything these days) if you could be clearer about what it does. That it installs MS components, that it uses these instead of the builtin versions sometimes, that you can change how it does this using winecfg, etc. I am not sure how we can provide that... this is more a question of a manual which will never be read by these people. Hmm, something like a status report together with some prominent debug channels could be a solution. But I don't think that leads to something as long as we use native libs. Regards Joachim von Thadden -- Never touch a running system! Never run a touching system? Never run a touchy system!!!
Re: Should the AppDB make public the number of unique page views each app gets?
Sounds like a pretty reasonable thing to me. Anyone interested in whipping up a patch to store application family/version views? How to count the non-generated page views? Chris On Saturday 19 November 2005 4:39 pm, Scott Ritchie wrote: This was an idea we discussed in IRC for a short bit, and I think it would be good to bring it up here. Essentially, if the AppDB displayed the number of page views each app got it would go a long way towards estimating the demand for particular applications, whether they work or not. It seems fair to say that someone looking an app up in the AppDB either wants to run it in Wine or wants to know if it's doable should he switch to Wine. Coincidentally, this also helps solve the voting problem - since votes for gold apps are supposed to be replaced with votes for apps that work should be done on, we now have a mechanism to sort the Gold list other than by votes. Sorting the gold list by page views would also greatly help navigation from the front page of the AppDB, as it would place the most popular applications at the top. Then again, maybe there's something I've overlooked. Thoughts? -Scott Ritchie
Re: [Fwd: WineTools is in need of some major house cleaning!]
Joachim von Thadden wrote: I understand the goal of WineTools and I can see both sides of this issue but for for some of us it really is frustrating because it makes our jobs harder. The purpose of WineTools is not to undermine and also it is, was and will never meant to be a pure replacement of windows. And this is nowhere stated. To come to an end with this discussion I would suggest the following: - adding a list wine-winetools for WineTools users This would be nice but who is supposed to host the mailing list. It could be just a news group though. - adding a warning in the software and on the WineTools site that the usage of the software leads to undebuggable situations for developers, so no help from there can be expected This would be good - changing the text in the download section according (there is already a note stating to use pure wine first) This new note is confusing still (I will submit a better patch) - smoothly migrating the WineTools to pure Wine with as less as possible tweaking There should be a way to do this. Making this list more prominant and updating it when wine tools is not required would help. http://www.von-thadden.de/Joachim/WineTools/wt0.9jo.html -- Thanks Tony Lambregts
[Lostwages] Re: lostwages/templates/en download.template
Jeremy Newman wrote: ChangeSet ID: 22527 CVSROOT:/opt/cvs-commit Module name:lostwages Changes by: [EMAIL PROTECTED] 2006/01/24 14:26:23 Modified files: templates/en : download.template Log message: based on patch from: Sven Paschukat [EMAIL PROTECTED] add a note to the WineTools link Patch: http://cvs.winehq.org/patch.py?id=22527 Old revision New revision Changes Path 1.72 1.73 +8 -3 lostwages/templates/en/download.template Index: lostwages/templates/en/download.template diff -u -p lostwages/templates/en/download.template:1.72 lostwages/templates/en/download.template:1.73 --- lostwages/templates/en/download.template:1.72 24 Jan 2006 20:26:23 - +++ lostwages/templates/en/download.template24 Jan 2006 20:26:23 - @@ -122,13 +122,18 @@ for post-installation instructions./b /a /td td align=left bgcolor=#ff - ba href=http://www.von-thadden.de/Joachim/WineTools/;Wine Tools/a/b - WineTools is a menu driven installer for installing Windows programs. This software lets you install the following Windows software: DCOM98, IE6, Windows Core Fonts, Windows System Software, Office amp; Office Viewer, - Adobe Photoshop 7, Illustrator 9 and many other programs. - By a href=http://www.von-thadden.de/Joachim/WineTools/;Joachim von Thadden/a. + Adobe Photoshop 7, Illustrator 9 and many other programs.br / + By a href=http://www.von-thadden.de/Joachim/WineTools/;Joachim von + Thadden/a.br / + div style=margin: 10px; padding: 5px; border: 1px solid #C0C0C0; background-color: #F0F0F0; +bNote:/b WineTools only recommended if installation or operability of +Windows software failed on pure Wine or because the Wine developers need +your feedback from testing. + /div /td /tr /table Wine developers do not want feed back of bugs in programs with winetools installed Change Log: update note to the WineTools link Files Changed: lostwages/templates/en download.template Index: templates/en/download.template === RCS file: /home/wine/lostwages/templates/en/download.template,v retrieving revision 1.73 diff -u -r1.73 download.template --- templates/en/download.template 24 Jan 2006 20:26:23 - 1.73 +++ templates/en/download.template 25 Jan 2006 03:27:01 - @@ -131,8 +131,9 @@ Thadden/a.br / div style=margin: 10px; padding: 5px; border: 1px solid #C0C0C0; background-color: #F0F0F0; bNote:/b WineTools only recommended if installation or operability of -Windows software failed on pure Wine or because the Wine developers need -your feedback from testing. +Windows software failed on pure Wine. Since winetools radically alters your +Wine configuration please do not report bugs in programs with WineTools +installed. /div /td /tr
Re: HW address w/o connection in iphlpapi
Right. if_nameindex does not return eth0 if I boot up without an ethernet connection. Maybe this is a system dependent thing? I am running on a RH8 based system. Or a libc thing? I'm running on FC2. The if_nameindex code looked a little nicer, but a loop on if_indextoname() is not so bad. Although I don't like the idea of predefined limits :) I'll probably submit a patch based on if_nameindex in the meantime, hopefully tomorrow if Alexandre commits the patch I already sent today. It removes a lot of the silliness of ifenum.c, so aside from not directly solving your problem, take a look at that and perhaps patch it. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Global hooks problems (WH_MOUSE_LL)
Trying to track down the problem with our DInput implementation I found some interesting stuff - our global hooks don't work correctly because hook callbacks are never called if event is generated in the different thread. I don't think this is a revelation to number of people who knew that before. But how do we fix it? Her is what I dug up so far: 1. Installing global hook we setting it as WINEVENT_INCONTEXT while msdn and tests indicate that it qualifies as WINEVENT_OUTOFCONTEXT instead. Unless of course we don't want to call post_win_event in step 5 and go to step 6 instead. 2. All HW mouse messages start here: http://source.winehq.org/source/dlls/x11drv/mouse.c#L191 From looking at it I assume that all the HW mouse hooks should be handled by HOOK_CallHooks function. This is because there are no code related to hooks in send_message server call. 3. First thing that HOOK_CallHooks does is calling HOOK_IsHooked with checks only current thread for installed hooks. So this is first place that is wrong. Let's comment that check out for now. I think we need to move that check farther down, after the call to server. 4. We call start_hook_chain http://source.winehq.org/source/server/hook.c#L468 to start hook callback chain. There we call get_first_valid_hook on local and then global if no local hooks exist. But there again we check for http://source.winehq.org/source/server/hook.c#L211 the hook callback thread being local (which is again not the case for global hooks). This is problem #2. 5. Now we have post_win_event of but right before it we hitting an assert so this is not the right way? 6. Say we returned with success and back to HOOK_CallHooks that now tries to call MSG_SendInternalMessageTimeout. Which for some reason fails to deliver message to our global hook. So my question is to anyone who knows. What is the proper way to deliver these messages to global hooks that are in a different thread/process? Attached is the small program to test part of this. Fixing problems (1) (2) made it work. But it still not enough for the game (for some reason). Vitaliy hooks_test.tar.bz2 Description: Binary data
