October 2005 - Wine-Devel - list.winehq.org

Re: KERNEL: force copying of DOS-style path into argv[0] of PE process

by Alex Villacís Lasso

Alexandre Julliard wrote: >Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > > > >>Sorry to disagree, but I have seen this behavior (fully qualified name >>in argv[0]) since MS-DOS and Windows 3.1. Even some old C tutorial books >>mention it in passing. I have also replicated this behavior from the >>command line (COMMAND.COM) in MS-Windows 98 in a DOS box, without using >>Explorer. My sample app prints out the argv[] array and it consistenly >>shows a fully qualified path to the executable in argv[0], even when run >>from a DOS box. >> >> > >It's OK to change argv[0] when started from a Unix shell, but not when >started from another Windows process. Your patch does it in all cases, >which is not correct. > > > Sounds reasonable. What is the proper way to tell apart the two cases?

Oct. 31, 2005

Re: killing wine dregs

by Walt Ogburn

Does wineserver -k not work for you? On Mon, 31 Oct 2005 wino(a)piments.com wrote: > > I took the system right down to the login console and still cant clean up. > > Do I really have to reboot as the only way to clean up this mess? > > This is taking windows emulation too far!! ;) > >

Oct. 31, 2005

Wine on Solaris?

by Thomas Tornblom

Greetings. I'm new to this forum, so bear with me... I'm trying o build 0.9 on Solaris 11 (nevada) and I'm running into some problems. The background is that I'm trying to run ComSoft, a win application to control the heatpump in my house. It uses serial comm, just plain 9600 bps, even parity. I tried to use the 20041104 version available on the Solaris 10 companion CD, but serial comm seems seriosuly broken on it, and I thought I'd better start with something more recent. I have added some missing sun-specific pieces from the 20041104 version as it was built by someone at Sun, and I have been able to build it, sort of. I'm running into problems when I try to start wine, where I get complaints about unresolved symbols, all of which are defined in the dll shared libraries. I'm puzzled by the naming of the shared libraries and I don't understand how they are spposed to be named and used. Take the kernel32 dll for instance. It is named /opt/sfw/lib/kernel32.dll.so, but during linking it is used as "-lkernel32", and at runtime no symbols are found. I'm trying to get in contact with the engineer at sun who built the version on the companion CD, but perhaps someone here can explain how it is supposed to work? Cheers, Thomas

Oct. 31, 2005

Re: The Holy Grail - Wine 0.9 - thanks to all

by Christian Costa

Lionel Ulmer wrote: >On Sun, Oct 30, 2005 at 12:46:13PM +0000, Christian Costa wrote: > > >>I've just taken a look at it again and it seems the patch only fixed the >>D3D7 API. >> >> > >Do not check the commit mail, but the patch itself: > >http://www.winehq.org/hypermail/wine-patches/2005/06/0103.html > >And you will see that the real patch fixes this issue. > > > Well, no. Antoine's patch fixed only the d3d7 light APIs. Old light APIs (light object + CreateLight method of direct3d object) were wrong. In fact when modifying that code to use d3d7, some part had been forgotten. My patch only finish the job by cleaning things up. Btw, I've just checked cvs commit and Antoine's patch seems to be commited entirely !?! Christian

Oct. 31, 2005

Re: KERNEL: force copying of DOS-style path into argv[0] of PE process

by Alexandre Julliard

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > Sorry to disagree, but I have seen this behavior (fully qualified name > in argv[0]) since MS-DOS and Windows 3.1. Even some old C tutorial books > mention it in passing. I have also replicated this behavior from the > command line (COMMAND.COM) in MS-Windows 98 in a DOS box, without using > Explorer. My sample app prints out the argv[] array and it consistenly > shows a fully qualified path to the executable in argv[0], even when run > from a DOS box. It's OK to change argv[0] when started from a Unix shell, but not when started from another Windows process. Your patch does it in all cases, which is not correct. -- Alexandre Julliard julliard(a)winehq.org

Oct. 31, 2005

Re: The Holy Grail - Wine 0.9 - thanks to all

by Lionel Ulmer

> Well, no. Antoine's patch fixed only the d3d7 light APIs. > Old light APIs (light object + CreateLight method of direct3d object) > were wrong. Ah must have been drunk when I got the CreateLight but report in the channel and compared Antoine's patch to my tree :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Oct. 31, 2005

Re: killing wine dregs

by wino＠piments.com

On Mon, 31 Oct 2005 20:10:12 +0100, <wino(a)piments.com> wrote: > I often have wine finish uncleanly or need to break in if it is > misbehaving , this leaves some processes lying around and often means > wine cannot be restarted correctly. > > I find killing it by hand labourious so I used the following command to > clean up and have now defined it as an alias to make life easier. > > > pgrep wine|while read p; do kill -9 $p ; done; > > It works nicely but just wondered if anyone would say OMG dont do that ! > > TIA. > > in fact it seems even kill -9 cant clean up some times. bash-3.00#killwine kill -9 10666 kill -9 10690 bash-3.00#killwine kill -9 10666 kill -9 10690 bash-3.00#killwine kill -9 10666 kill -9 10690 bash-3.00# bash-3.00#pgrep wine -l 10666 wineserver 10690 wine-preloader bash-3.00# I took the system right down to the login console and still cant clean up. Do I really have to reboot as the only way to clean up this mess? This is taking windows emulation too far!! ;)

Oct. 31, 2005

Re: KERNEL: force copying of DOS-style path into argv[0] of PE process (was: Re: Queries about some 'usability' points) - partially fixes #3542

by Uwe Bonnes

>>>>> "Molle" == Molle Bestefich <molle.bestefich(a)gmail.com> writes: ... Molle> Uhm. Explain to me how the above ratifies _not_ converting the Molle> Unix-style path to a Windows-style path before handing it to the Molle> app? We ARE trying to emulate Windows, are we not? Please verify your speculations with test cases (dll/kernel/tests/process.c) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Oct. 31, 2005

Re: KERNEL: force copying of DOS-style path into argv[0] of PE process

by Uwe Bonnes

>>>>> Alex writes: ... >> >> Alex> Sorry to disagree, but I have seen this behavior Alex> (fully qualified name in argv[0]) since MS-DOS and Alex> Windows 3.1. Even some old C tutorial books mention Alex> it in passing. I have also replicated this behavior Alex> from the command line (COMMAND.COM) in MS-Windows Alex> 98 in a DOS box, without using Explorer. My sample Alex> app prints out the argv[] array and it consistenly Alex> shows a fully qualified path to the executable in Alex> argv[0], even when run from a DOS box. Alex, can you please look at wine/dlls/kernel/test/process /* Test for Bug1330 to show that XP doesn't change '/' to '\\' in argv[0]*/ Perhaps you can add a test case for your observation... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Oct. 31, 2005

killing wine dregs

by wino＠piments.com

I often have wine finish uncleanly or need to break in if it is misbehaving , this leaves some processes lying around and often means wine cannot be restarted correctly. I find killing it by hand labourious so I used the following command to clean up and have now defined it as an alias to make life easier. pgrep wine|while read p; do kill -9 $p ; done; It works nicely but just wondered if anyone would say OMG dont do that ! TIA.

Oct. 31, 2005