March 2006 - Wine-Devel - list.winehq.org

Re: I have a complaint about the website

by Segin

Robert van Herk wrote: > >> sorry for my bad english i am not feeling well and it is affecting my >> corrdination, i can't walk right or type correctly. i can barely see >> the monitor, it's that bad. > > Don't worry, probably it's just a virus. > > Regards, > > Robert > > > > yeah, i think i got the karma-sutra or code-red when i hooked my brain to the internet.

March 27, 2006

Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.

by Tony Lambregts

Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Mar 27 22:43:03 2006 +0200 > > x11drv: Moved desktop mode handling to the explorer process. > > Per-application desktop mode settings are no longer supported. Apps > can be launched in a specific desktop window by using: > > explorer /desktop=name[,widthxheight] app.exe [args] > > If the named desktop already exists the app is launched inside it. The > default desktop is cleverly named "default". > So if I understand this correctly all programs will share the same desktop. Is it also true that I cannot specify in winecfg that one program can run full screen and another in a desktop window. If this is the case we will have a fair amount of crying over this one. At the very least we need to put a note in winecfg. (preferabley befor next release). -- Tony Lambregts

March 27, 2006

Re: I have a complaint about the website

by Segin

Jason Green wrote: >On 3/27/06, Segin <segin2005(a)gmail.com> wrote: > > >>Due to the current state of Wine, plus it's archjitechure, Even if a >>virus was found, it is much easier to remove. >> >>If the virus is a memory-resident kind, you can do pkill -9 wine as root >>or your user and shut down ile essentially killing said virus. >> >>A lot of viruses, in order to keep small, attempt to make fnction calls >>based on a DLL function absolute address. This has a 1 in 256 million >>cnahce in working, because each time you recodmile wine, the function >>entry points change. all that aill result in is a segmentation fault. >> >> > >I agree that running viruses are much more difficult in Wine than in >Windows, however, by default, Wine maps Z:\ to your entire Linux tree. > If the user running Wine has write-access to any other folders in the >Linux system tree and runs a virus which randomly deletes or modifies >files on any accessible drive letter, that is still a problem. Plus, >some users don't use "rm -rf .wine/" on a daily basis like most devs >do, and they may actually store useful things under their .wine/ >folder. In the (albeit, unlikely) event of "succesfully" running a >Windows virus, those files are at risk. > >There are plenty of distros that install some version of Wine by >default and automatically associate .exe's and the like with Wine, so >users that aren't careful are still at risk. Granted, that risk is >minimized by not being fully compatible with everything Windows does >[yet], but it's still a risk. > > > maybe if we put in a md5sum database of viruses and refuse to run those that are viruses? it's not as good as a real a/v app, but it's a start.

March 27, 2006

Re: I have a complaint about the website

by Segin

Philip V. Neves wrote: > On the website there is an article that talks about homogenious > populations being a threat to society and to the computer industry. > Although I accept the fact that this is mostly true I believe that is > a good argument for creating the Linux OS and other OS's not for > creating wine. With the wine project you are bringing the homogenious > population to the Linux community. So theoretically a virus could > spread just as easily through a wine system as well as a Windows > system. That virus could spread even if the security in Linux is in > place. The wine installation could be affected and we have to > reinstall the wine directory. > > I'd appreciate it if you guys would take that out of the website. I > feel it hurts the credibility of your project by having it there. The > fact is if a company has a wine installation they could have a large > number of appications that could be affected by a virus. Wine running > on a different system won't fix that. Although the security system in > Linux could provide some security against accessing more vital parts > of the system, the wine installation is still vulnerable due to the > fact its implementing windows system calls. > > I have infact found viruses with Clam after installing wine. So I > don't feel that this statement is true. > > > Due to the current state of Wine, plus it's archjitechure, Even if a virus was found, it is much easier to remove. If the virus is a memory-resident kind, you can do pkill -9 wine as root or your user and shut down ile essentially killing said virus. A lot of viruses, in order to keep small, attempt to make fnction calls based on a DLL function absolute address. This has a 1 in 256 million cnahce in working, because each time you recodmile wine, the function entry points change. all that aill result in is a segmentation fault. sorry for my bad english i am not feeling well and it is affecting my corrdination, i can't walk right or type correctly. i can barely see the monitor, it's that bad.

March 27, 2006

Re: I have a complaint about the website

by Robert van Herk

> sorry for my bad english i am not feeling well and it is affecting my > corrdination, i can't walk right or type correctly. i can barely see > the monitor, it's that bad. Don't worry, probably it's just a virus. Regards, Robert

March 27, 2006

Re: I have a complaint about the website

by Kuba Ober

> maybe if we put in a md5sum database of viruses and refuse to run those > that are viruses? You mean worms? Viruses modify existing files and thus it's pointless to check whole-file checksums. Signature checking has significant runtime impact (say a second just to get one .exe checked), so it's not something you'd want to do each time an .exe is about to be run. Then there are many variations of signature checks, as some virii are polymorphic and so on. I'd say it's best not to reinvent the wheel, and providing a false sense of security is pretty bad. The only real solution for the users is to run a virus scanner at regular intervals, and additionally to maybe run wine in a chroot jail (that's a packaging issue). Cheers, Kuba

March 27, 2006

Re: I have a complaint about the website

by Jason Green

On 3/27/06, Segin <segin2005(a)gmail.com> wrote: > Due to the current state of Wine, plus it's archjitechure, Even if a > virus was found, it is much easier to remove. > > If the virus is a memory-resident kind, you can do pkill -9 wine as root > or your user and shut down ile essentially killing said virus. > > A lot of viruses, in order to keep small, attempt to make fnction calls > based on a DLL function absolute address. This has a 1 in 256 million > cnahce in working, because each time you recodmile wine, the function > entry points change. all that aill result in is a segmentation fault. I agree that running viruses are much more difficult in Wine than in Windows, however, by default, Wine maps Z:\ to your entire Linux tree. If the user running Wine has write-access to any other folders in the Linux system tree and runs a virus which randomly deletes or modifies files on any accessible drive letter, that is still a problem. Plus, some users don't use "rm -rf .wine/" on a daily basis like most devs do, and they may actually store useful things under their .wine/ folder. In the (albeit, unlikely) event of "succesfully" running a Windows virus, those files are at risk. There are plenty of distros that install some version of Wine by default and automatically associate .exe's and the like with Wine, so users that aren't careful are still at risk. Granted, that risk is minimized by not being fully compatible with everything Windows does [yet], but it's still a risk.

