January 2009 - Wine-devel - list.winehq.org

Re: crypt32(4/4): Add a localized name for the TrustedPublisher store
by Alexandre Julliard 19 Jan '09

19 Jan '09

"Juan Lang" <juan.lang(a)gmail.com> writes: > Actually, this doesn't depend on the others. My mistake. It breaks the tests: ../../../tools/runtest -q -P wine -M crypt32.dll -T ../../.. -p crypt32_test.exe.so protectdata.c && touch protectdata.ok protectdata.c:200: Test failed: Description not empty make: *** [protectdata.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: [4/7] WineD3D: Put vertex shader duplication infrastructure in place
by Stefan Dösinger 19 Jan '09

19 Jan '09

Please don't apply this patch and the following ones yet. They break device::reset because they don't delete old gl shaders properly in this case. I'll try to get a fixed patch asap. Patches 1-3 should still be ok > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Stefan Dösinger > Sent: Monday, January 19, 2009 11:49 AM > To: wine-patches(a)winehq.org > Subject: [4/7] WineD3D: Put vertex shader duplication infrastructure in > place >

1 0

libmsi.a import library from wine, and header files available (entirely free software), available for python-win32 builds under msys+wine
by Luke Kenneth Casson Leighton 18 Jan '09

18 Jan '09

as part of building python2.5.2 under msys under wine on linux using mingw, i thought i'd try building _msi.pyd just for kicks. of course, that required having an msi.lib import library, and associated header files. so, purely as an experiment, i've documented the process by which it is possible to take wine 1.1.13 (current development release) source code, modify the header files for use with mingw, create a typelibrary (using dlltool) and then, surprise-surprise, _msi.pyd successfully builds. i say successfully builds: but then, running from _outside_ of a wineconsole cmd, doing this: /usr/local/bin/wine ./python.exe -c 'import _msi' succeeds. but if you do this: /usr/local/bin/wineconsole cmd c:/python2.5/bin/python.exde -c 'import _msi' you get an "access violation - no access to memory" blah blah to be honest, i don't care about that: this message is to let people know that it _is_ possible, and, if anyone is interested in e.g. adding -lmsi -lcabinet support to MinGW, here's where you can get the necessary crud: http://lkcl.net/msi.tgz if the wine team have any objections, if they believe this is a bad idea, please do say so :) l. p.s. if anyone would like to add a regression test to python called "test_msi.py" - or if they know of one that exists, i'd love to hear from you and try it out. outside of a wine cmd.exe of course :)

1 0

python regression tests - a monster hammer to keep wine "in check" :)
by Luke Kenneth Casson Leighton 18 Jan '09

18 Jan '09

folks, hi, i've started running the python regression tests under wine (using the build of python i've only just created) and have started filling in bugreports for the tests that fail, but some things occurred to me: 1) why am i the only person filling out the bugreports? :) 2) surely these regression tests would work equally as well under the python2.5.2.exe that you can get as part of the pre-prepared python win32 install that comes from python.org and activestate.com, you don't _need_ my wine-built version of python.exe 3) why am i considering rewriting the tests as c-code when they can just as well be left as python code? one of the bugs that's _really_ really important is: crlf conversion. the code in wine's msvcrt is completely borked. i demonstrated this by switching over to "native" msvcrt.dll, and nearly _all_ of the 12 tests that failed, all but the test_os.py ones miraculously succeeded. the majority of tests fail due to file corruption over writing \n and getting back \r\n, which is clearly bogus. _yes_ i'm aware of the difference between O_BINARY and O_TEXT, and it would seem that there's either a default setting which is wrong, or there's some runtime detection going on, or... just... _something_ :) but the behaviour of msvcrt wrt crlf is _definitely_ not right, as it stands, and as a result it completely screws any possibility for running python.exe under wine. completely. you can't have files that you write to, that are different from when they are read back. l.

3 7

Re: winejoystick.drv: Implement POV support
by Austin English 18 Jan '09

18 Jan '09

On Sat, Jan 17, 2009 at 6:01 AM, Vincent Pelletier <plr.vincent(a)gmail.com> wrote: > Note: > The code generating "discrete" values uses raw numbers istead of defined > values, because they exist only for 4 directions and (on the contrary of what > is advertised by MSDN) JOY_RETURNPOV also reports diagonal angles (verified > on vista 32 bits, with joytester.exe). I believe it's easier to see the > correlations between values this way. > > TODO: > JOYCAPS_POVCTS support, requiring some trigonometry functions and a joystick > reporting "analog" POV coordinates. > -- > Vincent Pelletier > > > > + case 16: /* Hat 0 X */ + case 17: /* Y */ + lpCaps->wCaps |= JOYCAPS_HASPOV | JOYCAPS_POV4DIR; + /* TODO: JOYCAPS_POVCTS handling */ + break; Minor, but shouldn't that be 'case 17: /* Hat 0 Y */' -- -Austin

2 1

http://bugs.winehq.org/show_bug.cgi?id=17003 - lseek with SEEK_END being ignored after fread
by Luke Kenneth Casson Leighton 18 Jan '09

18 Jan '09

this one's a loovely obscure one - fread makes lseek be ignored :) l.

