Re: Wine and serial port AGAIN
Hi! Wolfram == Wolfram Sang wolf...@the-dreams.de writes: ... Wolfram No need to do this. Vijay just needs to Wolfram 1) read Documentation/SubmittingPatches 2) consult the Wolfram MAINTAINERS file (or use scripts/get_maintainer.pl) (you can Wolfram set me on CC, too) 3) send the patch 4) wait for comments 5) if Wolfram not applied goto 3 Wolfram No magic involved :) Only patience and perstistance needed ... Not a problem here. Thanks to Vijay, I can keep my kernels with his individual patches until they are included in the mainstream. The only thing I'm thinking about now is, how to make this information more publicly available, to help the others to find the patches. Do you think that this mailing list is enough ? And hopefully more feedback than on wine-devel ... Of course... With regards, Pavel -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Wine and serial port AGAIN
Hi! It would be very good! I'm voting even for including the 2.6.36 version into the next .36 patch (probably .36.3). I can contact Pavel Machek, which has a lot of drivers in the kernel, but if anybody here could push it to the sources directly, it would be better. Regards, Pavel Hi All, Can anyone tell me how to get that into the mainline kernel ASAP. Or Anyone can send it on my behalf to lkml list to get it into main line Thanks, Vijay On Sat, Dec 18, 2010 at 2:20 AM, Pavel Troller pat...@sinus.cz wrote: On Fri, Dec 17, 2010 at 8:42 AM, Wolfram Sang wolf...@the-dreams.de wrote: OT: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0bca1b913affbd7e2fdaffee62a499659a466eb5 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d281da7ff6f70efca0553c288bb883e8605b3862 This is kernel related :P Ehrm, where does that add a handler for pl2303.c? I just made a patch for it. Its not there in the kernel yet. I need someone to test it. Hi Vijay! IT WORKS!!! It REALLY works! Sorry for yelling, but it's really working! I've used the 2.6.36 version, which Vijay sent me privately, after adding a missing semicolon it compiled cleanly and since the first attempt, the program writes the radio PERFECTLY! It's even better than on windows, because on my colleague's computer, attempt to program the radio always gives error for the first time and one must click Retry. The second attempt is then OK. Here, it works without any glitch! So, really many thanks to Vijay and all the experts here, which found the real cause of this problem! And sorry for blaming wine, it was not its fault! With regards, Pavel
Re: Wine and serial port AGAIN
On Fri, Dec 17, 2010 at 8:42 AM, Wolfram Sang wolf...@the-dreams.de wrote: OT: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0bca1b913affbd7e2fdaffee62a499659a466eb5 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d281da7ff6f70efca0553c288bb883e8605b3862 This is kernel related :P Ehrm, where does that add a handler for pl2303.c? I just made a patch for it. Its not there in the kernel yet. I need someone to test it. Hi Vijay! IT WORKS!!! It REALLY works! Sorry for yelling, but it's really working! I've used the 2.6.36 version, which Vijay sent me privately, after adding a missing semicolon it compiled cleanly and since the first attempt, the program writes the radio PERFECTLY! It's even better than on windows, because on my colleague's computer, attempt to program the radio always gives error for the first time and one must click Retry. The second attempt is then OK. Here, it works without any glitch! So, really many thanks to Vijay and all the experts here, which found the real cause of this problem! And sorry for blaming wine, it was not its fault! With regards, Pavel
Wine and serial port AGAIN
Hi!
As a technician, I need often to use some form of serial port communication.
My recent experience is with a program for programming TYT radios from China.
They supply a simple windows app, which allows to program all the features of
the radio, which cannot be accomplished using the radio keyboard only.
The program works perfectly in wine, with one exception - a physical comms
with the radio. It complains that it doesn't receive a response from the radio,
while the radio crashes - it stops working, when a programming attempt is made,
and has to be power-cycled.
The radio is connected using a USB cable, which contains just a regular
PL-2303 USB to serial converter, which is perfectly supported in Linux.
Port assignment for wine is also done, proof of which is, that the radio
crashes upon the programming request. The data volume to be programmed is
small, just a few hundreds of bytes. It's really stupid that I can prepare my
data in the program only, and then I need to ask my colleague with real windows
to perform a programming job :-(.
The program can be freely downloaded from the TYT pages:
http://www.tyt888.com/WebEditor/UploadFile/201096144939483.rar
but a real radio is needed to debug the comms problem. I've captured the
console output with WINEDEBUG=+comm, which is attached. It contains a log of
three consecutive attempts to program the radio. I'm ready to do more debugging,
but I don't know, how to proceed now.
With regards, Pavel.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,1086,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32fa80),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13e7d8),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13e850),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13eb68),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ebe0),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ec58),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ecd0),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ed48),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13edc0),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ee38),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13eeb0),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13ef28),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13efa0),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13f018),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9c2d6c,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x13f090),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9cfc9c,5774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32f63c),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9cfc9c,5774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32f63c),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9cfc9c,5774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32f63c),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9cfc9c,5774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32f63c),
partially implemented.
fixme:ole:OleLoadPictureEx
(0x9cfc9c,5774,1,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x32f63c),
partially implemented.
fixme:ole:OLEPictureImpl_SaveAsFile (0x12e580)-(0x181088, 0, (nil)), hacked
stub.
trace:comm:SetCommMask handle 0x78, mask 1fd
trace:comm:io_control 0x78 IOCTL_SERIAL_SET_WAIT_MASK 0x32f3d4 4 (nil) 0
0x32f374
trace:comm:io_control 0x78 IOCTL_SERIAL_SET_QUEUE_SIZE 0x32f3b4 8 (nil) 0
0x32f370
fixme:comm:set_queue_size insize 1024 outsize 512 unimplemented stub
trace:comm:io_control 0x78 IOCTL_SERIAL_PURGE 0x32f3d4 4 (nil) 0 0x32f374
trace:comm:SetCommTimeouts (0x78, 0x32f40c)
trace:comm:io_control 0x78 IOCTL_SERIAL_SET_TIMEOUTS 0x32f3a8 20 (nil) 0
0x32f364
trace:comm:GetCommState handle 0x78, ptr 0x32f418
trace:comm:io_control 0x78 IOCTL_SERIAL_GET_BAUD_RATE (nil) 0 0x32f3e8 4
0x32f378
trace:comm:io_control 0x78 IOCTL_SERIAL_GET_LINE_CONTROL (nil) 0 0x32f3ed 3
0x32f378
trace:comm:io_control 0x78 IOCTL_SERIAL_GET_HANDFLOW (nil) 0 0x32f3cc 16
0x32f378
trace:comm:io_control 0x78
Re: Mockba to Berlin game - mouse not clicking
2010/1/22 Vitaliy Margolen wine-de...@kievinfo.com: Pavel Troller wrote: BUT: The mouse buttons are DEAD. All I cannot left-click, right-click, mid-click, simply nothing. Sounds like a new bug in wined3d. Try older Wine version(s) (wine-1.1.28 ish). Yeah, if the game uses ddraw it's probably the same issue as http://bugs.winehq.org/show_bug.cgi?id=21025. Hi! But the bug, together with other similar ones, has been closed as fixed in 1.1.36, while this bug is still here. I cannot test the game with wine-1.1.34, because it crashes and ends up in wine debugger. So it will be probably another issue. Are there any traces available to activate to further debug the problem? With regards, Pavel
Mockba to Berlin game - mouse not clicking
Hi! My son bought a game DVD bound to a youngster's magazine. It contains a 5 years old game by Monte Cristo Multimedia, called Mockba to Berlin. We were trying this game with wine 1.1.36. The game PERFECTLY installs and then PERFECTLY launches, going through all the initial screens and videos. It then renders a primary menu on the screen, allowing to start a new game, load a save, perform some settings, etc. The mouse cursor is fully functional, the hovered item gets brightened and an explanatory text appears, which tells, what the particular item is for. BUT: The mouse buttons are DEAD. All. I cannot left-click, right-click, mid-click, simply nothing. It' very frustrating, it looks that just ONE CLICK remains to start the game, but you can't do it! There is no console output related to the problem, just some warnings from the GL renederer, which seem harmless. There is no AppDB entry for this game (we didn't found any), so we cannot follow any hints, how to solve the problem. The game was tested on 3 different machines but with the same wine installation. The results were identical. Are there any general tips, what we can try to solve the problem ? With regards, Pavel
Betamax VoIP programs - a new try
))
fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)-((null) 29 2 0x33dbbc (nil))
fixme:shdocvw:ClOleCommandTarget_Exec
(0x1ac7a0)-({000214d1---c000-0046} 103 0 (nil) (nil))
fixme:shdocvw:ClOleCommandTarget_Exec
(0x1ac7a0)-({de4ba900-59ca-11cf-9592-44455354} 2315 0 (nil) (nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)-((null) 35 0 (nil) (nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)-((null) 28 2 0x33daf4 (nil))
fixme:shdocvw:ClientSite_GetContainer (0x1ac7a0)-(0x33e720)
fixme:shdocvw:InPlaceFrame_SetStatusText (0x1ac7a0)-((null))
fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)-((null) 25 2 0x33e654 (nil))
fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)-((null) 26 2 0x33e654 (nil))
fixme:wininet:InternetLockRequestFile STUB
fixme:shdocvw:ClOleCommandTarget_Exec (0x1ac7a0)-((null) 21 2 (nil) (nil))
Is there a chance to find, what's fatal for the logon process, eventually to
make a quick-and-dirty fix? I actually don't need to call with the programs,
I have asterisk for calling, but I need to be able to setup my account, which
is possible ONLY from these clients (no chance to do it from their web).
Because the AppDB entry for Nonoh is now unmaintained, I'm eventually ready
to become a maintainer. Are there any special requirements needed to do such
a job ?
With regards, Pavel Troller
[PATCH] Compile fix on Linux 2.6.28 / x86
Hi! Due to changes in Linux kernel include file structure, the following patch is necessary to compile wine with the 2.6.28 kernel: --- wine/dlls/ntdll/serial.c.old2009-01-03 19:31:17.0 +0100 +++ wine/dlls/ntdll/serial.c2009-01-03 20:31:11.0 +0100 @@ -74,6 +74,10 @@ #include wine/debug.h #ifdef HAVE_LINUX_SERIAL_H +#include linux/version.h +#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,28) +#include asm/types.h +#endif #include linux/serial.h #endif With regards, Pavel Troller
Re: [PATCH] Compile fix on Linux 2.6.28 / x86
On Sat, Jan 03, 2009 at 08:36:07PM +0100, Pavel Troller wrote: Hi! Due to changes in Linux kernel include file structure, the following patch is necessary to compile wine with the 2.6.28 kernel: --- wine/dlls/ntdll/serial.c.old2009-01-03 19:31:17.0 +0100 +++ wine/dlls/ntdll/serial.c2009-01-03 20:31:11.0 +0100 @@ -74,6 +74,10 @@ #include wine/debug.h #ifdef HAVE_LINUX_SERIAL_H +#include linux/version.h +#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,28) +#include asm/types.h +#endif #include linux/serial.h #endif Better use #ifdef HAVE_ASM_TYPES_H here, its already been tested for. Ciao, Marcus OK, redone and resent to wine-patches. With regards, Pavel Troller
Re: wine-1.2 release criteria?
? ? ?? 15 ??? 2008 Pavel Troller ???(a): ... All these things have a common denominator: proprietary USB drivers. It's fine that wine can use USB scanners/cameras/printers etc, which can be interfaced though native Linux drivers/libraries, but these are almost always usable directly from Linux, while those proprietary devices aren't. Is there any chance that wine will progress in this area ? I'm ready to supply a bounty for a volunteer making some progress here. We (Etersoft) are realized USB support in wine via libusb and do many fixes in ntoskrnl.exe to load and run proprietary drivers for protection keys (like HASP). AS I know, this improvements is not acceptable by Alexandre. If anyone is interested to consult us to do our code more acceptable, you are welcome. Hi! It sounds really very interesting! Is your work accessible as a patch to the current wine tree, or as a git branch somewhere ? I would like to test it with some of my apps (Nokia software, programmers etc...) and give you a feedback, whether it works. Do you know, why Alexandre is not accepting your improvements ? With regards, Pavel Troller
Re: wine-1.2 release criteria?
* USB Support (iPod, etc.) No motion here, I think. I see a big potential here. What makes me crazy, is to beg my colleagues running windoze to - flash my Nokia phone with a new firmware - Program an EPROM in a progammer - Use an SDR (Software Defined Radio) - a box with just a radio hardware without any classic controls, controlled entirely from a PC - etc. etc... All these things have a common denominator: proprietary USB drivers. It's fine that wine can use USB scanners/cameras/printers etc, which can be interfaced though native Linux drivers/libraries, but these are almost always usable directly from Linux, while those proprietary devices aren't. Is there any chance that wine will progress in this area ? I'm ready to supply a bounty for a volunteer making some progress here. With regards, Pavel Troller
Re: -O0 nearly twice as fast to build as -O2
Pavel Troller wrote: OK, this was confusing. I was getting repeatable five minute builds, i.e. make clean; reboot; time make -j3 (more or less :-) was reliably showing five minutes wall clock time. Then I did make distclean; ./configure; make depend. After that, I got repeatable nine minute builds, i.e. make clean; reboot; time make -j3 was showing nine minute wall clock time. Turns out, the difference was... I had been building without optimization. So configuring with CFLAGS=-g -O0 is almost a 2x speedup! Hi! Yes, you are right, turning optimization off speeds up the compilation substantially. HOWEVER, it changes the generated code and due to various features of the compiler (like inlining or another) being present/absent, the code can, in rare cases, behave differently. I have many experiences that for example a program was repeatedly crashing, when compiled by default way, i.e. with optimalization, and when I compiled it without optimalization and with -g for debugging, it never crashed and worked perfectly under the debugger. I had to debug the optimized version, which is harder, because the generated code doesn't track the source exactly anymore. With regards, Pavel Troller Is that a GCC bug then? And, more importantly, was that with a recent GCC version? Hi! It cannot be clearly said. Some nuances of the C language are implementation dependent and it's perfectly OK to compile them differently with or without optimization. Sometimes the programmer incorrectly relies on such a nuance and then using the different set of options can cause his program to behave incorrectly. However, yes, there were, and maybe still are, GCC bugs regarding optimisation, but in recent versions they are very rare. And my experiences mentioned above don't count only for wine, there are many other programs, which do this. With regards, Pavel Troller
Re: -O0 nearly twice as fast to build as -O2
OK, this was confusing. I was getting repeatable five minute builds, i.e. make clean; reboot; time make -j3 (more or less :-) was reliably showing five minutes wall clock time. Then I did make distclean; ./configure; make depend. After that, I got repeatable nine minute builds, i.e. make clean; reboot; time make -j3 was showing nine minute wall clock time. Turns out, the difference was... I had been building without optimization. So configuring with CFLAGS=-g -O0 is almost a 2x speedup! Hi! Yes, you are right, turning optimization off speeds up the compilation substantially. HOWEVER, it changes the generated code and due to various features of the compiler (like inlining or another) being present/absent, the code can, in rare cases, behave differently. I have many experiences that for example a program was repeatedly crashing, when compiled by default way, i.e. with optimalization, and when I compiled it without optimalization and with -g for debugging, it never crashed and worked perfectly under the debugger. I had to debug the optimized version, which is harder, because the generated code doesn't track the source exactly anymore. With regards, Pavel Troller
Regression in winebrowser found and identified
Hi! Today we've found that winebrowser gets invalid URL consisting of many question marks instead of correct URL, in at least two cases: 1) Attempt to buy a game in Steam (yes, we are regularly doing that) 2) Trying to buy a program called CPT-Master from 3am systems, free demo which shows the problem when Buy now button is pressed in its welcome screen, can be downloaded at http://www.3amsystems.com/products/CPT-Master.exe The following commit has been identified as making the regression: e547cf7043e36fecfe5e23d1d6f93a9c5ba89c46 is first bad commit commit e547cf7043e36fecfe5e23d1d6f93a9c5ba89c46 Author: Hans Leidekker [EMAIL PROTECTED] Date: Sun Apr 6 14:44:31 2008 +0200 winebrowser: Convert to Unicode. :04 04 4f3a034b18392677fc0dfd1ed6df7fefe843a10e 0ab8603a13e836a0b91dd2f146df8da59f7e79e4 M programs It really looks related to the problem which I'm reporting :-). BTW, my system is NOT running in Unicode. Maybe is it related ? I hope it is not yet mandatory. I'm using iso-8859-2 encoding, which works much better in my normal working environment. Please do your best to fix it before 1.0, I feel it really bad and I think that many programs may be affected by it. Should I submit a bug too ? With regards, Pavel Troller
Re: Regression in winebrowser found and identified
On Saturday 07 June 2008 10:25:39 Pavel Troller wrote: BTW, my system is NOT running in Unicode. Maybe is it related ? I hope it is not yet mandatory. I'm using iso-8859-2 encoding, which works much better in my normal working environment. If the URL contains characters outside iso-8859-2 that may be the problem, yes. Is it fixed when you switch to utf8? Hi! 1) The URLs don't contain any special characters. They even don't need 8859-2, US-ASCII should be enough for them :-). 2) Switching to utf-8 caused that chinese characters and placeholders (boxes with hex value of the character) were displayed instead of question marks, and it didn't work either, of course. Please file a bug and attach a +winebrowser trace. Done. There are two traces, one with default setting and the other with LC_ALL=cs_CZ.UTF-8. -Hans With regards, Pavel Troller
Re: Serial port support in wine-1.0: What to do to make it working ?
Pavel wrote: I have to use wine-0.9.40 to communicate with a device in my work (simple text-based command-reply communication), any wine newer than say 0.9.50 doesn't work, the communication times out. ... I will try to dig into the driver and search for the bugs there. One of the cases is I think simple, the device uses normal ASCII protocol and I can talk to it using kermit or minicom, but the windows program intended to control it simply stucks on the first command and never gets a reply. I think there is a good place to start. Yep. FWIW, the fix might be tiny. Alexandre fixed a serial bug today, http://bugs.winehq.org/show_bug.cgi?id=9356 with just a single assignment. If you can come up with a simple way for others to reproduce the problem, that might help, too. Hi! I have a very good news today! I tested the current wine git and I've found that it works again in the case of a device mentioned above! It's really good, because it didn't work in 0.9.61 and using 0.9.40 was not good because of another problems in this version. Even better, I've also found that today's wine fixes the last graphics glitches remaining in the program GUI, so now it works PERFECTLY under wine, and it seems that reading/writing the device over the serial port is even FASTER than from windows! I will try another devices soon, to help to debug serial port problems as much as possible! With regards, Pavel Troller
Re: Serial port support in wine-1.0: What to do to make it working ?
On Wed, May 14, 2008 at 6:26 AM, Pavel Troller [EMAIL PROTECTED] wrote: Hi! I have a very good news today! I tested the current wine git and I've found that it works again in the case of a device mentioned above! It's really good, because it didn't work in 0.9.61 and using 0.9.40 was not good because of another problems in this version. Even better, I've also found that today's wine fixes the last graphics glitches remaining in the program GUI, so now it works PERFECTLY under wine, and it seems that reading/writing the device over the serial port is even FASTER than from windows! I will try another devices soon, to help to debug serial port problems as much as possible! With regards, Pavel Troller Wonderful! Can you add this information to the AppDB? To which app ? My one is a very special program, working just with a special telecom device. It's not available publicly anywhere. It doesn't have any entry in AppDB, it would be useless. I will add remarks to other apps, which I will verify later (i.e. MapSource souftware for Garmin GPS etc.). With regards, Pavel Troller
Re: Serial port support in wine-1.0: What to do to make it working ?
Hi Uwe, Pavel, perhaps compile wine yourself and instrument the serial code with debugging output. Try to see what's going wrong. Look at the codes where this happens and read the old changelogs, where somebody fiddled witrh the code. Ask about what people thought (or smoked) when implementing or offer a better implementation. OK, will do. I'm always compiling wine from source, so I will try to dig into the driver and search for the bugs there. One of the cases is I think simple, the device uses normal ASCII protocol and I can talk to it using kermit or minicom, but the windows program intended to control it simply stucks on the first command and never gets a reply. I think there is a good place to start. There is a big problem with those special devices, as only few if any wine developpers have it... Yes, I know. I hope that there is just a limited number of bugs, but they affect many such devices, so it looks that the driver is totally broken. With regards, Pavel Troller
Serial port support in wine-1.0: What to do to make it working ?
Hi! I have really BIG problems running any application, which needs to comm over a serial port: - My ham TCVR - My GPS - My multimeter - A lot of my mobiles - A lot of devices used in my work (special telco equipment, comms varying from simple AT-style commands up to complex proprietary binary protocols). In all the cases there are very similar problems - either the program doesn't detect the device properly, or the device doesn't respond, or in some cases the device does, what the program wants, but it then can't read it back. It looks that some archaic wine versions are better, for example I have to use wine-0.9.40 to communicate with a device in my work (simple text-based command-reply communication), any wine newer than say 0.9.50 doesn't work, the communication times out. Because I'm a telco engineer and serial comm is my daily work, and there are only windows versions of many tools I have to use, proper and mature serial port support is essential for me. So, what can I do to help fixing these problems ? Should I open a bug for every such a program ? Or just open one bug and state all the programs there ? I think that bugzilla contains a lot of bugs related to serial port; is it good to add a new ones ? I'm afraid I can't bisect a problem between 0.9.40 and current wine, but I can make a serial trace for both of them and look at the difference. Would it help to find at least this one particular problem ? Or what more can I do to make the serial port working ? I can code in C in the Linux environment, but I know NOTHING about windows... With regards, Pavel Troller
Problem with VoIP applications
Hi!
I was trying to run FreeCall VoIP client, however, it detects a problem
and tries to contact its authors. I've done a bit of googling and I've found
that there are at least 3 similar programs (FreeCall, VoipCheap, VoipDiscount)
which behave exactly the same way, they are using probably the same client.
Also AppDb lists at least one of them, with identical symptoms.
There is the following report generated by wine:
[EMAIL PROTECTED]:~/.wine/drive_c/Program Files/FreeCall.com/FreeCall$ wine
FreeCall.exe
preloader: Warning: failed to reserve range -0001
preloader: Warning: failed to reserve range -0001
preloader: Warning: failed to reserve range -0001
preloader: Warning: failed to reserve range -0001
err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element
err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element
preloader: Warning: failed to reserve range -0001
err:ole:CoInitializeEx Attempt to change threading model of this apartment from
apartment threaded to multi-threaded
err:ole:CoGetClassObject class {bcde0395-e52f-467c-8e3d-c4579291692e} not
registered
err:ole:CoGetClassObject class {bcde0395-e52f-467c-8e3d-c4579291692e} not
registered
err:ole:create_server class {bcde0395-e52f-467c-8e3d-c4579291692e} not
registered
fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported
err:ole:CoGetClassObject no class object {bcde0395-e52f-467c-8e3d-c4579291692e}
could be created for context 0x17
err:ole:CoInitializeEx Attempt to change threading model of this apartment from
apartment threaded to multi-threaded
err:ole:CoGetClassObject class {bcde0395-e52f-467c-8e3d-c4579291692e} not
registered
err:ole:CoGetClassObject class {bcde0395-e52f-467c-8e3d-c4579291692e} not
registered
err:ole:create_server class {bcde0395-e52f-467c-8e3d-c4579291692e} not
registered
fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported
err:ole:CoGetClassObject no class object {bcde0395-e52f-467c-8e3d-c4579291692e}
could be created for context 0x17
The preloader warnings are harmless in this case. I think the ole errors
are the real cause.
I don't need to use the program for calling, just to make a registration to
FreeCall - they offer also the web-based registration, but then they don't
allow to pay with PayPal - for better security :-(.
Any chance the program could be started at least to allow the registration ?
With regards, Pavel Troller
Unimplemented ntoskrnl functions ?
Hi! I'm solving the following problem: I would like to run the Tibbo Device Server Toolkit (TDSK) - see http://www.tibbo.com/get_dst.php During installation of the product on a fresh wine (the last Sunday's git) with a fresh .wine directory, it crashes with the following report: wine: Call from 0x7b841720 to unimplemented function ntoskrnl.exe.KeInitializeEvent, aborting wine: Unimplemented function ntoskrnl.exe.KeInitializeEvent called at address 0x7b841720 (thread 0021), starting debugger... Unhandled exception: unimplemented function ntoskrnl.exe.KeInitializeEvent called in 32-bit code (0x7b841796). Is this function hard to implement ? I'm somewhat experienced with Linux programming, but I know absolutely nothing about windoze. After a lot of time, if wineserver -k isn't applied, it reports another two unimplemented functions - KeInitializeInterrupt and KeInitializeMutant. What about these ? With regards, Pavel Troller
Re: Unimplemented ntoskrnl functions ?
On Tue, 15 Apr 2008, Pavel Troller wrote: Hi! I'm solving the following problem: I would like to run the Tibbo Device Server Toolkit (TDSK) - see http://www.tibbo.com/get_dst.php During installation of the product on a fresh wine (the last Sunday's git) with a fresh .wine directory, it crashes with the following report: wine: Call from 0x7b841720 to unimplemented function ntoskrnl.exe.KeInitializeEvent, aborting wine: Unimplemented function ntoskrnl.exe.KeInitializeEvent called at address 0x7b841720 (thread 0021), starting debugger... Unhandled exception: unimplemented function ntoskrnl.exe.KeInitializeEvent called in 32-bit code (0x7b841796). Is this function hard to implement ? I'm somewhat experienced with Linux programming, but I know absolutely nothing about windoze. After a lot of time, if wineserver -k isn't applied, it reports another two unimplemented functions - KeInitializeInterrupt and KeInitializeMutant. What about these ? With regards, Pavel Troller Hi, Pavel! You are trying to run the Windows device driver (a virtual port redirector) included with the application. Oh, I see. I actually don't want to use the device driver (Virtual Serial Port - VSP), there is a native Linux driver for it. What I need, is to manage the Tibbo devices, and this functionality is not available for Linux and probably will never be. Wine does not really support Windows drivers - although some may load the functionality just isn't there. The application may run on a COM port supported by the operating system (Linux, etc.) The problem probably is, that the Device Server utilizes the underlying devices for its operation, so it cannot be used without them. It uses some out of band channels to communicate with Tibbos - for example, even if the IP address of the device is lost/spontaneously changed, it can find it using special broadcasts, show its current config, and change it (without losing this service connection). I was hoping that maybe it will work independently of the device driver, but it probably won't. The installation failure is what you should aim to fix. A winedevice crash should not stop the installation. Regards, Paul Chitescu Thank you for your valuable help! It looks that these devices are not for me :-(. With regards, Pavel Troller
Can't determine disk space, install fails
Hi! We have a long-persisting problem there. It persists for many wine versions and prevents some programs from installing. As an example, today my son complained about impossibility to install WoW. The installer was not able to determine the free space on the disk (there was a dash instead of a number in the box) and the Continue button was greyed out, so it was not possible to proceed. There are other cases, in which the installers say that there is not enough space on the disk and fail. Of course there is enough space, but the installer is not able to find it. Especially WoW has Gold rating and these problems are not mentioned, so I don't think that this is a common wine problem, thus I'm not going to open a bug for it. I'm begging for a hint instead, what to try to find the cause of the problem. Wine is always manually compiled and it runs on a generic Linux system, not on any particular, publicly known distro. With regards, Pavel Troller
Re: Can't determine disk space, install fails
Ahoj Vito / Hi Vit, many thanks for your valuable help! In our case, it depends on the partition size, not on the free space remaining. We've found that on every partition bigger than 64G, the installation fails. Now we are performing an experimental installation in /var/tmp, where /var has only 15G in our case, and it works like a charm. What debugging options could we set to collect symptoms of the problem ? With regards, Pavel Troller Hi Pavel, I've ran into similar issues when, for example, I've got more than 64GB free space on the partition, and the old Win installers just told me there was -1 bytes free. I'd vote for some Wine (or 3rd party tool) functionality that would decrease the reported bytes available per user's request. As a temporary solution for such problems, I've used a small partition for installation with just 2GBs free and it worked for me. I've then moved the wineprefix into the target partition. Regards Vit Hrachovy Pavel Troller wrote: Hi! We have a long-persisting problem there. It persists for many wine versions and prevents some programs from installing. As an example, today my son complained about impossibility to install WoW. The installer was not able to determine the free space on the disk (there was a dash instead of a number in the box) and the Continue button was greyed out, so it was not possible to proceed. There are other cases, in which the installers say that there is not enough space on the disk and fail. Of course there is enough space, but the installer is not able to find it. Especially WoW has Gold rating and these problems are not mentioned, so I don't think that this is a common wine problem, thus I'm not going to open a bug for it. I'm begging for a hint instead, what to try to find the cause of the problem. Wine is always manually compiled and it runs on a generic Linux system, not on any particular, publicly known distro. With regards, Pavel Troller
Re: WineHQ should discourage the use of cracks
On Tue, Mar 04, 2008 at 03:35:11PM +0100, Kai Blin wrote: No argument on the US part. I'm still convinced that by EU laws, you're allowed to crack an app you bought in order to make it run on your software. As this hasn't been tested in court yet, though, I'll concede. IANAL, but since 2008 germany adopted a law from a EU proposal (maybe other countries added it before), that disallows circumventing copy protections at all. so in theory your statement is not true any longer for the EU. Hi! Here, in Czech Republic, there is also a new law forbidding to circumvent the copy protection, it probably comes from the same european source as the German one. However, using cracks to make the app running on wine can't be primarily classified as circumventing copy protection, but as modifying an app to run on other OS, which is, I hope, still legal. I think that if I own a legal copy of an application, didn't make any illegal copies of it, and just modified it to run in wine, any court on the world should decide, that my intention was not to circumvent the copy protection (because it is not of any importance to me, I already legally have it), but to make it working (yes, I've spent my money to use the app and I had to modify it to be able to use it). Our courts have to evidence my invention to make a punishable act (like to circumvent the copy protection to either get a pirated copy or to sell my pirated copies to anybody else), but if I did something similar, but for evidently another purpose (to run the legally owned app), I think that it's not a punishable act. Something similar happened recently - a court set free an old woman which was growing marihuana strictly for medical purpose, even if there is a law strictly prohibiting to grow marihuana at all. Of course IANAL, but my kids are running cracked games on wine, however we HAVE all the CDs including bills from the shop for everybody, who would like to accuse us of using illegal software. With regards, Pavel Troller
Re: wine proccess list
Am Dienstag, 11. Dezember 2007 18:02:53 schrieb Gonzalo Martinez - Sanjuan Sanchez: Hello to all. I have something in mind that I would like to ask to Wine developers. Is it possible using a hack/trick or a hidden option to change the name of wine in the proccess lists? I mean, Is it possible to list 'wine' proccess as, for example 'iexplorer' when I use Internet Explorer under Wine? Thanks a lot for your work, hope my question find the answer here. This is done since quite some time. apps are usually called iexplore.exe, or they have the name of the file that was passed to wine, like C:\Program Files\Internet Explorer\iexplore.exe If you still see wine, wineloader or something similar you have a very outdated version of wine. Hi! BTW I don't like this feature and I would prefer at least a commandline switch, or maybe a registry key, to prevent it. Why ? Because wine (and windows apps) sometimes crash and remain running, doing nothing useful but eating CPU/memory, and not being able to be killed easily (even killing the window doesn't close the app reliably). For this case, it's most easy to execute killall -KILL some static name like wine/wine-pthread instead of doing ps axufw, searching for the name of the app and then killing it. I had a single-liner script called kw (kill wine) and doing exactly the above command, and a beutifull bomb icon calling it. Now I can't se it - even killing wineserver sometimes doesn't help. With regards, Pavel Troller
Re: Error while compiling the wine-0.9.49 in RedHat Linux
James McKenzie wrote: Please also be aware that Wine will NOT build properly with any version of gcc 4.0 Can you elaborate? I have been building wine with gcc-4.* since forever and never had any problems with that. Currently I'm using gcc 4.2.2 (Gentoo 4.2.2 p1.0). tom Hi! Me too. Maybe James references just 4.0.x, not 4.1/4.2... With regards, Pavel Troller
Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW
mhhh - since it cost me more then one hour to find out why my machine reboots and triggering a reboot by just _reading_ a file on my system, device node or not is at least very weird behaviour from a user`s perspective. waiting for an user-space daemon to start handling of /dev/watchdog file (opening it and manipulating it from time to time to show that it's still alive. When you cat the file, kernel recognizes it as that such an app is taking over control of the watchdog and starts it. it`s looks a little bit too simple for me. triggering a reboot just by some simple open() and read() and close() ? let`s wait what the maintainer has to tell. regards roland OK, Roland, but it's Linux :-). Isn't rm -rf / a simple command ? Yes, it is :-). Less keystrokes than cat /dev/watchdog. And its impact is even more catastrophic :-). It's the reason why working as root is so much discouraged. With regards, Pavel Troller
wininet: InternetAttemptConnect() Stub
Hi! I have a problem running an offline client for ordering photo prints from digital cameras. Even it is an offline client, it requires the computer to be online. It seems that in wine, it feels to be offline, thus refusing further operation with a dialog saying something like Internet connection unavailable and terminating. The machine is normally connected to the LAN with full net availability. The following is its full console log. [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/droxi/OfflineClient$ wine PhotoOfflineClient.exe fixme:wininet:InternetGetConnectedState always returning LAN connection. fixme:win:SetLayeredWindowAttributes (0x10030,0x,255,2): stub! fixme:win:LockWindowUpdate (0x10028), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! fixme:shdocvw:OleObject_Close (0x199510)-(1) fixme:wininet:InternetAttemptConnect Stub I see two network related fixmes - the first one is very frequent but it seems harmless, many programs are able to use the net even they issue such a message. However, the second fixme looks more interesting, it looks like that the program tries to activate the internet connection, which is of course just a stub. Why is it doing so, I don't know. Is this information enough to find a problem (and maybe its fix) or is more debugging needed ? What else to try ?
Re: wininet: InternetAttemptConnect() Stub
Hi Pavel, On Nov 19, 2007 6:30 AM, Pavel Troller [EMAIL PROTECTED] wrote: I have a problem running an offline client for ordering photo prints from digital cameras. Even it is an offline client, it requires the computer to be online. It seems that in wine, it feels to be offline, thus refusing further operation with a dialog saying something like Internet connection unavailable and terminating. The machine is normally connected to the LAN with full net availability. The following is its full console log. [EMAIL PROTECTED]:~/.wine/drive_c/Program Files/droxi/OfflineClient$ wine PhotoOfflineClient.exe fixme:wininet:InternetGetConnectedState always returning LAN connection. fixme:win:SetLayeredWindowAttributes (0x10030,0x,255,2): stub! fixme:win:LockWindowUpdate (0x10028), partial stub! fixme:win:LockWindowUpdate ((nil)), partial stub! fixme:shdocvw:OleObject_Close (0x199510)-(1) fixme:wininet:InternetAttemptConnect Stub I don't think either wininet fixme is telling you anything worthwhile. As you already pointed out, the first one seems okay: a LAN connection is what it most likely expects anyway. The second stub, if you look at the source, returns ERROR_SUCCESS, which is what MSDN says it should return if it succeeds. I think you're going to have to try a +relay log and scanning through it ti figure out why it thinks it's offline. --Juan Just for your info, you're right, I was not carefull enough to verify what's happening and started writing too soon. The program is communicating happily with a lot of servers, downloads a plenty of files... and then it writes that the connection doesn't work. It seems that either it gets something wrong from one of the servers, or it crashes for another reason and the message is disinformative. I've captured its net activities by Wireshark and we are going to compare them with the log gathered when it runs on windows. With regards, Pavel Troller
Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW
i`ve tracked this down to a watchdog issue. whenever i do cat /dev/watchdog - my system reboots after ~1 minute. i`ve contacted the maintainer of the watchdog subsystem. looks like a bug to me. thanks roland Hi! I think it's not a bug, it's a normal behaviour. The kernel watchdog is normally not active when the machine is booted, waiting for an user-space daemon to start handling of /dev/watchdog file (opening it and manipulating it from time to time to show that it's still alive). When you cat the file, kernel recognizes it as that such an app is taking over control of the watchdog and starts it. However, because cat closes the file immediately, it is not handled anymore and kernel recognizes it as a userspace problem, thus rebooting the machine after the timeout expires. With regards, Pavel Troller
Re: #winehq admin troubles
Hi! Please, people, live in love and peace :-)! I think I see what happened... Parts of the previous mail are swapped, it's better for the explanation. Vitamin said: You omitted the reason: Nov 04 20:30:56 usrl Gunn: that's an old version. Go to winehq.org and follow their instructions to add them to your repos. Nov 04 20:31:05 vitamin fester, how are you loading that program? Nov 04 20:31:09 usrl Gunn: it will be more up to date that way Nov 04 20:31:25 vitamin usrl, that's not a problem here Nov 04 20:31:37 usrl vitamin: I know, but it's helpful anyway. To usrl: This sentence was probably not clever. You are trying to explain things to somebody who knows probably much more than you (and did you REALLY know, that there is not a problem, as you write?). Some people are taking it too personally and they don't like it. Maybe vitamin knew that there are more regressions in those new versions (there are, I compiled wine this week and my son complained loudly, I had to restore .45 or something about it), so he thought that it's better not to recommend an update. You got into middle of conversation, suggested something that user does not need (as 0.9.47 and 0.9.48 are still broken for most Source games). The line above is very important. I think it had to be sent to the channel. Please imagine yourself saying: (09:33:15 PM) vitamin: usrl, this will not help, as 0.9.47 and 0.9.48 are still broken for most Source games. feba thatl wrote: (09:32:56 PM) The topic for #winehq is:[long topic removed] (09:33:09 PM) ***vitamin fucking tired all knowning noobs! (09:33:15 PM) Name removed, same person from #ubuntu: wine: cannot find '/media/cdrom0/intro.exe' (09:33:15 PM) vitamin: usrl, you better leave (09:33:25 PM) usrl: Why? (09:33:32 PM) mode (+b [EMAIL PROTECTED] ) by vitamin Banning instead of a single word of reply ? Please try to see the problem from the usrl's perspective: - He wanted to help somebody - He didn't know what you did know (see below) - You requested him to leave, without any explanation - When he asked why (exactly as I would do in his place), he was forcefully banned. (09:33:32 PM) You have been kicked by vitamin: (vitamin) But since it seems that no one really gives a rip about what's going on on the channel, please whoever has higher access then me, remove me from the ops list. I don't want to explain myself every time some some one feels wronged and have to run to the mailing list to complain about it. No NO no :-). I think you are not bad, at all!!! I can exactly imagine what did you feel - that you were doing your best to explain things to an user and that usrl's entry and suggestions were wrong from your point of view. But please try to imagine that you are a policeman, a lost driver is asking you how to drive to a supermarket, and another person is trying to explain it too, but he's wrong. Would you put the second person (and a few seconds later the first one too) to a jail ? I hope no :-). And with your admin rights it's similar. You have them to protect the channel from all unwanted traffic, keep it going well and smooth. So the only thing you can maybe learn from those cases (if you want) is that you can wait for a second, make a deep breath, and think twice, what are the users REALLY trying to do, before you decide to kick/ban them. Vitaliy. With regards, Pavel Troller
Installer already running
Hi! I was trying to install the Joint Task Force game, which was packaged as a bonus with my new graphics card. The game itself seems to install well using the standard InstallShield, but then it tries to install a PhysX driver/library, which is necessary to run it. The PhysX package is provided as a single executable on the CD. When the executable (called PhysX_2.5.1_SystemSoftware.exe) is run by wine, it immediately pops a dialog saying The installer is already running and pressing its OK button terminates the installation. The game then complains that the PhysX driver is not installed and requires reinstallation (for anybody who would like to try this too, the game itself has to be patched by nocd crack first, otherwise it chokes on SECDRV.SYS). The dialog appears not only when the PhysX installer is launched from the game installer, but also when the executable is run directly from the command line. Intuitively I was trying to discover more about it by running wine with WINEDEBUG=+file, and it has shown that the installer created some files in c:\windows\temp first, then it played with explorer.exe (tried to run it ?), there was a search for a lot of fonts, libs etc., win.ini was consulted several times, and the dialog then appeared. Possibly all the stuff starting with explorer.exe was there to display the dialog box ? After accepting the box, it just deleted the stuff in the temp directory and terminated. I didn't find anything related to this in bugzilla. I would like to find the real cause of the problem, but I don't know exactly, how to proceed. Any hints ? It's the current git wine, but the same is observed on 0.9.33 or so. With regards, Pavel Troller
Re: Installer already running
Dear Vitaliy, I'm very sorry for my total stupidity, ignorance and maybe even debility, but I can't find nothing common between Bug# 219 and my question. The PhysX installer doesn't check for any *ICE components present in the system, doesn't output any strings to wine console, which are described in the bug desc, and the message The installer is already running, which is typical for my problem, is not mentioned in the bug description at all. So please be patient with me and explain me in the deeper detail, why are you thinking that I'm asking for #219. With regards, Pavel Troller I'm not so sure why are you reporting a long long long known problem with Safedisk here, on the mailing list? See the bug 219 and add your comments there. Pavel Troller wrote: Hi! I was trying to install the Joint Task Force game, which was packaged as a bonus with my new graphics card. The game itself seems to install well using the standard InstallShield, but then it tries to install a PhysX driver/library, which is necessary to run it. The PhysX package is provided as a single executable on the CD. When the executable (called PhysX_2.5.1_SystemSoftware.exe) is run by wine, it immediately pops a dialog saying The installer is already running and pressing its OK button terminates the installation. The game then complains that the PhysX driver is not installed and requires reinstallation (for anybody who would like to try this too, the game itself has to be patched by nocd crack first, otherwise it chokes on SECDRV.SYS). The dialog appears not only when the PhysX installer is launched from the game installer, but also when the executable is run directly from the command line. Intuitively I was trying to discover more about it by running wine with WINEDEBUG=+file, and it has shown that the installer created some files in c:\windows\temp first, then it played with explorer.exe (tried to run it ?), there was a search for a lot of fonts, libs etc., win.ini was consulted several times, and the dialog then appeared. Possibly all the stuff starting with explorer.exe was there to display the dialog box ? After accepting the box, it just deleted the stuff in the temp directory and terminated. I didn't find anything related to this in bugzilla. I would like to find the real cause of the problem, but I don't know exactly, how to proceed. Any hints ? It's the current git wine, but the same is observed on 0.9.33 or so. With regards, Pavel Troller
Re: Installer already running
Hi Tom! On 5/7/07, Pavel Troller [EMAIL PROTECTED] wrote: Dear Vitaliy, I'm very sorry for my total stupidity, ignorance and maybe even debility, but I can't find nothing common between Bug# 219 and my question. The PhysX installer doesn't check for any *ICE components present in the system, doesn't output any strings to wine console, which are described in the bug desc, and the message The installer is already running, which is typical for my problem, is not mentioned in the bug description at all. So please be patient with me and explain me in the deeper detail, why are you thinking that I'm asking for #219. With regards, Pavel Troller I agree, this is not an issue with Copy Protection, this is an issue where the installer thinks that the installer is already running. A couple of questions -Have you tried running the PhysX installer manually, after the game is installed? Yes. It's stated in my original mail. The results are identical. -Have you tried running wineboot to make sure any run entries are cleared and then running the PhysX installer manually? No, because the game installer neither didn't warn me that the windows will reboot, nor asked me to do it manually. And I tried to install the PhysX driver on another machine, independently on the previous attempts on the first one, and it also did exactly the same. -Any idea what brand of installer it is (InstallShield, MSI, WISE, or some other)? If you aren't sure, I can always take a look at the installer, if you will bzip and send to me (less than 10mb). The package is provided as a single executable file. It doesn't identify itself, it just pops up the dialog that it's already running. The only trace is the window title, which says AGEIA PhysX V2.5.1 Setup. I think that it's something special, not a classic brands of installers. I will send you the file privately. -- Thanks Tom With regards, Pavel Troller
Re: Installer already running
Pavel Troller wrote: it chokes on SECDRV.SYS). That is all you need to see to know this is SafeDisk. Vitaliy. Hi Vitaliy, sorry but you are wrong. If you want to judge the others, please be so kind and read at least the sentence in which your keyword appears. I'm quoting myself: (for anybody who would like to try this too, the game itself has to be patched by nocd crack first, otherwise it chokes on SECDRV.SYS). This sentence is just a quick note for those, who would eventually like to reproduce my problem as a whole. However, it's not related to the problem I was asking about. I know you are working very hard on wine; I would like to thank you as well as all the others million times and over and over :-). However, please, if you decide to reply to a mail, please don't use grep or any other kind of keyword match instead of reading at least the most important parts :-). With regards, Pavel Troller
Re: Current wine and HL2 family - well done!
Hi We just tried it and we can't reproduce your problem. We were even going in the water itself and the display was smooth and without any distortion. We set the DX9 mode in the game command line (parameter -dxlevel 90). To say even more - with this new version all the random buffers that were displayed are finaly gone, so there's no more strange looking side effects on this map (especially at the bomb spot over at the ramp near the watter). I've also made a test using UseGLSL=enabled, and the water looks perfect, tho the barrels seem overly shiny - same goes for the weapons the player is holding. I think there may be a texture stage missisng, tho everything else seems almost perfect (and with 16xAA looks amazingly well, with not much of a speed impact at 800x600). Hi! I've made also the glsl test. The same problem is here - there is too much shine all over the game. Not only barrels and weapons, but also faces, dresses, walls.. It looks like covered by the oil film. There are also some strange shadow effects - like that the top of the hand is dark and the bottom is bright, like if the light would come from the ground. And all this is of course much slower, doing about 8 - 10 fps on 1024x768. But yes, the water is really perfect. So we turned glsl off again, it seems that it really still needs some work. With regards, Pavel Troller
Current wine and HL2 family - well done!
Hi! Normally I'm writing complaints here, so for a bit of compensation, I would like to inform that yesterday's wine runs HL2 family of games for the first time without an annoying graphics glitch causing parts of skies to be replaced with some bogus contents like white, black, mirrors of a part of ground etc. So, many thanks to all the DirectX developers especially from my sons, they are very pleased and wish you all the best, especially continuous progress in wine development (a bit egocentric from them, but nice :-)) ). With regards, Pavel Troller
Re: Current wine and HL2 family - well done!
without an annoying graphics glitch causing parts of skies to be replaced with some bogus contents like white, black, mirrors of a part of ground etc. Are you finding no errors at all? In Counter-Strike: Source, when running in anything above DX7 mode, on the map de_aztec, the screen is often completely black - it appears to be when looking at water. Hi! We just tried it and we can't reproduce your problem. We were even going in the water itself and the display was smooth and without any distortion. We set the DX9 mode in the game command line (parameter -dxlevel 90). With regards, Pavel Troller
Re: 0.9.31 not suitable for gaming
On 21/02/07, Pavel Troller [EMAIL PROTECTED] wrote:
The last trace which appeared in the log is 2683, so
IWineD3DDevice_CreateAdditionalSwapChain() didn't return. I'm going bananas
from those names; where the hell this one grows :-) ? grep, as obvious,
shows
its calls only.
IWineD3DDeviceImpl_CreateAdditionalSwapChain() in dlls/wined3d/device.c.
IWineD3DDevice_CreateAdditionalSwapChain is actually a macro defined
in include/wine/wined3d_interface.h.
Thanks,
traced a few calls deeper. Now I'm standing at
static void WINAPI IWineD3DDeviceImpl_SetupFullscreenWindow(IWineD3DDevice
*iface, HWND window) {
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
LONG style, exStyle;
/* Don't do anything if an original style is stored.
* That shouldn't happen
*/
TRACE((%p): Setting up window %p for exclusive mode\n, This, window);
if (This-style || This-exStyle) {
ERR((%p): Want to change the window parameters of HWND %p, but
another style is stored for restoration afterwards\n, This,
window);
}
/* Get the parameters and save them */
style = GetWindowLongW(window, GWL_STYLE);
exStyle = GetWindowLongW(window, GWL_EXSTYLE);
This-style = style;
This-exStyle = exStyle;
/* Filter out window decorations */
style = ~WS_CAPTION;
style = ~WS_THICKFRAME;
exStyle = ~WS_EX_WINDOWEDGE;
exStyle = ~WS_EX_CLIENTEDGE;
/* Make sure the window is managed, otherwise we won't get keyboard input
*/
style |= WS_POPUP | WS_SYSMENU;
TRACE(Old style was %08x,%08x, setting to %08x,%08x\n,
This-style, This-exStyle, style, exStyle);
TRACE(1184\n);
SetWindowLongW(window, GWL_STYLE, style);
SetWindowLongW(window, GWL_EXSTYLE, exStyle);
TRACE(1187\n);
/* Inform the window about the update. */
SetWindowPos(window, HWND_TOP, 0, 0,
This-ddraw_width, This-ddraw_height, SWP_FRAMECHANGED);
TRACE(1191\n);
ShowWindow(window, TRUE);
TRACE(1193\n);
}
The last trace executed is 1187, which looks that SetWindowPos doesn't return.
Should I trace even more deep, or is anybody getting an idea, what can be
wrong
here ?
Where is SetWindowPos located ?
With regards, Pavel Troller
Hi!
Because I had to restore working wine, I did the following:
1) Restored original files
2) Pulled today's version
3) Compiled and verified
... Fallout tactics still didn't start with the obvious symptoms.
So I commented out the SetWindowPos() call in ..._SetupFullscreenWindow (on
lines 12512 of the today's source) and... voilla, the game starts and runs
perfectly. My son has verified it and didn't find any problems.
Then he tried HL2 and it seems also fully functional.
So... The bug is still there, but my workaround fixes it for me and I didn't
find any drawbacks (trying a lot of programs I'm using like IDA and some
special telco programs).
Because I didn't read anything from Stefan for a while, I'll wait a bit more
and then I'll create a bugzilla record for it.
Is it ok ?
With regards, Pavel Troller
Re: 0.9.31 not suitable for gaming
trace:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow Old style was
9000,0008, setting to 9008,0008
trace:ddraw:IDirectDrawImpl_FlipToGDISurface (0x19daf8)
This here seems strange. If you compare that to the good log you'll see that
IWineD3DDeviceImpl_Init3D was left way to early. As there is no ERR about a
possible reason for the abortion I think that somewhere an exception is
thrown, caught by the game which terminates afterwards.
Doesn't seem so. See below.
You can do the following:
- Run the game in winedbg and see if it catches the execption and gives a
backtrace and crash position
There is no such exception, at least winedbg doesn't catch any. Is a special
action (command etc.)
- Add some extra traces(or ERRs) to Init3D and its subfunctions to catch the
last line that is exectuted successfully.
Hmm... I added some traces to device.c. We know that last known trace from
Init3D in the bad case is Creating implicit swapchain.
I added a new trace here:
/* Setup the implicit swapchain */
TRACE(Creating implicit swapchain\n);
if (D3D_OK != D3DCB_CreateAdditionalSwapChain((IUnknown *) This-parent,
pPresentationParameters, (IWineD3DSwapChain **)swapchain) || swapchain ==
NULL) {
WARN(Failed to create implicit swapchain\n);
return WINED3DERR_INVALIDCALL;
}
TRACE(1674\n);
(it's on line 1674) and this one was NOT reached.
I'm a bit confusd because I failed to find the code for
D3DCB_CreateAdditionalSwapChain(), I found only its call in device.c and its
definition in wined3d_interface.h.
So, what to do next ?
With regards, Pavel Troller
Re: 0.9.31 not suitable for gaming
You can do the following: - Run the game in winedbg and see if it catches the execption and gives a backtrace and crash position There is no such exception, at least winedbg doesn't catch any. Is a special action (command etc.) Oops. Unfinished mail sent. I meant: Is a special action (command etc.) necessary to enable exception catching in winedbg ? Pavel
Re: 0.9.31 not suitable for gaming
On 21/02/07, Pavel Troller [EMAIL PROTECTED] wrote:
I'm a bit confusd because I failed to find the code for
D3DCB_CreateAdditionalSwapChain(), I found only its call in device.c and
its
definition in wined3d_interface.h.
That's D3D7CB_CreateAdditionalSwapChain() in dlls/ddraw/ddraw.c
Hi!
OK, thanks, found it now.
I've modified its code by inserting many traces:
{
ICOM_THIS_FROM(IDirectDrawImpl, IDirectDraw7, device);
IParentImpl *object = NULL;
HRESULT res = D3D_OK;
IWineD3DSwapChain *swapchain;
TRACE((%p) call back\n, device);
TRACE( 2672\n);
object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(IParentImpl));
TRACE( 2674\n);
if (NULL == object)
{
FIXME(Allocation of memory failed\n);
*ppSwapChain = NULL;
return DDERR_OUTOFVIDEOMEMORY;
}
TRACE( 2681\n);
ICOM_INIT_INTERFACE(object, IParent, IParent_Vtbl);
TRACE( 2683\n);
object-ref = 1;
res = IWineD3DDevice_CreateAdditionalSwapChain(This-wineD3DDevice,
pPresentationParameters,
swapchain,
(IUnknown*)
ICOM_INTERFACE(object, IParent),
D3D7CB_CreateRenderTarget,
D3D7CB_CreateDepthStencilSurface);
TRACE( 2692\n);
if (res != D3D_OK)
{
FIXME((%p) call to IWineD3DDevice_CreateAdditionalSwapChain failed\n,
This);
HeapFree(GetProcessHeap(), 0 , object);
*ppSwapChain = NULL;
}
else
{
TRACE(2701\n);
*ppSwapChain = swapchain;
object-child = (IUnknown *) swapchain;
}
TRACE( Returning\n);
return res;
}
The last trace which appeared in the log is 2683, so
IWineD3DDevice_CreateAdditionalSwapChain() didn't return. I'm going bananas
from those names; where the hell this one grows :-) ? grep, as obvious, shows
its calls only.
With regards, Pavel Troller
Re: 0.9.31 not suitable for gaming
On 21/02/07, Pavel Troller [EMAIL PROTECTED] wrote:
The last trace which appeared in the log is 2683, so
IWineD3DDevice_CreateAdditionalSwapChain() didn't return. I'm going bananas
from those names; where the hell this one grows :-) ? grep, as obvious,
shows
its calls only.
IWineD3DDeviceImpl_CreateAdditionalSwapChain() in dlls/wined3d/device.c.
IWineD3DDevice_CreateAdditionalSwapChain is actually a macro defined
in include/wine/wined3d_interface.h.
Thanks,
traced a few calls deeper. Now I'm standing at
static void WINAPI IWineD3DDeviceImpl_SetupFullscreenWindow(IWineD3DDevice
*iface, HWND window) {
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
LONG style, exStyle;
/* Don't do anything if an original style is stored.
* That shouldn't happen
*/
TRACE((%p): Setting up window %p for exclusive mode\n, This, window);
if (This-style || This-exStyle) {
ERR((%p): Want to change the window parameters of HWND %p, but
another style is stored for restoration afterwards\n, This,
window);
}
/* Get the parameters and save them */
style = GetWindowLongW(window, GWL_STYLE);
exStyle = GetWindowLongW(window, GWL_EXSTYLE);
This-style = style;
This-exStyle = exStyle;
/* Filter out window decorations */
style = ~WS_CAPTION;
style = ~WS_THICKFRAME;
exStyle = ~WS_EX_WINDOWEDGE;
exStyle = ~WS_EX_CLIENTEDGE;
/* Make sure the window is managed, otherwise we won't get keyboard input */
style |= WS_POPUP | WS_SYSMENU;
TRACE(Old style was %08x,%08x, setting to %08x,%08x\n,
This-style, This-exStyle, style, exStyle);
TRACE(1184\n);
SetWindowLongW(window, GWL_STYLE, style);
SetWindowLongW(window, GWL_EXSTYLE, exStyle);
TRACE(1187\n);
/* Inform the window about the update. */
SetWindowPos(window, HWND_TOP, 0, 0,
This-ddraw_width, This-ddraw_height, SWP_FRAMECHANGED);
TRACE(1191\n);
ShowWindow(window, TRUE);
TRACE(1193\n);
}
The last trace executed is 1187, which looks that SetWindowPos doesn't return.
Should I trace even more deep, or is anybody getting an idea, what can be wrong
here ?
Where is SetWindowPos located ?
With regards, Pavel Troller
Re: 0.9.31 not suitable for gaming
Hi! Am Dienstag 20 Februar 2007 06:37 schrieb Pavel Troller: - Steam based games, mainly HL2: During game load, the screen goes black. Moving the cursor causes sound effects as it hovers across the menus and buttons, so the program runs, but nothing can be seen. This regression is known, and it should be fixed already. It was caused by my patch which made wined3d return an error if an unsupported query is created, like windows does. Wine does not support event queries, but many apps expect them to be supported. I have sent another patch(committed already) that re-enables the fake event queries. OK. This bug seems to be really fixed, but the game crashes later (during the startup of the real game, after all the selections). It crashes in its own code (called Engine) but ntdll and kernel32 are visible in the backtrace. I can send it exactly if it helps. I don't know how to bisect this crash because the one initially mentioned is masking it. - Fallout Tactics (BOS.exe): Shows a dialog stating C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: Could not create display buffers and then another one about abnormal termination of the program and quits. I don't know about this regression. Can you do a bisect? Yes, done. It's the following commit: commit 388499ff28616ef03bf8949a78e658e1bdb4e4fc Author: Stefan DĂśsinger [EMAIL PROTECTED] Date: Wed Feb 14 17:59:08 2007 +0100 wined3d: More fullscreen window fixes. The game is run in a virtual desktop (i.e. it appears in the Linux window, not in full screen). With regards, Pavel Troller
Re: 0.9.31 not suitable for gaming
I don't know about this regression. Can you do a bisect? Yes, done. It's the following commit: commit 388499ff28616ef03bf8949a78e658e1bdb4e4fc Author: Stefan DĂśsinger [EMAIL PROTECTED] Date: Wed Feb 14 17:59:08 2007 +0100 wined3d: More fullscreen window fixes. The game is run in a virtual desktop (i.e. it appears in the Linux window, not in full screen). That is strange. Can you send be a +ddraw,+d3d8,+d3d9,+d3d trace? OK, did it. Sending two traces: A bad one, and a good one made by wine just before the above commit. With regards, Pavel Troller bos_traces.tar.bz2 Description: application/tar-bz2
0.9.31 not suitable for gaming
Hi! I've tried 0.9.31 and it seems that there is a regression in at least two games: - Fallout Tactics (BOS.exe): Shows a dialog stating C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: Could not create display buffers and then another one about abnormal termination of the program and quits. - Steam based games, mainly HL2: During game load, the screen goes black. Moving the cursor causes sound effects as it hovers across the menus and buttons, so the program runs, but nothing can be seen. Both those games are known to work with wine at about a half between .29 and .30. I tried it with basic .31 as well as with today's git update. Are those regressions known and is it a work in progress, or should I make a bisecting session to find the problem ? With regards, Pavel Troller
Regression in comctl32
Hi! I just found a regression in comctl32 and bisected it successfully. The following commit 369749dcb2ba12ce8481503543afd18ad99805d1 is first bad commit commit 369749dcb2ba12ce8481503543afd18ad99805d1 Author: Dmitry Timoshkov [EMAIL PROTECTED] Date: Mon Feb 12 16:47:56 2007 +0800 comctl32: Make ImageList_Read and ImageList_Write compatible with each other, simplify the code. :04 04 7a8b282d58c6a6111ad0995eb8d47cbfbc8cadb0 afca21972669e3d013eef8de59556675a0bc798b M dlls causes that IDA Pro shows black squares instead of its toolbar icons. With regards, Pavel Troller
Re: Another report of malware running on Wine
Hi! This weekend my son downloaded a trojan masking as keygen for a Symbian mobile application. After running a trojan, a tooltip in the systray appeared saying something like Your computer is infected. After that, I inspected his .wine directory. There were many files added in various directories (system32, windows, even root of c:, they were partly .exe, partly .dll, ane one even .htm :-). I looked it in the web browser and it displayed a page saying that my comp is full of malware, spyware and various other *ware and that the only cure is to download a specialized application from them :-). They tried to make me shocked by displaying something that THEY know that your computer has IP address my real IP ADDRESS, you are using Windows XP (hahaha) and your browser is MSIE 6 (hahahaha). However, this page was not displayed by the trojan, so I think that something has failed in it and it was unable to fire the formerly mentioned MSIE6 :-). Two unknown processes were permanently running by wine. After cleaning all this mess, normal wine operation has been fully restored. With regards, Pavel Troller
Re: Executing wine over make segfaults.
Please open a bug and discuss this problem via bugzilla, rather than on wine-devel. OK. Bug #6622 has been registered. Let's move our efforts to bugzilla. Regards, Pavel
Re: Executing wine over make segfaults.
fixme:seh:check_no_exec No-exec fault triggered at 0x401000, enabling work-around Are you using SeLinux or some other patches? If so, please try building your kernel from the vanilla Linux kernel.org sources. Hi Mike! I take you very seriously, I know that you are a real wine guru, but I know that those messages are not related to the segfaulting problem. 1) These messages appear only on a x86_64 architecture. On i386 the crash is the same but the messages are not there. 2) There are other apps, which work perfectly, although they emit the same messages. 3) I'm using exec-shield patch, but I can disable it (for sure, tested by the pax testing suite) using a procfs entry. Even with exec-shield disabled the crash is still there, and in 2.6.17, even with exec-shield enabled, there is no crash. With regards, Pavel Troller
Re: Executing wine over make segfaults.
this is what i did - and also suggest quite some time ago him(?)/list. i had the same problem since .16 kernels (unstable(~) gentoo-source ebuild). since that change everything works fine (.18 now). Hi! Yes, you did, and you did correctly. I just rebooted the x86_64 machine with noexec=off. The app runs with no problems. Does it mean that something changed in noexec between .17 and .18 ? Why wine worked well with noexec and 2.6.17 ? But it's really wrong: I don't want to compromise my security because of running wine. Is there a chance to fix this in wine, for example by ordering executability for every memory allocation ? With regards, Pavel Troller
Re: Executing wine over make segfaults.
Hi! It is usuyally generated from wine-pthread gdb wine-pthread core.19668 bt It showed the following: [EMAIL PROTECTED]:~$ gdb wine-pthread core.19668 GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. warning: core file may not match specified executable file. warning: Can't read pathname for load map: Input/output error. Reading symbols from /opt/wine/lib/libwine.so.1...done. Loaded symbols for /opt/wine/bin/../lib/libwine.so.1 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 ... and many similar lines for every library involved Reading symbols from /opt/wine/lib/wine/urlmon.dll.so...done. Loaded symbols for /opt/wine/bin/../lib/wine/urlmon.dll.so Core was generated by `/mnt/cd/100_prazskych_zajimavosti.exe '. Program terminated with signal 11, Segmentation fault. #0 0x00876440 in ?? () (gdb) If it still does not show a backtrace, try: No it doesn't, the backtrace is just as dummy as before. x /i $eip info registers to show the current instruction + registers. OK, particular success: (gdb) x /i $eip 0x876440: Cannot access memory at address 0x876440 (gdb) info registers eax0x33f5cc 3405260 ecx0x0 0 edx0x3904a2 3736738 ebx0x33f9ff 3406335 esp0x7ffddc80 0x7ffddc80 ebp0x33f634 0x33f634 esi0x3904a0 3736736 edi0x1 1 eip0x876440 0x876440 eflags 0x210206 [ PF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x33 51 gs 0x3b 59 (gdb) Ciao, Marcus With regards, Pavel Troller
Re: Executing wine over make segfaults.
This seems to be Wine-related problem (but not neccessary Wine bug) because everything else works fine with 2.6.18.1 kernel; I'm not alone who have strange problems with Wine under 2.6.18 kernel. No, you are not. I've posted a very similar problem with wine 2.6.18 a couple of weeks ago. Just to recall, my experiences with the problem: 1) Not every windows app causes wine to segfault. There are fairly complex, networked apps, which work flawlessly (DC++), other ones, much more simple, cause wine to crash, like wine's itself rundll.exe setupapi.dll when it tries to create a fresh .wine directory. Please see my post to wine-devel dated Oct 11, with subject wine segfaulting for details. There is even a strace snippet. 2) It crashes almost identically on both i386 and x86_64 architectures, with the same applications. 3) As demonstrated in 1), it does so even in the .wine directory build process, which means that no DLL overrides or other user-broken things can be involved. 4) No user/system settings can change this. Tried to increase various ulimits, manipulate (disable) exec-shield etc. Just the only solution known to me is to boot 2.6.17 or less, which I cannot normally because of other features I currently need from 2.6.18. 5) I'm testing wine on the system it was built on (with 2.6.18). It should ensure maximum compatibility with its kernel (I'm using live kernel includes for linux/* and asm/*). However, it works when transferred to another system running 2.6.17. I'm ready to perform some debugging; however, currently I don't know where to start. With regards, Pavel Troller
Re: wine segfaulting
Hi! Marcus Meissner wrote: On Wed, Oct 11, 2006 at 11:32:47AM +0200, Markus Amsler wrote: Hi, What kernel version/distro are you using? What about make test. I had similar strange behavior with 2.6.18 (debian/unstable linux-image-2.6.18-1-686): wine segfaults in multiple situations. The strangest was: make test failed/segfaulted in ntdll, but running the test manually with runtest worked !?! The rest of the system was perfect stable. With 2.6.17 everything works fine. I'm running kernels 2.6.16 - 2.6.18. Yes, the failing machine runs 2.6.18. It seems to be a really hot trace! Just now I cannot make test, because I'm not locally on the failing machine. Will try it ASAP. I found some reports on the net having similar problems with 2.6.18. It looks like a memory layout issue. I did cat /proc/self/maps several times. It looks very similar on both 2.6.17 as well as 2.6.18. However, it may be something not visible there. [EMAIL PROTECTED]:~$ cat /proc/self/maps 0017e000-0017f000 r-xp 0017e000 00:00 0 [vdso] 0092b000-00947000 r-xp 08:01 98122 /lib/ld-2.5.so 00947000-00948000 r-xp 0001b000 08:01 98122 /lib/ld-2.5.so 00948000-00949000 rwxp 0001c000 08:01 98122 /lib/ld-2.5.so 00d8b000-00ebd000 r-xp 08:01 98151 /lib/libc-2.5.so 00ebd000-00ebf000 r-xp 00131000 08:01 98151 /lib/libc-2.5.so 00ebf000-00ec rwxp 00133000 08:01 98151 /lib/libc-2.5.so 00ec-00ec3000 rwxp 00ec 00:00 0 08048000-0804c000 r-xp 08:01 32711 /bin/cat 0804c000-0804d000 rw-p 3000 08:01 32711 /bin/cat 0972f000-0975 rw-p 0972f000 00:00 0 b7d03000-b7d0a000 r--p 011c7000 08:01 53695 /usr/share/locale/locale-archive b7d0a000-b7d3e000 r--p 0118e000 08:01 53695 /usr/share/locale/locale-archive b7d3e000-b7f3e000 r--p 08:01 53695 /usr/share/locale/locale-archive b7f3e000-b7f4 rw-p b7f3e000 00:00 0 bfbdf000-bfbf5000 rw-p bfbdf000 00:00 0 [stack] The kernel is patched with exec-shield, but wine works perfectly with it on 2.6.17. Is there a ulimit set? (ulimit -a) But I think we solved this specific problem already. All the machines have identical ulimit. Increasing values on the failing one doesn't help. I also setted /proc/sys/vm/legacy_va_layout to 0|1. But no effect. I did the same, also with no effect. I also tried to disable exec-shield, to be sure, and it also didn't help. Pavel
wine segfaulting
Hi!
I have a problem running wine on one of my machines. It's the same binary
copy which I've compiled and which successfully runs on another ones.
The problem is that many apps, which run on other machines, cause wine to
segfault here. The first one doing so is rundll.exe setupapi.dll...,
invoked during wineprefixcreate process, so there is even a problem creating
a fresh .wine directory.
Simple apps, like winecfg and notepad, run well. Other ones don't. For
some of them, wine dumps a lot of warnings before the segfault, but exactly
the same warnings are emitted on another machines, where the app runs well.
When the app fails, it even doesn't start to render its window. However, when
a virtual desktop is to be used, it appears but it's still empty in the
moment of the fault.
I was trying to get a backtrace by generating a core file and then examining
it with gdb. However, it always complains about the fact that the core was
created by another binary being run, and reports the name of the windows
executable, not anything like wine-*thread, which run the app. An attempt of
dumping the bt ends up with many hundreds of illegal entries, mostly zeroes,
some 0xs and other junk, and the bt is ended by an inaccessible memory
somewhere at 0x7FFE.
Basic software (kernel, glibc, X11...) is very similar on all of the
machines, and of recent dates.
I've also used strace and examined it. It looks that the segfault comes to
2 threads simultaneously. Immediately before there are some mprotect() calls
and mmap2(), which is successfull. The fault appears somewhere at 61k'th line,
so the app did a bunch of things before the crash:
Now I'm lost. Can anybody help me, what to try next to find the cause and
solve the problem ? Many thanks in advance!
With regards, Pavel Troller
[pid 4583] ... gettimeofday resumed {1160539521, 267044}, NULL) = 0
[pid 4583] read(21, \221\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
\0\1\0\0\0\0\0\0\0\0..., 64) = 64
[pid 4583] write(22,
\0\0\0\0\0\0\0\0\0\0\0\226\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64 unfinished ...
[pid 4580] ... read resumed
\0\0\0\0\0\0\0\0\0\0\0\226\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 64) = 64
[pid 4583] ... write resumed ) = 64
[pid 4580] rt_sigprocmask(SIG_SETMASK, [], unfinished ...
[pid 4583] epoll_wait(0x6, 0xbfb1b5dc, 0x80, 0x6c8f unfinished ...
[pid 4580] ... rt_sigprocmask resumed NULL, 8) = 0
[pid 4580] write(6, ;[EMAIL PROTECTED]\0\2\0\205\0@..., 80) = 80
[pid 4580] mmap2(0x39, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x39
[pid 4580] shmget(IPC_PRIVATE, 3152, IPC_CREAT|0700) = 7143430
[pid 4580] shmat(7143430, 0, 0)= 0xb7f45000
[pid 4580] write(6, ;[EMAIL PROTECTED]..., 56) = 56
[pid 4580] read(6,
\1\1\10\3\0\0\0\0\5\0\240\1\0\0\0\0\0\0\0\0\0\0\0\0\10..., 32) = 32
[pid 4580] shmctl(7143430, IPC_64|IPC_RMID, 0) = 0
[pid 4580] mprotect(0x39, 4096, PROT_READ|PROT_WRITE) = 0
[pid 4580] write(6, [EMAIL PROTECTED]@[EMAIL PROTECTED], 24) = 24
[pid 4580] mprotect(0x39, 4096, PROT_READ) = 0
[pid 4580] write(6, ;[EMAIL PROTECTED]..., 64) = 64
[pid 4580] read(6,
\1\1\r\3\0\0\0\0\5\0\240\1\0\0\0\0\0\0\0\0\0\0\0\0\10L..., 32) = 32
[pid 4580] mprotect(0x39, 4096, PROT_NONE) = 0
[pid 4580] write(6, [EMAIL PROTECTED]..., 60) = 60
[pid 4580] write(6, ;[EMAIL PROTECTED]\0\2\0\212\0@..., 44) = 44
[pid 4580] write(6, ;[EMAIL PROTECTED]..., 88) = 88
[pid 4580] write(6, ;[EMAIL PROTECTED]\0\2\0\214\0@..., 52) = 52
[pid 4580] shmdt(0xb7f43000) = 0
[pid 4580] mmap2(0x3a, 4096, PROT_NONE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3a
[pid 4580] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 4580] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 4587] ... read resumed 0x6cd9c6a4, 8) = ? ERESTARTSYS (To be restarted)
[pid 4588] ... read resumed 0x6151d4c4, 8) = ? ERESTARTSYS (To be restarted)
[pid 4583] ... epoll_wait resumed ) = 1
[pid 4587] +++ killed by SIGSEGV +++
PANIC: handle_group_exit: 4587 leader 4580
Process 4588 attached (waiting for parent)
[pid 4580] +++ killed by SIGSEGV +++
[pid 4583] gettimeofday({1160539521, 270820}, NULL) = 0
[pid 4583] epoll_ctl(0x6, 0x2, 0x15, 0xbfb1b53c) = 0
[pid 4583] close(21) = 0
[pid 4583] close(22) = 0
[pid 4583] close(23) = 0
[pid 4583] epoll_wait(0x6, 0xbfb1b5dc, 0x80, 0x6c8b) = 3
[pid 4583] gettimeofday({1160539521, 271022}, NULL) = 0
[pid 4583] write(38, \0\0\0\0\3\1\0\0, 8) = -1 EPIPE (Broken pipe)
[pid 4583] --- SIGPIPE (Broken pipe) @ 0 (0) ---
[pid 4583] epoll_ctl(0x6, 0x2, 0x24, 0xbfb1b53c) = 0
[pid 4583] close(36) = 0
[pid 4583] close(37) = 0
[pid 4583] close(38) = 0
[pid 4583] write(35, \0\0\0\0\3\1\0\0, 8) = -1 EPIPE (Broken pipe)
[pid 4583] --- SIGPIPE (Broken pipe) @ 0 (0) ---
wine and serial port - again
Hi! From time to time, complaints can be heard about functionality of the serial port implementation in wine. Just now I have one of examples of the serial communication problem. There is a very simple program, called ft or softjump, intended to dump or modify some particular addresses of an EEPROM of an amateur radio. It uses a serial port in non-canonical mode, writing always 5 binary chars into it and reading (also binary) reply. I've run this program under wine but there were problems - the program never dumped any data. The source is included in the program archive; it was about 30 minutes of work to convert it for Linux. After successfull compilation, I've run the resulting Linux program (pure Linux, not winelib) and it worked as expected. For the testing purposes, I've then compiled the original windows version using winegcc. I was able to run the program, but the results were identical to those with original windows binary (no data). The windows binary output shows this: [EMAIL PROTECTED]:~/ft817$ wine ft.exe ft.exe by Peter May, VK2JCG, [EMAIL PROTECTED] This program uses undocumented CAT commands to read or update the EEPROM in the Yaesu FT817 and FT897 Radios. The soft jumper settings are stored in location 4 and 5 of the EEPROM. Power the radio off and on to activate the new settings. If you do a reset of the radio, you will have to run this program again to rewrite the values The program assumes that the radio is connected to COM1: and the CAT rate is set to 38400 baud *** USE AT YOUR OWN RISK *** Serial port COM1: successfully reconfigured. Read current data from EEPROM gives : [EMAIL PROTECTED]:~/ft817$ Its Linux version works well: [EMAIL PROTECTED]:~/ft817/Source$ ft ft by Peter May, VK2JCG, [EMAIL PROTECTED] This program uses undocumented CAT commands to read or update the EEPROM in the Yaesu FT817 and FT897 Radios. The soft jumper settings are stored in location 4 and 5 of the EEPROM. Power the radio off and on to activate the new settings. If you do a reset of the radio, you will have to run this program again to rewrite the values. *** USE AT YOUR OWN RISK *** Linux version by Pavel Troller - OK1XPT, [EMAIL PROTECTED] Serial port /dev/tts/0 successfully reconfigured. Read current data from EEPROM gives : DD BF [EMAIL PROTECTED]:~/ft817/Source$ Do you see ? The windows version doesn't output the actual EEPROM data. +file,+comm trace from wine looks like this: trace:file:CreateFileW LCOM1: GENERIC_READ GENERIC_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (LCOM1:,0x7fb3fdd0,(nil),(nil)) trace:file:RtlGetFullPathName_U (LCOM1: 520 0x7fb3fb44 (nil)) trace:file:get_dos_device LCOM1 - /dev/ttyS0 trace:file:CreateFileW returning 0x2c trace:comm:GetCommState handle 0x2c, ptr 0x7fb3fe70 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_BAUD_RATE (nil) 0 0x7fb3fe18 4 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_LINE_CONTROL (nil) 0 0x7fb3fe1d 3 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_HANDFLOW (nil) 0 0x7fb3fe00 16 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_CHARS (nil) 0 0x7fb3fe12 6 0x7fb3fdb0 trace:comm:GetCommState OK trace:comm:dump_dcb bytesize=8 baudrate=38400 fParity=0 Parity=0 stopbits=2 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=0 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1 trace:comm:dump_dcb ~CRTSCTS trace:comm:dump_dcb bytesize=8 baudrate=38400 fParity=0 Parity=0 stopbits=2 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=0 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=0 trace:comm:dump_dcb ~CRTSCTS trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_BAUD_RATE 0x7fb3fe18 4 (nil) 0 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_LINE_CONTROL 0x7fb3fe1d 3 (nil) 0 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_HANDFLOW 0x7fb3fe00 16 (nil) 0 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_CHARS 0x7fb3fe12 6 (nil) 0 0x7fb3fdb0 trace:comm:SetCommTimeouts (0x2c, 0x7fb3fe5c) trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_TIMEOUTS 0x7fb3fe0c 20 (nil) 0 0x7fb3fdb0 trace:file:WriteFile 0x8 0x7fb3f9cc 48 0x7fb3fdd4 (nil) Serial port COM1: successfully reconfigured. trace:file:WriteFile 0x2c 0x7fb3fe54 5 0x7fb3fe4c (nil) trace:file:ReadFile 0x2c 0x7fb3fe8c 4 0x7fb3fe4c (nil) trace:file:WriteFile 0x8 0x7fb3f9b4 38 0x7fb3fdbc (nil) Read current data from EEPROM gives : trace:file:WriteFile 0x8 0x7fb3f9b8 2 0x7fb3fdc0 (nil) You can see the port configuration phase, as well 5 bytes being written and a read being attempted. However, resulting count variable (see source) is probably 0, because there is no output of values read. I don't know, whether it is due to wrong command being written to the radio, or failure to read its response. Original package can be downloaded freely for example here: http://www.817-onair.de/download.php?id
Re: wine problems on a 64bit system
Hi Alexandre, many thanks that you are also looking at this problem. It may be that your kernel doesn't allow writable memory to be made executable, in which case we can't do anything about it. Or maybe the workaround is simply broken... It may also be possible to make that section executable some other way, you'll need to investigate what that memory address corresponds to in the app. Running the app, it shows [EMAIL PROTECTED]:~/il2sturmovikfb$ wine il2fb.exe fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around Looking at /proc/pid/maps, it shows [EMAIL PROTECTED]:/proc/14647# cat maps |grep 6d4d 6d4cf000-6d4d rw-p 6d4cf000 00:00 0 6d4d-6d4d1000 rwxp 6d4d 00:00 0 6d4d1000-6d4e3000 rw-p 6d4d1000 00:00 0 It looks that this page IS writable as well as executable. However, there is nothing more about it, no indication of which part of the app it corresponds to. Just a global data/BSS section ? BTW the problem happens very early during startup, even before an Xserver is accessed, so trying it from the text console (without $DISPLAY defined) gives exactly the same results as from Xterm. But now I'm unsure, maybe we are on a false track. I just examined +relay output again and I've found that immediately after the No-exec message the program seems to continue normally. The problem (exception loop in msvcrt) occurs many thousands lines later. I'm attaching preceding cca 1500 lines of the log. With regards, Pavel Troller il2relay.bz2 Description: Binary data
Re: wine problems on a 64bit system
Pavel Troller [EMAIL PROTECTED] writes: But now I'm unsure, maybe we are on a false track. I just examined +relay output again and I've found that immediately after the No-exec message the program seems to continue normally. The problem (exception loop in msvcrt) occurs many thousands lines later. I'm attaching preceding cca 1500 lines of the log. It sounds like the no-exec workaround worked fine, and that you have some other problem. What does a +seh trace look like? Hi Alexandre! +seh shows the following: trace:seh:raise_exception code=c005 flags=0 addr=0x6d4d08b0 trace:seh:raise_exception info[0]=0008 trace:seh:raise_exception info[1]=6d4d08b0 trace:seh:raise_exception eax=0001 ebx=7fe02cd8 ecx=7fe02cd8 edx=0003 esi=7fe02cd8 edi=6d4e0e90 trace:seh:raise_exception ebp=7fb2fd70 esp=7fb2fd68 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010293 trace:seh:call_stack_handlers calling handler at 0x401f00 code=c005 flags=0 trace:seh:_except_handler3 exception c005 flags=0 at 0x6d4d08b0 handler=0x401f00 0x7fb2fa44 0x7fb2f984 semi-stub trace:seh:_except_handler3 filter = 0x401e62 trace:seh:_XcptFilter (-1073741819,0x7fb2f8c0) trace:seh:_except_handler3 filter returned CONTINUE_SEARCH trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch trace:seh:call_stack_handlers handler at 0x401f00 returned 1 trace:seh:call_stack_handlers calling handler at 0x7b82be80 code=c005 flags=0 fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around trace:seh:call_stack_handlers handler at 0x7b82be80 returned 0 trace:seh:raise_exception code=c005 flags=0 addr=0x6d4db3ef trace:seh:raise_exception info[0]=0008 trace:seh:raise_exception info[1]=6d4db3ef trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c005 flags=0 trace:seh:_except_handler3 exception c005 flags=0 at 0x6d4db3ef handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 trace:seh:raise_exception code=c005 flags=0 addr=0x6d4d5d7b trace:seh:raise_exception info[0]=0008 trace:seh:raise_exception info[1]=6d4d5d7b trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c005 flags=0 trace:seh:_except_handler3 exception c005 flags=0 at 0x6d4d5d7b handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 It looks that the first exception is the No-exec, then there is one more lonely one (at 0x6d4db3ef) and the third one (at 0x6d4d5d7b) is the first invocation of the looping one - this one repeats in the log at the same address forever. With regards, Pavel Troller
Re: wine problems on a 64bit system
) and not for the other ones, where it also should be ? Why this new page has not been worked-around ? With regards, Pavel Troller
Re: wine problems on a 64bit system
Hi Pavel, Hi Steven! I've only slightly followed wine-devel recently Are you using a stock Fedora kernel? No. I'm using vanilla kernels just with exec-shield patch from Ingo Molnar. I'm not using any well-known distro. They are all (x86-64) built with SMP support. My ones are also built with SMP support, because both the 64bit machines have dual-core CPUs. One of them is Pentium-D and the second is Dual Opteron. Would it be possible to check with a custom built non-smp kernel to see if you have the same behavior? OK. These machines build a kernel in 3 minutes, no problem to try to disable SMP and verify. However, the 32bit one is also SMP :-); it's MSI K7D Master board populated with 2 Athlons MP. It works perfectly and it's ideal for gaming, because one CPU handles Xserver and similar and the other runs the game :-). wine has no problems with it. I've been looking in to this matter myself but its been slow going because I lack a 64bit system here. Can you run a strace on a winelib process and send us the results with both the SMP and non-smp kernels? Will do. With regards, Pavel Troller
Re: Compiling wine on an x86-64 system
Hi Rob! There are quite a few places that use i386 syscalls directly and you just fixed the one place it was detected. What you need to do is to copy a 32-bit unistd.h to asm-i386/unistd.h and make sure that it is included correctly by asm/unistd.h. Many thanks for your explanation. So I created my own /usr/include/asm directory and wrote a small script, which populated it with files like this sample: /* Automatically generated wrapper for asm/unistd.h - do not edit */ #ifdef __i386__ # include asm-i386/unistd.h #else # ifdef __x86_64__ #include asm-x86_64/unistd.h # else #error Unknown architecture, neither i386 nor x86_64 # endif #endif asm-i386 and asm-x86_64 contain the appropriate headers from the kernel tree. I hope it's a good solution to have a flexible bi-arch development system. After that, I recompiled wine (and removed my previous unistd.h hack first). The resulting wine is fully functional now. With regards, Pavel Troller
wine problems on a 64bit system
Hi! As some of you know, I'm experimenting with my new 64bit systems. I've found that there are problems running a lot of applications, which normally run on a 32bit system. A typical example is IL2 Sturmovik Forgotten Battles game. On a 32bit system, with the latest wine CVS (even compiled on a 64bit system) it runs flawlessly. On a 64bit system, it just prints fixme:seh:check_no_exec No exec fault triggered at 0x6d4d08b0, enabling work-around but the workaround seems to be unefficient, because nothing more happens. With a +relay, it shows that the program is looping, executing 0009:Call msvcrt._except_handler3(7fb2faa0,7fb2fba0,7fb2f7d4,7fb2f714) ret=7bc54d65 0009:Ret msvcrt._except_handler3() retval= ret=7bc54d65 and nothing more, ad infinitum. The machines are running very similar kernels. Both are hardened with exec-shield, but even disabling it on a 64bit by 'echo 0 /proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with exec-shield enabled (and doesn't print the no-exec message). Are there chances to fix this issue ? Or is it a system problem ? With regards, Pavel Troller
Compiling wine on an x86-64 system
Hi! I would like to ask for a help with wine compilation on an x86_64 system. Today I successfully did the compilation, but the result is totally unusable. I've supplied -m32 switch to both CFLAGS and LDFLAGS (I have to specify my own C/LDFLAGS because of custom -I/-L options to find various packages). gcc as well as winegcc correctly generated 32bit output. There was just one error during compilation - it attempted to compile dlls/ntdll/signal_i386.c, which suffered from __NR_sigaction being undefined. Because my kernel headers are set up for a 64bit system, there is not such a define. __NR_rt_sigaction is defined instead. I'm not sure whether it's ok that wine tried to compile this file (it compiled signal_x86_64.c too, with no problems). I also don't know how to hack the kernel includes to define it correctly (I have just vanilla, unmodified set of native kernel headers for 2.6.17-rc5 set up). So I hacked it by copying the appropriate #define from asm-i386/unistd.h kernel header directly to signal_i386.c. wine then compiled and installed without a glitch. However, any attempt to run it ends up with immediate return without any diagnosis. It even doesn't output its usage help. I've already compiled a lot of normal programs for 32bit systems on my x86_64 system. However, wine resists. What am I doing wrong ? What's the correct way ? With regards, Pavel Trolle
Regression in wine made 2006/03/23
Hi! I would like to report a regression made by commits issued 2006/03/23 at the evening. Just now I don't have bisecting environment available, I've just made a simple CVS regression testing and found the above commit (it modifies multiple areas) guilty. The problem is that DC++ gui is totally screwed up now. It tries to render, but mostly unsuccessfully, it's full of garbage and doesn't display, what it should. It doesn't update when necessary. DC++ is simply unusable now. I should leave my testing machine now. I can try to pinpoint a particular patch responsible for this regression later in the evening today, or tomorrow. If anybody has an idea, what change could cause this, please let me know, it will be more easy for me. With regards, Pavel Troller
Dreamcom Kubik SMS crash
\ ntdll ELF 0x7bf0-7bf03000 Deferredwine-loader Threads: process tid prio (all id:s are in hex) 0008 (D) E:\DreamCom\DreamCom.exe 000e0 000d0 000c0 000b0 000a0 00090 == WineDbg terminated on pid 0x8 The program is very popular here in Czech Republic and in the specialized GSM mailing list there were already posts that it's the only one which keeps users on windoze. It's the reason I'm asking here whether it could be possible to fix it. It never worked in any version of wine yet, AFAIK. With regards, Pavel Troller
SJphone crashing
Hi!
I would like to test a free softphone application called SJphone (free
download from http://www.sjlabs.com ). I know there is a native Linux version,
but it's much less featured than the windows one (mainly missing skin support
and generally less options) and because I need to train other users how to use
the windows version, I have to try it for myself first :-).
Installation is working well, no errors encountered. However, after trying to
run the program, its GUI appered for a while with a sandclock cursor and then
the following crash occured.
I don't have access to real windows so I don't have any windows DLLs
available. Would it be possible to fix wine's ones to make the program working ?
With regards, Pavel Troller
P.S. running CVS wine from 06/01/15 (yesterday).
[EMAIL PROTECTED]:~/.wine/drive_c/Program Files/SJLabs/SJphone$ wine SJphone.exe
err:wave:OSS_WaveOutInit open(/dev/mixer2) failed (No such file or directory)
err:wave:OSS_WaveInInit open(/dev/mixer2) failed (No such file or directory)
fixme:ole:CoRegisterMessageFilter stub
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7ff51ee8)-((nil),0008)
fixme:ras:RasEnumConnectionsA (0x7f7b10a0,0x7fc68e34,0x7fc68e40),stub!
fixme:ras:RasEnumConnectionsA RAS support is not implemented! Configure program
to use LAN connection/winsock instead!
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7ff64d48)-((nil),0008)
err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not
registered
err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59}
could be created for for context 0x1
fixme:ole:CoCreateInstance no classfactory created for CLSID
{4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154
fixme:win:LockWindowUpdate (0x2002a), partial stub!
fixme:win:LockWindowUpdate ((nil)), partial stub!
fixme:keyboard:RegisterHotKey (0x2002a,1,0x0006,81): stub
fixme:keyboard:RegisterHotKey (0x2002a,2,0x0006,66): stub
fixme:keyboard:RegisterHotKey (0x2002a,3,0x0006,76): stub
fixme:keyboard:RegisterHotKey (0x2002a,4,0x0006,78): stub
fixme:keyboard:UnregisterHotKey (0x2002a,5): stub
fixme:keyboard:RegisterHotKey (0x2002a,6,0x0006,83): stub
fixme:keyboard:RegisterHotKey (0x2002a,7,0x0006,77): stub
err:msacm:MSACM_GetRegistryKey No alias needed for registry entry
wine: Unhandled page fault on write access to 0x59be at address 0x3f6dbd50
(thread 0009), starting debugger...
WineDbg starting on pid 0x8
Unhandled exception: page fault on write access to 0x59be in 32-bit code
(0x3f6dbd50).
In 32 bit mode.
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
EIP:3f6dbd50 ESP:7fc68248 EBP:7fc689ec EFLAGS:00210246( - 00 -RIZP1)
EAX:015000d4 EBX:3f6e4e04 ECX:209c EDX:54da0020
ESI:009c7ffc EDI:7fa403d0
Stack dump:
0x7fc68248: 7fc68250 7fa40408 0078 009c7ffc
0x7fc68258: 015000d4 00d700d6 016e0158 017000da
0x7fc68268: 00dd00dc 00df0162 00e10155 010300e2
0x7fc68278: 013a00e4 00e70107 00e9010d 00eb0119
0x7fc68288: 00ed011b 010f00ee 01440111 00f30148
0x7fc68298: 015100f4 00f700f6 016f0159 017100fa
Backtrace:
=1 0x3f6dbd50 in msacm32 (+0xbd50) (0x3f6dbd50)
2 0x3f6dc2d9 MSACM_RegisterDriver+0x139 in msacm32 (0x3f6dc2d9)
3 0x3f6d88fb acmDriverAddA+0x4b in msacm32 (0x3f6d88fb)
4 0x0057dea5 in sjphone (+0x17dea5) (0x0057dea5)
5 0x (0x)
6 0x005781e0 in sjphone (+0x1781e0) (0x005781e0)
0x3f6dbd50: movl%eax,0x0(%edx,%esi,8)
Modules:
Module Address Debug info Name (131 modules)
PE 0x0040-0085e000 Export sjphone
PE 0x1000-10006000 Deferredmozctlx
ELF 0x2000-20015000 Deferredld-linux.so.2
ELF 0x20015000-2002f000 Deferredlibwine.so.1
ELF 0x2002f000-2004 Deferredlibpthread.so.0
ELF 0x2004-20149000 Deferredlibc.so.6
ELF 0x20149000-2014c000 Deferredlibdl.so.2
ELF 0x2014c000-20169000 Deferrediphlpapielf
\-PE 0x2015-20169000 \ iphlpapi
ELF 0x20169000-201af000 Deferredrpcrt4elf
\-PE 0x2018-201af000 \ rpcrt4
ELF 0x201af000-20257000 Deferredcomctl32elf
\-PE 0x201c-20257000 \ comctl32
ELF 0x20257000-202e3000 Deferredoleaut32elf
\-PE 0x2027-202e3000 \ oleaut32
ELF 0x202e3000-202fb000 Deferredversionelf
\-PE 0x202f-202fb000 \ version
ELF 0x202fb000-20374000 Deferredwinex11elf
\-PE 0x2031-20374000 \ winex11
ELF 0x20374000-2037a000 Deferredlibxxf86dga.so.1
ELF 0x2037a000-2038 Deferredlibxxf86vm.so.1
ELF 0x2038-2039 Deferredlibxext.so.6
ELF 0x2039-20393000 Deferredxlcdef.so.2
ELF 0x20393000-203af000 Deferredimm32elf
\-PE
Registry entries for serial ports not created
Hi! I was trying to utilize a program for updating mobile phone's firmware (for Siemens/Benq mobiles, just an original app with encapsulated firmware image). This program immediately told that there are no serial ports present in my machine and terminated. After a bit of seeking in my own memory and wine list mail archive I remembered that there should be some registry entries which a program can examine and get some basic info about the ports. In an old mail I found something, which I converted to the following registry entry and put to system.reg file: [Hardware\\Devicemap\\Serialcomm] 1015709345 Serial0=COM1 Serial1=COM2 Serial2=COM3 Serial3=COM4 I think this should go to the standard system.reg by default, maybe in the reduced form with just the first two ports. Together with correct links in .wine/dosdevices, it makes that the program can really find the port. And at the end: How to create such a registry entry by wine's regedit ? I've spent about 15 minutes trying to do so but I've failed and then edited the file manually. Any attempt to create a folder called Serialcomm in Hardware\\Devicemap was unsuccessfull; I didn't find how to create a folder for keys, and using Add key menu entry I always got an error dialog saying A subkey must be volatile. What does it mean ? With regards, Pavel Troller
Re: Registry entries for serial ports not created
Hm must be a win9x format. Because on winNT+ it's \Device\Serial0=COM1 - exactly as symlinks in \??\. Possibly, I don't know windoze at all. I just looked at the trace output, which key the program tried to open, and grepped that string in my mail archive. What I found, I entered to the registry, and the program was happy then. So, to prevent guessing or entering some default values for everybody, maybe it could be made configurable using winecfg; I can imagine a tab called I/O ports or similarly, which would allow users to enter their port configuration similarly as for disk drives. winecfg would create dosdevices links (or its equivalent) as well as those registry entries. With regards, Pavel Troller
Re: gethostbyname(my_name) and IL2-Sturmovik
@Pavel Troller I've checkt the /etc/hosts now. You were right, it says 127.0.0.1 localhost.localdomain localhost Zwirch (With Zwirch the Name of this Computer) But I can't just statically rewrite it, because I use DHCP. Also this is a fresh Ubuntu-Install, so I'm surely not the only Wine-User with such an /etc/hosts.. Hi ! Yes, I know that *MANY* well-known distros are wrong with /etc/hosts and similar files.. The trick is that specifying your hostname for localhost interface improves Linux functionality in the case that there isn't other network interface active. Otherwise, a plenty of services would not work locally. However, when a real network interface comes up, it should be changed and moved to the line with a real IP address, which is not so obvious in the real world... I think that it is NOT GOOD to patch wine to fix this case; it behaves absolutely correctly and all the problem should be solved by correctly configuring your Linux networking. Please see any good document about naming principles of network interfaces. With regards, Pavel Troller
Re: gethostbyname(my_name) and IL2-Sturmovik
On 12/13/05, David Nolden [EMAIL PROTECTED] wrote: @Pavel Troller I've checkt the /etc/hosts now. You were right, it says 127.0.0.1 localhost.localdomain localhost Zwirch (With Zwirch the Name of this Computer) But I can't just statically rewrite it, because I use DHCP. Also this is a fresh Ubuntu-Install, so I'm surely not the only Wine-User with such an /etc/hosts.. This link may be of interest: http://lists.debian.org/debian-devel/2005/10/msg00387.html Tom Hi! Yes, it uncovers even more problems with the /etc/hosts file on many distributions (hey, I'm so happy that I'm maintaining my own private distro, independently of all the big players on the market :-) ). However, your link talks mainly about localhost.localdomain. I am even more strict and I'm saying that the host name also should not be there. And because I know that the host name should be assigned to EXACTLY ONE network interface, it is a reason that in my distro, when there are no public if's active, a dummy0 comes up and the host name is assigned to it. This if holds an address DIFFERENT from localhost (192.168.0.1 is used as a preconfigured default on a fresh install). Once more, please don't patch wine, it's evidently not its problem at all! With regards, Pavel Troller
Re: gethostbyname(my_name) and IL2-Sturmovik
Hi! I think you are wrong. POSIX does not say that it's wrong to have the computer name associated with 127.0.0.1 in /etc/hosts, and it doesn't say that gethostbyname(my_name) should return a real IP. OK, but it also doesn't explicitly state that gethostbyname(my_name) may return 127.0.0.1, so it's just neutral :-). If I remember correctly, though, Microsoft, specifies that gethostbyname(my_name) *should* return real IP. I don't know M$ standards, sorry, cannot comment on this. This subtle difference means that Wine must take extra care. Fetching a real IP on a UNIX host is not trivial, but doable. Yes, it is. BUT: man 5 hosts tells that: The Berkeley Internet Name Domain (BIND) Server implements the Internet name server for UNIX systems. It aug ments or replaces the /etc/hosts file or host name lookup, and frees a host from relying on /etc/hosts being up to date and complete. So it seems to imply that the DNS info is currently an authoritative source for host name queries. Of course everybody knows it, I'm just making note of it to support my following question: Did you ever see in the real world that a DNS server would return 127.0.0.1 as a response to a regular host name query ? I think not. And on the other side, try to query a DNS server for localhost. Every DNS server should immediately return 127.0.0.1, it's RFC compliance requirement. Isn't it logical to keep the host table coherent with DNS ? Or are you happy that in case your DNS server fails you get totally different results ? Of course I cannot argue more. It's just about the administrator's personal style and knowledge. I'm maintaining and administering Unix systems from 1985, long before Linux was born, and I would never allow such a thing in my host table. But if the current distro maintainers are of another view, I will not do anything against it. It's just about Open Source freedom: I will remove that patch from wine for me, and that's it :-). With regards, Pavel Troller
Re: Repeat message - Why was the included patch rejected?
This message never seemed to make it to the list so here is a resend == Bob Hi Bob! I remember Your message, even with an answer from Alexandre. Maybe You've missed them ? Now copying Alexandre's reply: --- copy begin --- Anyone know why this patch wasn't applied ? I don't know about anyone else but I'm still getting va_list undeclared. The stdarg.h include has to go in the C files that need it, not in the header since it's not in the Windows header. -- Alexandre Julliard [EMAIL PROTECTED] --- copy end ---
Re: Fwd: Re: Fwd: MBR was destroyed
Hello, I think I still didn't make myself clear. Yes there is (I guess) a bad bug in Wine. But: giving normal users a right to write to /dev/hd? is very dangerous and should be avoided. Exactly, I second this. For example, in my standard Linux setup, the disks have the following permissions: brw--- 1 root root 3, 0 Nov 13 19:58 /dev/hda brw--- 1 root root 3, 1 Nov 13 19:58 /dev/hda1 brw--- 1 root root 3, 2 Nov 13 19:58 /dev/hda2 brw--- 1 root root 3, 3 Nov 13 19:58 /dev/hda3 brw--- 1 root root 3, 4 Nov 13 19:58 /dev/hda4 brw--- 1 root root 3, 5 Nov 13 19:58 /dev/hda5 brw--- 1 root root 3, 6 Nov 13 19:58 /dev/hda6 brw--- 1 root root 3, 7 Nov 13 19:58 /dev/hda7 Why would a normal user need a write access to /dev/hd? ? I can imagine just a single exception - when it is a windows partition, used directly by some windows emulation software (as vmware can). But AFAIK wine cannot do this, so it's not needed there. Wine can have bugs, any other application could have bugs that made them try to write things to /dev/hd?. You could get some virus or whatever that execute with you user's right and you really don't want it to wipe out your hdd, do you ? Even the user can have a bug :-). I'm running and administering UN*X systems from 1989 but I still strictly distinguish between root and user rights. I've found it very VERY useful. However, I'm also voting for finding and solving this wine bug. With regards, Pavel Troller
Re: Could not determine operating system. Exiting.
I'm guessing the answer is no, but is there a free version of the program or a demo that we can download? It's hard to find this type of bug without having the program to tinker with. Assuming the answer is no, can you provide the line where the dialog pops up and ~1000 lines before that point in a +version,+relay log? Zip that up and either send it back to the list (if the size isn't too large and the mailing list lets it through) or post it on a website where we can access the log. Hi James! Thanks for Your help, I made some progress in this issue. I've looked once more to the +relay log (+version gives nothing). I've found that about 2000 lines before the dialog pops up there is a block reading all the NAMES of environment variables and comparing them with OS. So I intuitively entered OS=Windows NT before starting the program and now I'm getting another pop-up, saying that only NT is supported. So my OS string is wrong. I can find, where my name string retrieved from the envvar, but there isn't any comparison visible in the log (i.e. it's done internally in the program). So what I need now, is an exact string, which NT4.0 put to the OS envvar. And I have a tip for wine improvement: maybe it would be good, that wine itself would set up such a variable according to the OS version it's emulating. With regards, Pavel Troller Thanks, James Hawkins
Strange problem with writing files from wine
Hi! I have problems with writing files from wine (today's CVS). Typical example is word95, which always writes something like: Cannot access folder F:\filename.doc : unaccessible or protected by password (in my local language, so it may be inaccurate). There is a small problem with this strange indentation (that the second double quote is on a next line, but it is not fatal. More fatal is that this dialog even occurs and the file cannot be written. I've created a tracefile with +file and I think I've found the problem. At the moment of attempt to write (in this example, F:\brumbal.doc), there appears: trace:file:CreateFileW L.\\F: GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L.\\F:,0x7fc8975c,(nil),(nil)) trace:file:RtlGetFullPathName_U (L.\\F: 520 0x7fc89508 (nil)) trace:file:get_dos_device LF: - /dev/hdb1 warn:file:CreateFileW Unable to create file L.\\F: (status c022) trace:file:CreateFileW returning 0x trace:file:RtlDosPathNameToNtPathName_U (LF:\\,0x7fc89744,(nil),(nil)) trace:file:RtlGetFullPathName_U (LF:\\ 520 0x7fc89508 (nil)) trace:file:wine_nt_to_unix_file_name L\\??\\F:\\ - /home/patrol/.wine/dosdevices/f:/ trace:file:GetFileAttributesW LF:\\brumbal.doc\r\n trace:file:RtlDosPathNameToNtPathName_U (LF:\\brumbal.doc\r\n,0x7fc8aae4,(nil),(nil)) trace:file:RtlGetFullPathName_U (LF:\\brumbal.doc\r\n 520 0x7fc8a8b0 (nil)) trace:file:CreateFileW L.\\F: GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L.\\F:,0x7fc8975c,(nil),(nil)) trace:file:RtlGetFullPathName_U (L.\\F: 520 0x7fc89508 (nil)) trace:file:get_dos_device LF: - /dev/hdb1 warn:file:CreateFileW Unable to create file L.\\F: (status c022) trace:file:CreateFileW returning 0x trace:file:RtlDosPathNameToNtPathName_U (LF:\\,0x7fc89744,(nil),(nil)) trace:file:RtlGetFullPathName_U (LF:\\ 520 0x7fc89508 (nil)) trace:file:wine_nt_to_unix_file_name L\\??\\F:\\ - /home/patrol/.wine/dosdevices/f:/ [EMAIL PROTECTED]:/opt/samba-dir/Program Files/Microsoft Office/Office$ Why the hell wine is trying to access /dev/hdb1 ? Yes, my home directory is on it, but I think that such a form of access is not good :-). In my .wine/dosdevices, there is clearly a line lrwxrwxrwx 1 patrol users 12 Sep 7 06:50 f: - /home/patrol Or am I misinterpreting the log and the failure is caused by something else ? Otherwise wine is working near to perfect now. With regards, Pavel Troller
Possible regression in CVS wine
Hi! I've just upgraded wine on my son's computer by today's CVS. He tried some games and one of them stopped working. It's hind95 and the game bails out on an illegal instruction - outb, jumping into winedbg. Backtrace shows just 3 levels of game code itself, no dlls involved. I understand that user code cannot perform direct hardware I/O, but the game worked just before the upgrade (on wine about 1 month old). I don't know whether wine is normally intercepting and emulating these instructions, and the CVS version doesn't, or whether a new wine caused that another code path has been activated in the game code, leading to such a problem. There is also native w2k version of the game (hind.exe) but it still doesn't work in wine: it very sow renders the splash screen and then sits there and does nothing more. The game can be freely downloaded from www.abandonia.com; just search hind in the title page. There is probably a dynamic download URL used so I'm not posting it there. With regards, Pavel Troller
Re: Possible regression in CVS wine
Hi, I haven't tried to run the game but maybe the problem is that wine now defaults to behave like Win 2000[1] which does not allow privileged instructions. You could try to set windows version to 98 with winecfg Hi! Thanks, it was really the problem. Program runs now, and even better than before. We upgraded wine because some programs were not getting the keyboard and this problem now seems to be fixed. With regards, Pavel Troller
Re: Wine-20050830 Compile error
Hello, After getting the lastest tar, I get the following error: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o add.o add.c In file included from add.c:39: winldap_private.h:289: error: syntax error before BerElement winldap_private.h:290: error: syntax error before BerElement winldap_private.h:322: error: syntax error before BerElement winldap_private.h:323: error: syntax error before BerElement make[2]: *** [add.o] Error 1 make[2]: Leaving directory `/usr/src/wine/dlls/wldap32' make[1]: *** [wldap32] Error 2 make[1]: Leaving directory `/usr/src/wine/dlls' make: *** [dlls] Error 2 Hi! Exactly the same here. BerElement is undefined in winldap_private.h. It's defined in winldap.h but trying to include both winldap.h and winldap_private.h leads to a lot of collisions. So I copied the definition of BerElement from winldap.h to winldap_private.h and it at least compiles :-). With regards, Pavel Troller
Re: CVS Problem
On 8/27/05, Andrew Neil Ramage [EMAIL PROTECTED] wrote: Further to the below, I noticed the following message when downloading CVS. cvs update: Updating wine/windows/ttydrv cvs update: Updating wine/windows/x11drv Unknown host cvs.kde.org. wine update from cvs.kde.org ??? Strange. But cvs.kde.org surely doesn't exist, because KDE moved to SVN, updating often from them, too. Anyone know what is wrong ? -- I just did a CVS update and it works fine here. Here too. Tom Regards, Pavel.
Re: Window geometry problem
Hi! I have a small update: Stuart Axon sent me a screenshot of the same app from wxp. Thanks! I placed the image together with the first (bad) one, the URL is http://www.sinus.cz/~patrol/ircape-wxp.png . Comparing the two images, one can find, that 1) Size of both is identical 2) Basic graphic elements are also identical 3) The slider is much bigger and incorrectly positioned 4) The same applies to the text window 5) Other elements are not present at all (Insert time info, Insert pause time) 6) The lonely checkbox may belong to auto line change text Observing this, can anybody determine a part of wine (dll or so), which is responsible for this ? Could I try it as native to see what would change ? Which regards, Pavel Troller
Re: Window geometry problem
Hi! I have a small update: Stuart Axon sent me a screenshot of the same app from wxp. Thanks! I placed the image together with the first (bad) one, the URL is http://www.sinus.cz/~patrol/ircape-wxp.png . Comparing the two images, one can find, that 1) Size of both is identical 2) Basic graphic elements are also identical 3) The slider is much bigger and incorrectly positioned 4) The same applies to the text window 5) Other elements are not present at all (Insert time info, Insert pause time) 6) The lonely checkbox may belong to auto line change text Observing this, can anybody determine a part of wine (dll or so), which is responsible for this ? Could I try it as native to see what would change ? Which regards, Pavel Troller
Window geometry problem
Hi! I would like to report a long lasting problem with an application, which renders its main window incorrectly in wine. The app is iRiver caption editor and it can be freely downloaded at http://www.iriveramerica.com/download/ce.zip . Installation of the program is easy and proceeds and the program itself runs well, but its window looks like a total mess. For a snapshot, look at http://www.sinus.cz/~patrol/ircape.png . I think it's not necessary to write more, what's wrong, simply the widgets are misplaced, incorrectly sized, the window has scrollbars, which it IMHO shouldn't have etc. The window is not resizable. It's the only app known to me which exhibits such a behaviour. I don't have a possibility to test it on a real windoze system, I don't have it. I'm about to file a bug for it, but I'm asking first here to verify that it's not an easily resolvable problem with my setup etc., and also whether a similar (or the same) behaviour isn't already registered. With regards, Pavel Troller
CryptUnprotectData undeclared - cannot compile
Hi! For some time, about 10 - 14 days, I cannot compile wine from CVS anymore. The reason is as follows: make[3]: Entering directory `/usr/src/emul/wine/dlls/crypt32/tests' ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole protectdata.o testlist.o -o crypt32_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/crypt32 -L../../../libs -lcrypt32 -s -L/opt/ungif/lib protectdata.o(.text+0x3b5): In function `test_cryptunprotectdata': /usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:114: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x42f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:120: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x4b9):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:129: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x54f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:140: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x702):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:160: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x782):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:167: more undefined references to `CryptUnprotectData' follow collect2: ld returned 1 exit status The same reported another user on the user's list, but nobody noticed it. It would be nice to fix this problem to be able to compile wine again. With regards, Pavel Troller
Re: CryptUnprotectData undeclared - cannot compile
Hello, have you done a cvs update -Pd ? Hello, of course, it's in my .cvsrc . cvs doesn't show any M'ed nor C'ed files, the update is clean. I also did a make clean in dlls, as suggested by Mike, but the problem is still there. Of course I know a standard procedure of ./configure ; make depend make and I'm always following it. Now I'm trying 'make distclean' before anything else... Yes, the problem is still there. Now I'm posting all the output from crypt32: make[2]: Entering directory `/usr/src/emul/wine/dlls/crypt32' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o cert.o cert.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o commctrl.o commctrl.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o encode.o encode.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o protectdata.o protectdata.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o datetime.o datetime.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o main.o main.c ../../tools/winebuild/winebuild -D__WINESRC__ -D_CRYPT32_ -o crypt32.dll.dbg.c --debug -C. cert.c encode.c protectdata.c main.c make[3]: Entering directory `/usr/src/emul/wine/dlls/crypt32/tests' gcc -c -I. -I. -I../../../include -I../../../include-D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o protectdata.o protectdata.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o draglist.o draglist.c gcc -c -I. -I. -I../../../include -I../../../include-D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o testlist.o testlist.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o flatsb.o flatsb.c ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole protectdata.o testlist.o -o crypt32_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/crypt32 -L../../../libs -lcrypt32 -s -L/opt/ungif/lib gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o header.o header.c protectdata.o(.text+0x3b5): In function `test_cryptunprotectdata': /usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:114: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x42f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:120: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x4b9):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:129: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x54f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:140: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x702):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:160: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x782):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:167: more undefined references to `CryptUnprotectData' follow collect2: ld returned 1 exit status So, still no luck. With regards, Pavel Troller
Re: CryptUnprotectData undeclared - cannot compile
solution is to: cd dlls rm *.def cd .. make Ciao, Marcus Hi Marcus, yes, Your solution is the Right One! Thanks! However, I think that something is wrong with make distclean, because it should erase all the generated files including these .def's ? Or is there a reason to keep them in (and possibly cause problems) ? With regards, Pavel Troller
Reporting Unknown EXE OS version and a non-functioning program
Hi!
Because my kids are obsessed by trains and everything about them, I've
decided to download them a train simulation game. Because I refuse to use
anything from M$ and I didn't find any train simulator for Linux, I've found
and downloaded a free miniature train simulator, available for download at
http://jeanmichel.kerdal.free.fr/Train/train.zip . I've unzipped the package
and tried to run the Install.exe file. But the only I get is
[EMAIL PROTECTED]:~/train$ wine Install.exe
fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 4.0, please report
!!
fixme:ole:CoRegisterMessageFilter stub
fixme:ole:OleLoadPictureEx
(0x7f9bdd4c,326,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x720dfb0c),
partially implemented.
fixme:ole:OLEPictureImpl_SaveAsFile (0x767bd768)-(0x767bffd0, 0, (nil)),
hacked stub.
The program then simply runs and waits fot the rain (or maybe train :-) ?)
without any visible activity and should be killed.
Normally I wouldn't report this because there is still a lot of programs which
are incompatible with wine (oh these windows programmers... :-) ). But this
one explicitly asked for reporting, so I'm just doing what it asked for :-).
This is with a fresh wine CVS update, which reports itself as wine-20050310.
With regards, Pavel Troller
Re: Poor performance when using Texas Instruments code generation tools in Wine
Hi ! We have some performance problems with Wine that we could use some help on.. Here's the story: We have been using TI code generation tools (compiler and linker) on Wine, and it has worked well. However, when we started evaluating newer versions of the codegen tools, the linking time was dramatically increased (from 20 sec to 30 minutes...). We have done some profiling using oprofile, and found that most of this time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll module. The time needed to locate a free heap block increases gradually, from a few iterations up to about 15000 in the project we are building. We suspect that this may be due to fragmentation caused by the heap allocate/free algorithms. Hi! Maybe this can also explain the slowdown of long-running apps under wine ? For example, DC++ runs perfectly when started, but after 12 hours of operation the window updates, search and other program functions are so incredibly slow, that it's better to kill it and restart. With regards, Pavel Troller