March 27, 2006

Re: I have a complaint about the website

by Hiji

> So theoretically a virus could spread just as > easily through a wine system as well as a Windows > system. That virus could spread even if the > security in Linux is in place. The wine > installation could be affected and we have to > reinstall the wine directory. Take a look at this. It's a good read: http://winehq.org/?issue=259#Wine%20&%20Viruses Hiji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

March 27, 2006

Winetools -> wine doors

by penna＠bb.com.br

Hi Karl, > I would love it if people would get involved, a few good coders can have > SVN/trac access I'll work on opening up to the public soon. > > pygtk/pyxml/wine hackers/shell scripters very welcome. Maybe I can help with bash scripting (very good skill) .... I know nothing about python ... 8( ... but can learn quickly. BTW, I would like to point out two suggestions: 1) you (we) should set up a winedoors-devel list. This discussion should be out of the wine-devel list (we should not mix things up and wine devel folks are already too busy) 2) the winedoors should return some information to the AppDB in order to keep that information for the wine devel folks get some feedback what is going on with, for example, DLL overrides. For example, if the AppDB keeps track of the most overriden DLLs (information "feeded" by winedoors - or winetools 8)) I think wine developers could query the database in order to see which DLL needs some improvement because its is the most one overriden. One more thing, I like Winetools. It helped me a lot. Does it need improvement? Yes, it needs, but it is not the reason we may "burn" it. Regards (I am not subscribed at wine-devel list, so please cc me) --------------------------------------------------------- Ulisses de Sousa Penna Analista Consultor - Banco do Brasil Fone: +55-61-3310-6320 Fax: +55-61-3310-6435 ---------------------------------------------------------

March 27, 2006

I have a complaint about the website

by Philip V. Neves

On the website there is an article that talks about homogenious populations being a threat to society and to the computer industry. Although I accept the fact that this is mostly true I believe that is a good argument for creating the Linux OS and other OS's not for creating wine. With the wine project you are bringing the homogenious population to the Linux community. So theoretically a virus could spread just as easily through a wine system as well as a Windows system. That virus could spread even if the security in Linux is in place. The wine installation could be affected and we have to reinstall the wine directory. I'd appreciate it if you guys would take that out of the website. I feel it hurts the credibility of your project by having it there. The fact is if a company has a wine installation they could have a large number of appications that could be affected by a virus. Wine running on a different system won't fix that. Although the security system in Linux could provide some security against accessing more vital parts of the system, the wine installation is still vulnerable due to the fact its implementing windows system calls. I have infact found viruses with Clam after installing wine. So I don't feel that this statement is true.

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Tomas Carnecky

Huw D M Davies wrote: > On Mon, Mar 27, 2006 at 05:05:23PM +0100, Huw D M Davies wrote: >> Ah right, glDrawBuffer alters the rendering state, that's bad. We >> should presumably be calling glXSwapBuffers here (but only in the >> GLXPixmap case). > > Which of course won't work either. > > We need to find out what happens to the render state under Windows > when we make call wglMakeCurrent on a bitmap (I know that even with > the rendering state set for GL_BACK then the bitmap gets drawn on) and > whether we restore the rendering context when we switch back to using > some other dc afterwards. We probably shouldn't do anything in the > pbuffer case (which is what's causing your problem I guess). > > The big issue is that pbuffers and bitmap rendering are getting > confused all over the place. > Feel free to take http://dbservice.com/tom/LinuxTest.cpp, change it and test it.. it's a win32 application, despite its name :) tom

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

Petr Tesarik <hat(a)tesarici.cz> writes: > That means that Windows XP creates a new thread in the given process > and breaks it at DbgBreak(). > > Does this mean that we may avoid sending SIGTRAP altogether? Creating a new thread is probably even harder, but yes we can certainly avoid SIGTRAP. One possible way is to use SIGUSR1 to change the thread context to simulate a call to DbgBreakPoint. -- Alexandre Julliard julliard(a)winehq.org

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Huw D M Davies

On Mon, Mar 27, 2006 at 05:05:23PM +0100, Huw D M Davies wrote: > Ah right, glDrawBuffer alters the rendering state, that's bad. We > should presumably be calling glXSwapBuffers here (but only in the > GLXPixmap case). Which of course won't work either. We need to find out what happens to the render state under Windows when we make call wglMakeCurrent on a bitmap (I know that even with the rendering state set for GL_BACK then the bitmap gets drawn on) and whether we restore the rendering context when we switch back to using some other dc afterwards. We probably shouldn't do anything in the pbuffer case (which is what's causing your problem I guess). The big issue is that pbuffers and bitmap rendering are getting confused all over the place. Huw. -- Huw Davies huw(a)codeweavers.com

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Tom Spear (Dustin Booker, Dustin Navea)

Tomas Carnecky wrote: > I don't know if it even runs.. I mean, if it works correctly. > > http://dbservice.com/tom/LinuxTest.exe > > It creates LinuxTest.log in the same directory as the executable, and > prints out whether pbuffers are supported and which drawbuffers are > activated.. > > tom > > Well, I ran the file, and it did create the log, but in my case it said that pbuffers weren't supported in either spec. Tom

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Huw D M Davies