1 0

Wine AppDB Test Results Submitted by Distribution @ 2009/01/18
by nn 18 Jan '09

18 Jan '09

Ubuntu users account for the majority of submitted test results to date. ------- Distribution / Number of Test Results Submitted ------- Ubuntu 17968 Gentoo 4135 Debian 2747 Open SUSE 1554 Fedora_Core 1334 SUSE 1011 fedoraproject 960 Mandrake 794 Arch_Linux 768 Slackware 678 Kubuntu 238 Mint_Linux 208 pclinuxos 206 FreeBSD 204 MacOSX 185 ubuntustudio 121 linuxfromscratch 113 CentOS 100 sabayonlinux 87 sidux 58 kanotix 46 slamd64 41 Red_Hat 41 gobolinux 39 mepis 38 pcbsd 37 zenwalk 33 pld-linux 29 na 25 uhulinux.hu 25 vectorlinux 24 Source_Mage 23 xandros 22 ultimalinux 20 Puppy_Linux 19 frugalware 19 mepis 17 pardus-linux.nl 16 KNOPPIX 15 pardus.treng 13 Kurumin_Linux 13 xubuntu 12 redflag-linuxenindex.php 12 pcbsd 12 slax 11 sam-linux 9 kalangolinux 9 elivecd 9 lunar-linux 8 dreamlinux.br 8 Alt_Linux 8 ubuntu-eee 7 64studio 6 skolelinux 5 remote-exploitbacktrack.html 5 freespire 5 wolvix 4 opensolaris 4 opensolaris 4 yoper 3 thinkgos 3 paldo 3 magiclinuxdrupal 3 linux-xp 3 linspire 3 damnsmalllinux 3 AGNULA-DeMuDi 3 tinyme.mypclinuxos 3 opengeu.intilinux 3 developers.sunsxde 3 pardus.treng 2 cdlinux.pl 2 asplinux.ru 2 Aurox_Linux 2 wiki.rpathwikirPath_Linux 2 ubuntusoftware.infoultimate 2 grml 2 arklinux 1 yeslinux 1 sun 1 realnetworks 1 pendrivelinux20080206usb-mcnlive-toronto 1 pendrivelinux 1 myah 1 linpus 1 linnexos.pl 1 kateos 1 foresightlinux 1 wiki.laptopgoFedora 1 linux.startcom 1 fluxbuntu 1 easys.gnulinux.de 1 blagblagblag 1 ------- Grand Total 34225 ------- Rough Stats Compiled from ( http://appdb.winehq.org/objectManager.php?sClass=distribution&sTitle=View%2… ) Stay connected to the people that matter most with a smarter inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox

1 0

stdin and stdout getting connected to the wrong things!
by Luke Kenneth Casson Leighton 18 Jan '09

18 Jan '09

http://bugs.winehq.org/show_bug.cgi?id=16968 this one's _really_ intriguing. i've been observing that occasionally, running python.exe e.g from /bin/sh.exe interactively shows... nothing. it's like, "dude, where's my car^H^H^Hinteractive python prompt?>>>" and the python developers are _really_ getting heavy at me for moving Py_Initialize() around and doing all sorts of weird shit like _assuming_ that the isatty(stdin) test has succeeded n stuff. well, i think what's happening - and this popen() test gives some clues - is that stdin and stdout are being connected to the xterm from which /usr/bin/wine was started... for a _brief_ period of time. after some unspecified time, they are no longer connected to the starting-process's stdin or stdout, but are connected to the correct places. but in many instances, that's far too late - a process should _never_ start up with its stdin and stdout connected to the wrong place in the first place! l.

1 0

python regression tests - a monster hammer to keep wine "in check" :)
by Dan Kegel 18 Jan '09

18 Jan '09

Luke wrote: > 1) why am i the only person filling out the bugreports? :) You got lucky and found a good test suite! If you put up a nice easy recipe, you'll probably get some help. > 2) surely these regression tests would work equally as well under the > python2.5.2.exe that you can get as part of the pre-prepared python > win32 install that comes from python.org and activestate.com, you > don't _need_ my wine-built version of python.exe Indeed. (For the curious, see http://docs.python.org/library/test.html ) > 3) why am i considering rewriting the tests as c-code when they can > just as well be left as python code? You only have to do that for the tests that fail. It's useful because a) it greatly reduces the size of the log a wine developer has to look at, and b) adding it to wine's test suite makes it much less likely to recur. I agree we should be running the Python tests routinely, but probably not as part of wine's "make test". - Dan

3 6

fgets followed by fread gives wrong results
by Luke Kenneth Casson Leighton 17 Jan '09

17 Jan '09

http://bugs.winehq.org/show_bug.cgi?id=16982 test case included, along with output shown from native msvcrt.dll run. this is _different_ from #16790 (but inter-related, as fgets is made up from lots of fgetc()s. the file pos (from ftell) is off by one, compared to msvcrt.dll On Sat, Jan 17, 2009 at 7:53 PM, Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> wrote: > give it a bit more time - there's another one (involving fgets > followed by fread) which i'm investigating, i'll have that one nailed > as a test case in a bit, am just about to add a test case to #16790

1 0