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

Re: advpack: Open the INF file if the RSC_FLAG_INF flag is specified
by Alexandre Julliard 29 Mar '06

29 Mar '06

"James Hawkins" <truiken(a)gmail.com> writes: > @@ -72,10 +72,7 @@ static void test_RunSetupCommand() > /* try to run an exe with the RSC_FLAG_INF flag */ > hexe = (HANDLE)0xdeadbeef; > hr = pRunSetupCommand(NULL, "winver.exe", "Install", "c:\\windows\\system32", "Title", &hexe, RSC_FLAG_INF, NULL); > - todo_wine > - { > - ok(hr == SPAPI_E_WRONG_INF_STYLE, "Expected SPAPI_E_WRONG_INF_STYLE, got %ld\n", hr); > - } > + ok(hr & SPAPI_E_EXPECTED_SECTION_NAME, "Expected a setupapi error, got %ld\n", hr); This test doesn't make sense. If you want to test certain bits you have to write that explicitly, not pick some random constant that happens to have the right value. And in any case a simple AND won't do what you want. -- Alexandre Julliard julliard(a)winehq.org

1 0

Debugging X errors?
by Dan Kegel 28 Mar '06

28 Mar '06

OK, I've had it. The X errors I'm running into are keeping me from getting work done. They might be due to bugs in my X server (ubuntu 05.10), but while I wait for the next release of ubuntu, maybe I could try to track them down anyway. It looks like the procedure for diagnosing X errors such as X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0x0 Serial number of failed request: 468 Current serial number in output stream: 470 in Wine is to do WINEDEBUG=+synchronous export WINEDEBUG and then use winedbg to run the apps, and get a backtrace when the error occurs. I'll try that. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 4

Re: Russian translation for uninstall application
by Dmitry Timoshkov 28 Mar '06

28 Mar '06

"Anatoly A. Kazantsev" <jim-crow(a)rambler.ru> wrote: > + * Uninstaller (Russain Resources) Please fix the above typo and the translation of the word "registry" to match the commonly used russian word and resend the patch. -- Dmitry.

1 0

I have a complaint about the website
by Philip V. Neves 28 Mar '06

28 Mar '06

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.

7 8

Re: setupapi: Test loading an exe from the system directory with SetupOpenInfFile
by Alexandre Julliard 28 Mar '06

28 Mar '06

"James Hawkins" <truiken(a)gmail.com> writes: > All the handling is in place for this to (mostly) work in > SetupOpenInfFileW. We call > CreateFile("c:\\windows\\system32\\winver.exe", ..., > OPEN_EXISTING...), but that fails, returning INVALID_HANDLE_VALUE. > winver.exe is in drive_c/windows/system32 as a symlink to the > installed winver.exe.so. Should a call to CreateFile on a symlink > fail? If the symlink is broken, yes. Note that it's no longer supposed to be a symlink, you should probably remove it and re-run wineprefixcreate. That said, I'm not quite sure why you'd want to open an exe with SetupOpenInfFile... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: Fix SIGTRAP handling
by Petr Tesarik 28 Mar '06

28 Mar '06

2 3

What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()
by Tomas Carnecky 28 Mar '06

28 Mar '06

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? tom

4 7

Winetools -> wine doors
by penna＠bb.com.br 28 Mar '06

28 Mar '06

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 ---------------------------------------------------------

2 1

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()
by Tom Spear (Dustin Booker, Dustin Navea) 27 Mar '06

27 Mar '06

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

1 0

Re: ntdll: Fix SIGTRAP handling
by Petr Tesarik 27 Mar '06

27 Mar '06

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

3 3