On Mon, Mar 27, 2006 at 05:32:12PM +0200, Tomas Carnecky wrote: > Huw D M Davies wrote: > > On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote: > >> GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo. > >> And I don't think PBuffers or Pixmaps can be stereo, so is there any > >> special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so? > > > > See man glXCreateGLXPixmap. The X pixmap is used as the front left > > buffer of the resulting rendering area, so we make sure that we're > > rendering into the X pixmap, not some dummy buffer created by > > glXCreateGLXPixmap. > > > > Ok, but see what happens if an application has one rendering context, > one window (doublebuffered) and one pbuffer (doublebuffered or not), > activates the window (per default the backbuffer is selected for > rendering), then activates the pbuffer (together with the same context), > now wglMakeCurrent() calls glDrawBuffer(GL_FRONT_LEFT), so the > frontbuffer is selected for rendering, and now the application again > activates the window and now it suddenly renders into the frontbuffer, > instead of the backbuffer like it thinks. > > wglMakeCurrent() isn't supposed to change the rendering context state > (someone prove me wrong, I couldn't find any good description of this > function, but neither does glXMakeCurrent) and application can make > assumptions according to that. > > I don't have any wgl-pbuffer demos here, those from the nvidia sdk don't > run (and won't for a looong time, sadly). And one application to test it > with apparently isn't enough. > > I have written a test for windows (to test whether wglMakeCurrent > changes the drawbuffer or not), but nobody of my friends has a graphics > card that supportd pbuffers. Ah right, glDrawBuffer alters the rendering state, that's bad. We should presumably be calling glXSwapBuffers here (but only in the GLXPixmap case). Huw. -- Huw Davies huw(a)codeweavers.com

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Tom Spear (Dustin Booker, Dustin Navea)

Tomas Carnecky wrote: > I have written a test for windows (to test whether wglMakeCurrent > changes the drawbuffer or not), but nobody of my friends has a graphics > card that supportd pbuffers. > > tom > > > > I have a GF FX5700. Does that support pbuffers? If so, I'll run the test.... Tom

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Tomas Carnecky

Huw D M Davies wrote: > On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote: >> GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo. >> And I don't think PBuffers or Pixmaps can be stereo, so is there any >> special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so? > > See man glXCreateGLXPixmap. The X pixmap is used as the front left > buffer of the resulting rendering area, so we make sure that we're > rendering into the X pixmap, not some dummy buffer created by > glXCreateGLXPixmap. > Ok, but see what happens if an application has one rendering context, one window (doublebuffered) and one pbuffer (doublebuffered or not), activates the window (per default the backbuffer is selected for rendering), then activates the pbuffer (together with the same context), now wglMakeCurrent() calls glDrawBuffer(GL_FRONT_LEFT), so the frontbuffer is selected for rendering, and now the application again activates the window and now it suddenly renders into the frontbuffer, instead of the backbuffer like it thinks. wglMakeCurrent() isn't supposed to change the rendering context state (someone prove me wrong, I couldn't find any good description of this function, but neither does glXMakeCurrent) and application can make assumptions according to that. I don't have any wgl-pbuffer demos here, those from the nvidia sdk don't run (and won't for a looong time, sadly). And one application to test it with apparently isn't enough. I have written a test for windows (to test whether wglMakeCurrent changes the drawbuffer or not), but nobody of my friends has a graphics card that supportd pbuffers. tom

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

Dne 03/27/06 v 08:13:23 (-0700), Vitaliy Margolen napsal(a): > > There is no other way to detect a hardware breakpoint than to look > > at DR6. Additionally, since the bits would get stuck for all > > subsequent SIGTRAPs, we need to clear them. > > [skip] > > Please don't forget here that we are not inventing something new. We can > not deviate from what native does, or it will brake some applications. If > you have a test case that shows that windows does what you trying to do - > I would like to see it. Or you could write your own test to test this on > windows. Maybe, you're missing my point. I'm trying to avoid DR6 altogether. And I can do it on some platforms. However, some Unixes seem to be crippled and I'm trying to provide a reasonable fallback for them. BTW if we forbid sending SIGTRAP to a Wine process, there will be more such platforms. AFAIK SIGTRAP is only sent internally by wineserver for DebugBreakProcess(). I'll have a look at it. Petr Tesarik

March 27, 2006

Re: server: Fix FPU registers in get_thread_context()

by Petr Tesarik

Dne 03/27/06 v 08:03:58 (-0700), Vitaliy Margolen napsal(a): > Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote: > > > Hi, > > > this patch fixes a bug in get_thread_context(). Currently, this > > routine assumes that all registers except debug registers are saved in > thread->>context if it exists. However, it does not include FPU > > registers. > > > IMO, we should not blindly assume which registers are present in > thread->>context but look at ContextFlags. > > > BTW I found this bug when winedbg stopped working with programs using > > the FPU. > > > ChangeLog: > > > * Look at ContextFlags to see which registers are saved in > > thread->context. > > Sorry this is not correct. Exception handler should get full context > including FPU context. If we not saving it that's the problem on the > other end. I don't think so. A real 80386 without a math coprocessor does not even have an FPU context. I guess this is why CONTEXT_FULL does not include CONTEXT_FLOATING_POINT. Petr Tesarik

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

Petr Tesarik <hat(a)tesarici.cz> writes: > Oh, I forgot to mention another thing. I didn't start all this for > nothing. I made my changes to raise_trap_exception() to make an > existing application (Kindler Lexikon) work. Sure, I'm not saying you did this for no reason. I just have the feeling you are changing a lot of things that don't need to be changed. This is a sensitive area of the code that a lot of apps depend on, and we have to be very careful about making changes. > [...] > Pretty long, huh? The thing is that all of this is necessary because you want to handle a SIGTRAP sent with kill(). But obviously no Windows application is going to send us a SIGTRAP; the only way this will happen is when we do it ourselves in DebugBreakProcess, and there's nothing that says that we can't use a different mechanism here if it works better. I'd say that somehow reusing the existing SIGUSR1 support is probably a better choice. -- Alexandre Julliard julliard(a)winehq.org

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

Dne 03/27/06 v 16:49:13 (+0200), Alexandre Julliard napsal(a): > Petr Tesarik <hat(a)tesarici.cz> writes: > > > In my opinion, the solution is reasonable because if any application > > is really interested in the DR6 register (i.e. it is a debugger), it > > will clear the status register (DR6) anyway, since the processor never > > clears the bits and unless you clear them manually, the register gets > > pretty useless. > > There are applications other than debuggers that care about debug > registers, notably copy protection code. We can't afford to do things > differently even if they sound reasonable. I'm afraid I can't understand you. At first, you're advocating the wrong test for the TF bit by the fact that it's 99.9 % correct and then you're criticizing clearing DR6 which is also 99.9 % correct. Not enough on that, I've provided a patch already which is 100 % correct on most platforms and only 99.9 % correct on the remaining ones. If you talk about copy protection schemes, I've seen code like this (while debugging self, of course): pushf pop %eax orl $0x100,%eax push %eax popf ; some code pushf pop %eax andl ~$0x100,%eax push %eax popf Now, native Windows will generate EXCEPTION_SINGLE_STEP after the last popf. In Wine you'll get a SIGTRAP (possibly with get_trap_code() == TRAP_x86_TRCTRAP, if TRAP_sig is defined for the platform). This will check the TF bit in context->EFlags. Since this is not set, it will fetch the debug registers and check the lowest 4 bits. These will be zero, so Wine generates an EXCEPTION_BREAKPOINT. I've already explained in another email that it's not possible to get the correct behavior in any other way than the way I've proposed. Petr Tesarik

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Vitaliy Margolen

Monday, March 27, 2006, 7:58:38 AM, Petr Tesarik wrote: > Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a): >> Petr Tesarik <hat(a)tesarici.cz> writes: >> >> > No, Windows need not do things like that, because the Windows kernel >> > knows very well, whether it got INT1 or INT3... Some UNIX kernels do >> > not give us that information reliably. >> >> I'm afraid it's not acceptable to do things differently, especially >> not things like the checking of the previous instruction that may >> cause extra exceptions. Also stuff like the clearing of DR6 needs a >> test case, that's something that's visible from the application. [skip] > There is no other way to detect a hardware breakpoint than to look > at DR6. Additionally, since the bits would get stuck for all > subsequent SIGTRAPs, we need to clear them. [skip] If you need a program that uses DR6 for copy protection and will brake if you touch anything in it look here: http://bugs.winehq.org/show_bug.cgi?id=4036 It's using hardware breakpoints for lots of nasty things. And depends on the _exact_ content of the DR* registers when exception handler is called. Also it sets those registers only once. So if you alter any of the DR* registers in any way, this copy protection will brake. Please don't forget here that we are not inventing something new. We can not deviate from what native does, or it will brake some applications. If you have a test case that shows that windows does what you trying to do - I would like to see it. Or you could write your own test to test this on windows. Vitaliy.

March 27, 2006

Re: server: Fix FPU registers in get_thread_context()

by Vitaliy Margolen

Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote: > Hi, > this patch fixes a bug in get_thread_context(). Currently, this > routine assumes that all registers except debug registers are saved in thread->>context if it exists. However, it does not include FPU > registers. > IMO, we should not blindly assume which registers are present in thread->>context but look at ContextFlags. > BTW I found this bug when winedbg stopped working with programs using > the FPU. > ChangeLog: > * Look at ContextFlags to see which registers are saved in > thread->context. Sorry this is not correct. Exception handler should get full context including FPU context. If we not saving it that's the problem on the other end. Vitaliy Margolen

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a): > Petr Tesarik <hat(a)tesarici.cz> writes: > > > No, Windows need not do things like that, because the Windows kernel > > knows very well, whether it got INT1 or INT3... Some UNIX kernels do > > not give us that information reliably. > > I'm afraid it's not acceptable to do things differently, especially > not things like the checking of the previous instruction that may > cause extra exceptions. Also stuff like the clearing of DR6 needs a > test case, that's something that's visible from the application. Oh, I forgot to mention another thing. I didn't start all this for nothing. I made my changes to raise_trap_exception() to make an existing application (Kindler Lexikon) work. Now, the copy protection mechanism in Kindler Lexikon uses a DOS application (no kidding!), so if you accept the VM86-related stuff that I posted earlier, so that raise_trap_exception() is not used for VM86-generated debug traps, it would probably be enough. However, as a side effect I noticed that the code does not work well, so I fixed it. If my fix is not good enough, well, then the UNIX ABI is not good enough, because: 1. A SIGTRAP can be delivered as a result of: a. INT 1 (single step or hardware breakpoint) b. INT 3 (INT3 or INT 03) c. kill() or tgkill() on the process 2. sc_trapno in sigcontext is set correctly by Linux only for 1a and 1b. The value of sc_trapno for 1c is undefined (and it may be even 1 or 3; I can provide a test case if needed). 3. Since you want to raise a BREAKPOINT exception for 1c, a BREAKPOINT exception with ExceptionAddress decremented by 1 for 1b and a SINGLE_STEP exception for 1a, you have to distinguish between those three cases. 4. You can tell the 1c case from 1b or 1c from the si_code in siginfo. However, this field might not be available. Things are even worse, because even TRAP_sig might be unavailable on some platforms! 5. Since the kernel does not provide enough information to distinguish between 1a, 1b and 1c, you have to investigate the reason yourself. There is no other way to detect a hardware breakpoint than to look at DR6. Additionally, since the bits would get stuck for all subsequent SIGTRAPs, we need to clear them. There is no other way to detect an INT3 breakpoint than to look at the code that immediately precedes the exception address. However, there is no guarantee that this address is mapped at all (a hardware breakpoint may occur anywhere, even at the first opcode of a page). Since native Windows won't crash in such cases, neither should we. That's why the whole thing is in a TRY block. Pretty long, huh? Petr Tesarik

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

Petr Tesarik <hat(a)tesarici.cz> writes: > In my opinion, the solution is reasonable because if any application > is really interested in the DR6 register (i.e. it is a debugger), it > will clear the status register (DR6) anyway, since the processor never > clears the bits and unless you clear them manually, the register gets > pretty useless. There are applications other than debuggers that care about debug registers, notably copy protection code. We can't afford to do things differently even if they sound reasonable. > I wonder why you haven't been bothered by the fact that the current > implementation silently drops the TF bit, which is even worse! :O I'm sure there are bugs in the current implementation, but that's not a reason for introducing different ones... If you find anything that the current code is doing wrong, please provide a test case demonstrating the bug, and I'll be more than happy to fix it (or to accept a fix if you have one). -- Alexandre Julliard julliard(a)winehq.org

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Petr Tesarik

Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a): > Petr Tesarik <hat(a)tesarici.cz> writes: > > > No, Windows need not do things like that, because the Windows kernel > > knows very well, whether it got INT1 or INT3... Some UNIX kernels do > > not give us that information reliably. > > I'm afraid it's not acceptable to do things differently, especially > not things like the checking of the previous instruction that may > cause extra exceptions. Also stuff like the clearing of DR6 needs a > test case, that's something that's visible from the application. I don't want to cause unnecessary conflicts, so I _have_ written a test case, where Wine does a lot of application-visible things differently. Anyway, I've provided an improvement which only needs to do such things as a fallback on platforms, where the cause of the SIGTRAP cannot be determined easily. In my opinion, the solution is reasonable because if any application is really interested in the DR6 register (i.e. it is a debugger), it will clear the status register (DR6) anyway, since the processor never clears the bits and unless you clear them manually, the register gets pretty useless. I wonder why you haven't been bothered by the fact that the current implementation silently drops the TF bit, which is even worse! :O Petr Tesarik

March 27, 2006

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()

by Huw D M Davies

On Sat, Mar 25, 2006 at 02:23:01AM +0100, Tomas Carnecky wrote: > GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo. > And I don't think PBuffers or Pixmaps can be stereo, so is there any > special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so? See man glXCreateGLXPixmap. The X pixmap is used as the front left buffer of the resulting rendering area, so we make sure that we're rendering into the X pixmap, not some dummy buffer created by glXCreateGLXPixmap. Huw. -- Huw Davies huw(a)codeweavers.com

March 27, 2006

Re: ntdll: Fix SIGTRAP handling

by Alexandre Julliard

Petr Tesarik <hat(a)tesarici.cz> writes: > 2. The x86 spec states that a single-step interrupt (INT 1) is > generated if the TF bit was set when the execution of the > instruction BEGAN. This means that if the instruction changes the > TF bit (e.g. popf), there is an INT 1, but the TF bit is not set > any more. The only way to check whether the interrupt was > generated because of the TF bit, is to check bit 15 in DR6. I don't see why you can't still check the TF bit, it will be set 99% of the time, and fetching the DR6 register is quite expensive. > The following patch fixes all of these issues. I'd really like to see test cases showing that Windows does things this way. -- Alexandre Julliard julliard(a)winehq.org

March 27, 2006

Re: advpack: Add initial tests for RunSetupCommand

by Detlef Riekenberg

Am Donnerstag, den 23.03.2006, 23:12 -0600 schrieb James Hawkins: > * Add initial tests for RunSetupCommand. > dlls/advpack/tests/install.c | 106 ++++++++++++++++++++++++++++++++++++++++ Hi. Your tests used a fixed Path, resulting to failure on: - win95, win98 and winme (c:\windows\system) - NT3.51 (c:\winnt35\system32) - NT4 and w2k (c:\winnt\system32) - Every Installation, that use a non-default Installation-Directory - Every update of an NT < winxp (I don't know about the default Path in Versions > winxp) Your Patch is already in the tree, so expect many tests to fail. -- By By ... ... Detlef

March 27, 2006

FPU context in signal handlers

by Petr Tesarik

Hi, I've just submitted a patch that handles the FPU state in signal handlers. However, the FPU_sig() macro is only defined for Linux, so other architectures won't benefit from that patch. I doubt that i387 FPU state is left untouched by the kernel on other architectures, but I have no access to any such box (*BSD, BSDI, SCO, Apple), I cannot investigate into that, and the FPU handling is most likely broken on those architectures. This has become more serious now that winedbg tries to fetch (and restore!) the FPU state on the i386 architecture. I guess that architectures with (context)->uc_mcontext also define (context)->uc_mcontext.fpregs (SCO), but since I can't test it, I won't send such a patch to wine-patches. Is there anything I might do about it? Anybody wants to help? Petr

March 27, 2006

Re: Regression in wine made 2006/03/23

by James Hawkins

On 3/27/06, Pavel Troller <patrol(a)sinus.cz> wrote: > 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 Works fine for me with CVS. Are you fully up to date? What version of DC++ are you using? -- James Hawkins

March 27, 2006

Re: [Wine] Wine/Interix -- The pros and cons.

by Geoff Streeter

At 2006-03-24 22:26 -0500, Segin wrote: >I was thinking about running Wine on Interix (the POSIX layer of >Microsoft's Services for Unix). There are a few apparent unknows: > >Would Wine load the .dll.so's? Since Interix uses PE for it's native >format (running on Windows, duh), Would Wine load the .dll.so's? Would it >reject them being in PE format and having the 'POSIX Layer' attribute set, >or could we hack on a patch to detect if Wine itself is running in said >layer, and load them if it is? Would that even *work*? And how about >detecting Winelib applications? It might get detected as a regular Windows >app, and ... uh-oh... (let's just say it isn't pretty) > >There are several obvious pros: You can test Wine almost fully under >Windows without mingling with Windows's native componets. This would allow >for better and faster compatability tests. We could also see what >"unknowns" exist in Interix -- Althought not nessessrarly useful to Wine >developers itself, it could mean a whole new generation of applications >which are half-Unix, half-Windows, if the right holes are found. > >I am sure this will spark a LOT of debate. > >_______________________________________________ >wine-users mailing list >wine-users(a)winehq.org >http://www.winehq.org/mailman/listinfo/wine-users Bear in mind that SFU won't install on XP Home or XP64. It seems to be XP Pro only. I haven't tried installing on the Vista Beta (either 32 or 64 bit). Geoff

March 27, 2006

Regression in wine made 2006/03/23

by Pavel Troller

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

March 27, 2006

Re: WINECFG: use directory harddiskvolume1 for mapping drive C instead of drive_c

by Alexandre Julliard

Hans Leidekker <hans(a)it.vu.nl> writes: > Any word on why this patch wasn't applied? There's a test marked todo_wine > by Stefan Leichter that demonstrates this behaviour. And here's the relevant > part of a relay log: QueryDosDevice needs to be fixed to return real device names instead of just reading the symlink. We can't require people to name their directories harddisk something. I'm working on it but it needs a bit more device infrastructure first. -- Alexandre Julliard julliard(a)winehq.org

March 26, 2006

Re: Alexandre Julliard : server: Class and global atoms should not be local to a window station.

by Alasdair Sinclair

Hi This patch breaks firefox-1.5 on fedora core 4 (x86-64). 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 wine: Unhandled page fault on write access to 0x0000001a at address 0x6033e436 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x0000001a in 32-bit code (0x6033e436). fixme:dbghelp:sffip_cb NIY on 'c:\builds\tinderbox\Fx-Mozilla1.8\WINNT_5.2_Depend\mozilla\xpcom\build\xpcom_core.pdb' Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0063 EIP:6033e436 ESP:7fa0f790 EBP:7fa0f7c0 EFLAGS:00010246( - 00 -RIZP1) EAX:00000001 EBX:7f5e866c ECX:00000000 EDX:7fa0f704 ESI:00000000 EDI:7fa0fd18 Stack dump: 0x7fa0f790: 0001002a 7f5c580a 0001002a 00000113 0x7fa0f7a0: 00000000 0000139c 7fca1cf9 7f5e866c 0x7fa0f7b0: 7fa0f7c0 7f5e866c 0001002a 7fa0fd18 0x7fa0f7c0: 7fa0f800 7f5c6490 6033e417 0001002a 0x7fa0f7d0: 00000113 00000000 0000139c 7e270598 0x7fa0f7e0: 7fa0f9ac 7fa0f824 7f595f80 00000113 0200: sel=1007 base=7fe6a000 limit=00001fff 32-bit rw- Backtrace: =>1 0x6033e436 in xpcom_core (+0x2e436) (0x6033e436) 2 0x7f5c6490 WINPROC_CallWndProc+0x70(hwnd=<register not in topmost frame>, wParam=0x0, lParam=0x139c) [/ppp/wine/wine-git/dlls /user/winproc.c:418] in user32 (0x7f5c6490) 3 0x7f5cd2de CallWindowProcW+0x12e(func=0x7f624c34, hwnd=0x1002a, msg=0x113, wParam=0x0, lParam=0x139c) [/ppp/wine/wine-git/dll s/user/winproc.c:3095] in user32 (0x7f5cd2de) 4 0x7f5926ff DispatchMessageW+0xaf(msg=0x7fa0fd18) [/ppp/wine/wine-git/dlls/user/message.c:3001] in user32 (0x7f5926ff) fixme:dbghelp:sffip_cb NIY on 'c:\builds\tinderbox\Fx-Mozilla1.8\WINNT_5.2_Depend\mozilla\browser\app\firefox.pdb' 5 0x0051866b in firefox (+0x11866b) (0x0051866b) 6 0x007fd417 in firefox (+0x3fd417) (0x007fd417) 7 0x00401012 in firefox (+0x1012) (0x00401012) 8 0x7fc8a00c start_process+0xec(arg=0x0) [/ppp/wine/wine-git/dlls/kernel/process.c:845] in kernel32 (0x7fc8a00c) 9 0xf7fcc4f7 wine_switch_to_stack+0x17 in libwine.so.1 (0xf7fcc4f7) Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 9873494ced8405113381266b4d99c2a9f3002cb1 > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=9873494ced8405113381266… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Wed Mar 22 22:13:40 2006 +0100 > > server: Class and global atoms should not be local to a window station. > > --- > > dlls/user/tests/winstation.c | 43 +++++++++++++++++++++++++++++++++++++++++- > server/atom.c | 27 ++++++++++++++++---------- > server/class.c | 24 ++++------------------- > 3 files changed, 62 insertions(+), 32 deletions(-) > > diff --git a/dlls/user/tests/winstation.c b/dlls/user/tests/winstation.c > index 4bc1941..a595718 100644 > --- a/dlls/user/tests/winstation.c > +++ b/dlls/user/tests/winstation.c

March 26, 2006

Re: Page fault xmlspy 2006 wine .9.10

by Grant Lewis

Eric Pouech wrote: > Grant Lewis wrote: >> It's repeatable. I can launch the progam fine but when I click in certain >> parts of the gui I generate the page fault and the program dies. >> >> wine: Unhandled page fault on write access to 0x0000001f at address >> 0x7d62d6 (th >> read 0009), starting debugger... >> WineDbg starting on pid 0x8 >> First chance exception: page fault on read access to 0x00000000 in 32-bit >> code ( >> 0x7ffa7292). > does the attached patch help ? > A+ I'll try incorporating your patch into the gentoo ebuild and report back if it helped my situation. Gramt

March 26, 2006

Re: WINECFG: use directory harddiskvolume1 for mapping drive C instead of drive_c

by Hans Leidekker

Any word on why this patch wasn't applied? There's a test marked todo_wine by Stefan Leichter that demonstrates this behaviour. And here's the relevant part of a relay log: 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "a:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=00000000 ret=0100503a 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "b:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=00000000 ret=0100503a 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "c:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=0000000c ret=0100503a 0009:Call ntdll._strlwr(7fb0f8c8 "..\\drive_c") ret=01005053 0009:Ret ntdll._strlwr() retval=7fb0f8c8 ret=01005053 0009:Call ntdll.strstr(7fb0f8c8 "..\\drive_c",01002638 "harddisk") ret=01005069 0009:Ret ntdll.strstr() retval=00000000 ret=01005069 0009:Call ntdll.strstr(7fb0f8c8 "..\\drive_c",01002630 "ramdisk") ret=0100507d 0009:Ret ntdll.strstr() retval=00000000 ret=0100507d 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "d:",7fb0f8c8,00000400) ret=0100503a ... I know this affects the IE7 and MSI 3.1 installer, but probably more. ------------------ I've seen installers from Microsoft call QueryDosDevice on the whole alphabet and search any returned object name for the substrings "harddisk" and "ramdisk". On Wine they normally won't find any and quit with the following error: "Unable to find a volume for file extraction" QueryDosDevice on Wine returns the filename pointed to by the drive link beneath the dosdevices directory. In a default Wine installation this is ../drive_c. So a simple fix for this problem is to use the a different name for that directory, for example the name used for the first harddisk in the NT object namespace: harddiskvolume1. -Hans Changelog Use directory harddiskvolume1 for mapping drive C instead of drive_c.

March 26, 2006

stir stir stir

by Mike Hearn

Deprived of patch-writing time lately I can do little more than cheer the team on. And of course, take pot-shots at our partners over the wall, the Windows team themselves ;) Hello there if you're reading this! In the comments of this anonymous MS employees blogs post (great reporting here huh) we can find this post by somebody who claims to be on an appcompat testing team: http://minimsft.blogspot.com/2006/03/vista-2007-fire-leadership-now.html#c1… in which the following totally astonishing claim is made: "Results: Client appcompat % hovering at <40% (GASP - INTERNAL INFO... better moderate this one out!!!!)" which is explained due to reduction of testing staff, loss of team morale and outsourcing of testing. Can it really be true that the Vista builds have such appallingly low application compatibility? Anybody who has access to Vista builds want to comment on this? Given they (now) have half a year to clean it up, does anybody want to take bets on what the score will be by the time it releases? I wonder what this number means (presumably that 40% of apps work perfectly out of the box), and I also wonder what our own appcompat score is. Wouldn't it be scary if Linux ends up more Windows compatible than Windows is! :) thanks -mike

March 26, 2006

Re: Wine/Interix -- The pros and cons.

by Steven Edwards

Hi, In short it wont work. In long see inline. On 3/24/06, Segin <segin2005(a)gmail.com> wrote: > Would Wine load the .dll.so's? Since Interix uses PE for it's native > format (running on Windows, duh), Would Wine load the .dll.so's? Would > it reject them being in PE format and having the 'POSIX Layer' attribute > set, or could we hack on a patch to detect if Wine itself is running in > said layer, and load them if it is? Would that even *work*? And how > about detecting Winelib applications? It might get detected as a regular > Windows app, and ... uh-oh... (let's just say it isn't pretty) Wine should still load its builtin libs first. Your going to need to add some configure magic to detect interix/SFU and get it building. The last time I tried I ran in to conflicts with headers. It seems what Microsoft has for basic types in the POSIX headers does not match what windows has. > There are several obvious pros: You can test Wine almost fully under > Windows without mingling with Windows's native componets. This would > allow for better and faster compatability tests. We could also see what > "unknowns" exist in Interix -- Althought not nessessrarly useful to Wine > developers itself, it could mean a whole new generation of applications > which are half-Unix, half-Windows, if the right holes are found. You can already test any of the pure Win32 Wine dlls if you do a mingw build. Trying to to a port is a good bit of work. A port to SFU has the same problems as a Cygwin port. Your going to have to implement support in ntdll and wineserver for get/setthreadcontext. For simple Win32 apps that can just be stubbed but then you have the harder task of implementing or working around the lack of send/recvmsg. I think there was a hack to emulate it for cygwin but I never got around to testing it so you might be able to come up with a creative solution that will work for both targets. My advice would be to get it working on cygwin first and then port to SFU. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

March 26, 2006

Speed demon: Mozilla 1.7.12 and Wine.

by Segin

This is possibly the best news the Wine development team has recieved since getting Solitare to run on Wine in 1994: Wine and Mozilla are *faster* than IE on native Windows, on the same harware. I am not joking you. I used to have a Windows partition until it was corrupted recently, and my "personalized" Google homepage comes up in 2.31 seconds in IE. Note that Windows is running native (not a VM). Mozilla 1.7.12 in Wine pulls up the same page in under a second. I will continue to test. The only thing that is missing is Java support, and most of us can live without that. It's nice to know that we are mopping the floor with the World's Worst Webbrowser.

March 25, 2006

Re: Page fault xmlspy 2006 wine .9.10

by Eric Pouech

Grant Lewis wrote: > It's repeatable. I can launch the progam fine but when I click in certain > parts of the gui I generate the page fault and the program dies. > > wine: Unhandled page fault on write access to 0x0000001f at address 0x7d62d6 > (th > read 0009), starting debugger... > WineDbg starting on pid 0x8 > First chance exception: page fault on read access to 0x00000000 in 32-bit > code ( > 0x7ffa7292). does the attached patch help ? A+ -- Eric Pouech

March 25, 2006

WGL_PBUFFER_LOST_ARB implementation

by Tomas Carnecky

This patch implements 'WGL_PBUFFER_LOST_ARB'. It creates a new field in 'X11DRV_PDEVICE' which is used to store flags (currently only one: X11DRV_FLAG_DAMAGED). This flag indicates that the drawable (PBuffer) is damaged and no longer valid. As soon as the x11 driver receives the GLX_DAMAGED event it calls X11DRV_GLX_Event() which then set the flag. wglQueryPbufferARB() uses ExtEscape() to retrieve this flag and can decide whether the PBuffer is lost or not. This patch depends on one I've sent earlier to the wine-patches mailing list: '[x11drv] Move x11drv ExtEscape() codes to one common header file.'. Please look through this patch and tell me if I've done something horribly wrong or missed an important aspect. I'm very new to wine and I don't know what I am allowed to touch and what not. tom

March 25, 2006

Re: Winetools -> wine doors

by Segin

Also note that most of Winetools prior usefullness was killed when we killed ~/.wine/config Dr J A Gow wrote: > Karl Lattimer wrote: > >> Fair point that it has been useful to you, it has been useful to me >> also. Here's what I see. >> >> * An over complicated bash script, with way too many difficult to >> maintain parts >> * An inflexible application, which can only have new applications added >> to it by the maintainer >> * A terrible confusing GUI >> >> My choice of words was strong I admit, but I think this application is >> ready to go to silicone heaven. > > > Your points are quite true. I was only really pointing out that something > that enables individuals to Get Work Done Quickly (however bad the tool > might be technically) is of considerable value. That, of course, does not > mean that the tool shouldn't be replaced when it starts to suffer from > 'bit-rot'. But let's not completely can it until a viable replacement is > available otherwise we could undermine the perceived 'usefulness' of Wine > when it comes to a necessary rush-job. > > I should add I don't use Winetools as a matter of course - I used it once > to get me out of a hole, and it did! > >> What I am proposing and indeed working on is; >> >> * An appdb integrated application manager >> * A clean UI which fits with gnome HIG >> * A flexible, expandable, small and simple application which is easily >> maintained but can do everything winetools does. > > > This sounds like an excellent idea. > >> >> Maybe nostalgia will keep some people using winetools, or trying to fix >> something which is broken. Or maybe a couple people could lend a hand >> with this and we could have something better ;) >> >> K, >> >> >> > > > >

March 25, 2006

Re: Wine/Interix -- The pros and cons.

by Kuba Ober

On Saturday 25 March 2006 14:04, you wrote: > I have hands-on experience with it. I know that if you get the > abandonware X11 server, XDeep/32, and symlink the xdeep40.exe file (i > think that's it) to /usr/X11R6/bin/X (/dev/fs/C/xdeep32/bin/xdeep40.exe > -> /usr/X11R6/bin/X) you can use startx... > > And by the way, I use NetBSD pkgsrc on Interix (which is a supported > platform per the NetBSD pkgsrc site.) Interesting! One only hopes it's not bait-and-switch on MS's side. Cheers, Kuba

March 25, 2006

Re: Winetools -> wine doors

by Karl Lattimer

On Sat, 2006-03-25 at 14:02 -0500, Segin wrote: > Also note that most of Winetools prior usefullness was killed when we > killed ~/.wine/config Now we rely on winereg? is that correct (I should know this ;) I've been making some steady progress today, managed to get CD auto detection working (from some freevo code) and I've added basic SAX parsing for package lists. I hope I can get a base shell working soon. I would love it if people would get involved, a few good coders can have SVN/trac access I'll work on opening up to the public soon. pygtk/pyxml/wine hackers/shell scripters very welcome. Some clarification i need is on how wine executes applications. AFAIK this is how it works. wine runs the wineserver and wine-pthread and when the application exits cleanly wineserver goes too, otherwise winedbg starts. I have code waiting for wine exit (similar to winetools) which currently works but I'd like to make sure i'm on the right track ;) I'd also like to know what is the best way to kill a wine process and when it should be killed (currently I'm waiting indefinitely for wine to exit, then waiting 5 minutes on the wineserver). When is the best time to use wineboot? What purpose does it serve, what can it break. Cheers, K,

March 25, 2006

Re: What happened to the Fedora packages?

by Kuba Ober

On Thursday 23 March 2006 19:07, Neal Gompa wrote: > I just decided to use the yum packages suggested earlier... and yes, it > fails, then crashes! anyway, thanks! You might be speaking chinese as well. Care to post actual messages? Being vague when asking for help is rude. Cheers, Kuba

March 25, 2006

Re: What happened to the Fedora packages?

by Kuba Ober

> Compiling WINE always crashes my computer, so I prefer to > use the RPMs... You'd better figure out why compilation crashes your computer. It might be a hardware or kernel problem. Anyway, you first have to get such compilations to run stably, only then try actually running wine. Software builds are good system stress tests (or turn out to be). Cheers, Kuba

March 25, 2006

Re: Wine/Interix -- The pros and cons.

by Kuba Ober

On Friday 24 March 2006 22:26, Segin wrote: > I was thinking about running Wine on Interix (the POSIX layer of > Microsoft's Services for Unix). There are a few apparent unknows: [. . .] IIRC the POSIX layer that M$ implemented was there just to get government contracts and it's supposedly not very useful for real development. Does anyone have some hands-on experience with it? Another thing is that you'd need an X server running on Windows to get anything graphical. Not that it's a problem, just an observation. Cheers, Kuba

March 25, 2006

Bug 4806 - CpuDetect.dll missing (need help)

by Tom Spear

When trying to load up various apps, users are having problems with wine causing the program to say that certain files are missing, even when run from within the program directory (where the file that is supposedly missing is).. The problem has been narrowed down to this patch: http://www.winehq.org/pipermail/wine-cvs/2006-January/020072.html ..It seems to be that wine thinks the header is bigger than the file to be read. Louis Lenders and Tony Lambregts have narrowed it down to one line, which commenting out causes the programs to work.. After they added some traces to the code, it appears that the st.st_size variable is correct but the header_size variable is incorrect.. My question is where is wine pulling the header size from to fill into that variable to have given it the value that it is getting? And is there a simple (as well as proper) solution for this? Tom

March 25, 2006