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

[d3d9/device.c] IDirect3DDevice9Impl_GetDepthStencilSurface problem
by Paul Vriens 31 Jan '05

31 Jan '05

Hi, while trying to run a demo-app, I had a 'crash' I have the following (part of a) trace: trace:d3d:IDirect3DDevice9Impl_GetDepthStencilSurface (0x77e3d028)->returning ((nil)) default is stencilbuffer=((nil)) trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x499db0cd trace:seh:EXC_RtlRaiseException info[0]=00000001 trace:seh:EXC_RtlRaiseException info[1]=00000004 trace:seh:EXC_RtlRaiseException eax=00000004 ebx=499e232c ecx=00000000 edx=00000001 esi=77e3d028 edi=77ec8318 trace:seh:EXC_RtlRaiseException ebp=70ecf5ac esp=70ecf5a0 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00210202 This is because IDirect3DSurface9Impl_AddRef is called with a NULL parameter. In d3d8/device.c this is checked in d3d9/device.c it isn't. The demo-app get's a bit further with this patch/hack, but I don't know if it's correct (or if it is correct in d3d8). Comments ? Cheers, Paul.

1 0

Help on Wine
by Katia Maculan 31 Jan '05

31 Jan '05

Hello, In the last few days I executed some tests to understand a segmentation fault problem in my pcsdll library working with WineLib in RedHat 9. I created: - A little library pcsdll exporting a function that calls the TlsAlloc function - A little executable pcsmon that calls the exported library pcsdll function and creates a window Linking the library with the command g++ -m32 -march=pentium-mmx -mcpu=i686 -g -shared -Wl,-soname=pcsdll.so ...... when the pcsmon calls the library function the library obtains a segmentation fault in calling TlsAlloc function. Do you have any idea about what I miss? Regards Katia PS: I'm using wine 20050111 version -- Katia Maculan Developer ISIS Papyrus Italy Srl Tel: (+39) 0125 6455400 Fax: (+39) 0125 6455150 E-mail: katia.maculan(a)isis-papyrus.com Info: info(a)isis-papyrus.com Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com

2 1

Re: [wined3d] GUIDS for everything.
by Alexandre Julliard 31 Jan '05

31 Jan '05

Oliver Stieber <oliver_stieber(a)yahoo.co.uk> writes: > Hi, this patch provides guids for all the wined3d > interfaces. There not needed right now, but some > patches I'll be sending in depend on them. I don't think you want to add wined3d GUIDs to dxguid, they don't exist in the Windows one. IMO they should remain purely internal to wined3d and d3d8/d3d9. -- Alexandre Julliard julliard(a)winehq.org

1 0

Xnews regression from update region handling
by Rein Klazes 31 Jan '05

31 Jan '05

Alexandre, After the update region handling moved to the server, Xnews gets in an endless loop when the windows with news groups is scrolled. The endless loop is in user/painting.c. Calling sequence is ScrollWindowEx(... SW_ERASE|SW_INVALIDATE)-> RedrawWindow(..., RDW_INVALIDATE|RDW_ERASE|RDW_ERASENOW)-> erase_now() In erase_now() the aptly coded endless loop is never broken out, and loops on the same window over and over. Before the change this was coded quite differently (traversing the window's child tree) and could not loop indefinitely. I am quite stuck what should be the reason why the loop is expected to end in the first place. Perhaps you want to have a look. Xnews can be downloaded from all over the net, for example: http://xnews.newsguy.com/release/xnews.zip Unzip it in a directory of your choice; run xnews.exe; enter the host name of a news server; confirm that you want to download the list of newsgroups; you get a window with newsgroups, try to scroll down the list. Rein.

2 1

Re: winmm: another round for unicode migration
by Alexandre Julliard 31 Jan '05

31 Jan '05

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > this patch moves (almost) the rest of winmm to handle correctly the MM > drivers as unicode drivers (for the 32 bit part) It doesn't build, you probably forgot to include the header changes. -- Alexandre Julliard julliard(a)winehq.org

1 0

MAPI32.dll.so - how to use in linux programs?
by Luke Kenneth Casson Leighton 31 Jan '05

31 Jan '05

[please cc to this address lkcl(a)lkcl.net, thank you!] hi, i am in the process of decoding mapi for an exchange 5.5 client/server project. i have got to the point where i can send (with a test program) and receive (in a test server) MAPI data. i noticed that Wine has a mapi32.dll.so. i was therefore wondering: could someone kindly point me in the direction of a stand-alone example program plus example Makefile(.am?) which i can cut/paste which will show me how to use mapi32.dll.so? the test program relies on a test loader program, so i can't find a "int main (char *argv[], int argc)" anywhere nor is it obvious what's going on. pointers to any existing simple usage documentation more than sufficient. any information and assistance greatly appreciated: in the mean-time i will keep blatting out hard-coded packets... l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

Re: SHLWAPI: implement PathIsValidChar{A,W}
by Juan Lang 31 Jan '05

31 Jan '05

Hi Hans, it looks like from values 0x7e onward the character class is always PATH_CHAR_CLASS_OTHER_VALID. If you like, for clarity you can fill in the value through 0x7f, but having a lookup table beyond this isn't necessary. Also, that means the data type can be unsigned char, not DWORD. And, it looks like the return value isn't consistent: +static BOOL WINAPI PathIsValidCharAW( unsigned char c, DWORD class ) +{ + return class & SHELL_charclass[c]; +} Here you mask class with the value in the table.. +BOOL WINAPI PathIsValidCharA( char c, DWORD class ) +{ + return PathIsValidCharAW( (unsigned char)c, class ); +} and again here, implicitly.. +BOOL WINAPI PathIsValidCharW( WCHAR c, DWORD class ) +{ + if (c > 0xff) return PATH_CHAR_CLASS_OTHER_VALID; + return PathIsValidCharAW( (unsigned char)c, class ); +} But for values of c greater than 0xff, you do not mask. This may be deliberate, I don't know, but it doesn't look correct. --Juan p.s. Have you added me to your spam list yet? ;) __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

2 1

Q: porting driver for USB scanner - where to start?
by Heiko Nardmann 31 Jan '05

31 Jan '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I want to write a linux driver for my USB scanner which is currently not yet supported by sane. So I wonder where to start; where do I find detailed information about the Windows driver interface, esp. for USB scanners. I want to know which interface a driver has to offer to Windows and which functionality the API has to offer. Thanks in advance for any help. - -- Heiko Nardmann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB5kmfpm53PRScYygRAh08AJ9oT68jQ0TKuikBFgJN1HG9EqjW2gCfbk9B Tndu1Nin8Z6DZQ/yg3+GEjc= =Dvvb -----END PGP SIGNATURE-----

5 4

some benchmark results
by Brian Vincent 31 Jan '05

31 Jan '05

I found an interesting program today and took it for a spin. I'm sure someone smarter than me can decipher this and get more out of it. It's called PerformanceTest v5.0 (build 1017) and it does benchmarks on lots of different things. I didn't look into what, if any of this stuff depends on Win32. For all I know it's written in assembly. A quick look at the results seems to point at lots of Win32 stuff. You can download it from: http://www.softpedia.com/get/System/Benchmarks/PerformanceTest.shtml The installer runs fine under Wine. I wasn't able to run all the tests, but here's what I got results for on Wine (Fedora Core 3) and WinXP on the same hardware: CPU (nothing too interesting here): Windows Wine Integer math 201.5 209 MOps/sec Floating point 210.9 210.4 MOps/sec MMX 177.1 178.4 Million matrices/sec SSE/3DNow 132.6 136.8 Million matrices/sec Compression 1548.0 1634.8 KBytes/sec Encryption 7.2 7.0 MBytes/sec Image rotation 138.8 139.9 rotations/sec Random string sorting 362.2 355.8 thousand strings/sec CPU Mark 321.2 328.5 "composite score" ----------- 2D (interesting, but probably not news) Windows Wine Lines 75.8 39.5 thousand lines/sec Filled rectangles 39.2 19.1 thousand images/sec Unfilled shapes 26.1 8.7 thousand shapes/sec Fonts (won't run, RichEdit20 problem, native not tried) GUI 124.3 22.4 ops/second ----------- 3D (won't run to completion on Wine, I believe it's DX7-based) Simple 65.2 Medium 97.8 Complex 37.1 ----------- Memory (interesting) Windows Wine Allocate small block 676.5 248.8 MBytes/sec Read cached 1124.4 1132.6 MBytes/sec Read uncached 912.7 965.4 MBytes/sec Write 474.3 446.5 MBytes/sec Memory Mark 310.8 274.9 "composite score" ----------- Disk Windows Wine Sequential read 19.9 18.1 MBytes/sec Sequential write 12.5 14.4 MBytes/sec Random seek 2.2 3.2 MBytes/sec Disk Mark 91.3 94.1 "composite score" ----------- CD Read 1.1 1.2 MBytes/sec CD Mark 54.3 58.5 "composite score" I'm very impressed the 2D GUI runs through to completion. If you just run one test, give that a try. The system is a Celeron 2.2GHz laptop, SiS chipset for graphics, 256MB RAM. Total "Passmark" rating on XP was 185.8. Anything stand out to anyone? Anyone have any insights into the results? As far as an intepretation goes, seems fairly obvious to me and about what you'd expect.. apps with heavy CPU are comparable to Windows, 2D and 3D apps will suffer a big performance hit, and apps requiring heavy IO (memory, disk) might even get a small performance boost under Wine (because of Linux?) -Brian

2 1

Wine packages, universe maintainence, and myself
by Scott Ritchie 30 Jan '05

30 Jan '05

Hello, I met some of you on IRC the other night. I am currently the Debian and Ubuntu packager for the Wine project. The "official" Debian maintainer hasn't been updating the packages and refuses to turn them over to me, so we've setup our own apt repository at winehq.org. The packages have been tested a lot, and are also in the Ubuntu backports project working fine. I was wondering what it would take to make them the ones that sit on Ubuntu's repository, rather than the (very old) Debian unstable ones, and from what I heard on IRC it seems like this is a rather doable thing for Ubuntu as we don't have to worry about Debian politics so much. Hence, I am writing this email. I'd be willing to maintain the Wine packages for Ubuntu, as well as related ones such as winetools. There's other work for me to do as well, but I suppose the first step is to coordinate things in here and make this happen. There's quite a bit on my todo list for the moment -Documentation is a seemingly never-ending task, both for man pages and packaging guidelines and such. -The Wine documentation also needs to be moved into the right places. I was recently given a very helpful tip on IRC about making Wine's User Guide work with standard freedesktop.org help interfaces, and I'll be committing the patch upstream shortly. -Tweaking the wine package to get it a bit more right is also important. I've got a bunch of little changes I need to make for the next release written up on my penboard at the moment. Hopefully soon I can start erasing them. -Updating the Wine User Guide itself. I've already got chapter 1, the introduction, finished. Obviously, this is a good thing to do. -Updating the Wine web site to make things easier (example is this page: http://www.winehq.org/site/download-deb ). That site may undergo a slight redesign in the future too. -I've got a special project I've been trying for a while involving porting Miranda Instant Messenger with Winelib. In theory, I could convert it into an Ubuntu package that runs on all arches with the Wine package installed, even though Miranda is a windows program. If this becomes easy it represents an amazingly huge step in application compatibility - it won't be long before we start seeing other OSS apps like DC++ or FileZilla coming into Ubuntu packages. Writing a howto guide for this based on my experience is part of this goal. -The Winelib documentation needs updating as well. I plan on using my experience trying to port Miranda IM to help it out. -Winetools, a useful program for running Wine, also needs packaging. I've got it almost finished at this point, although I need some help with some issues I've been having. More on this in IRC. As for the Wine package itself, the current versions of the Wine and Winetools packages are in my webspace, here: deb http://tuzakey.com/~scott/apt binary/ deb-src http://tuzakey.com/~scott/apt source/ The Wine package at first glance seems a bit different from some Debian standards, for various reasons. First off, even though Wine has some seemingly shared libraries, I haven't split them off. This is because only wine binaries can really use them, and they need the latest version anyway. Both windows apps called with Wine and winelib apps still need to be handled by the same wineserver (in case they message eachother, amid other reasons), and so they are both completely dependent on the Wine binaries anyway. Furthermore, since it's the same wineserver coordinating everything on a system, it needs to have the same library in use - since it's basically impossible to get use out of more than one libwine.so.x in a system, it makes little sense to support this. Secondly, Wine, not being an emulator, has some rather important differences between architectures. Wine really does need 3 different packages for the 3 different Ubuntu arches, as they each have some challenges. The i386 one is the simplest, and is basically standard Wine. The PPC arch can only run winelib apps, so it may need some trimming down and added documentation to prevent confusion. The 64 bit version of Wine represents the most interesting challenge, as Wine will still need the old 32 bit libraries to run 32 bit Windows applications. According to forum posts I've read, Wine packages not currently doing this easily is actually a blocker for some users in switching to 64 bit Ubuntu. Wine has some rather unique things which make it harder to maintain. -Arch issues, like mentioned above -PAX issues will inevitably come up again. This was an issue that came up before, although with Ubuntu using the latest Wine it will certainly be an easier one to tackle. -Until Wine hits a stable release, which seems to be perpetually six months away, Wine is updated monthly. This means an old and possibly unstable version of Wine will perpetually end up in Universe, unless we backport it. This may or may not be a problem from the User's perspective. Either way, I'll make the latest available at winehq.org. Clearly the best long term solution is to move to a more stable Wine release - I've been doing my part to help clear our 0.9 blocker bugs like the lack of documentation, but I can't do much for core Wine development other than cheer on my compatriots. We may want to have an entirely new applications menu for Wine. I envision having Wine installed and then having it create a new folder Applications->Wine, which will contain the Winecfg program labeled "Configure Wine" as well as a near empty start menu with Wine's shipped winelib Notepad program. When other windows programs get installed, they can be put in the Wine start menu there. The PPC arch may have no real need of start menu, though. We can run winelib apps on ppc, such as the hypothetical Miranda-IM package, but it might make sense to put that somewhere other than Wine's start menu (such as Applications->Internet) In fact, we may want to have packaged winelib apps specifically not go in the Wine folder for all arches, even arches that support a Wine start menu. I guess I should make a page for myself on the Ubuntu wiki. I'll likely put a huge todo list for myself up there as well, if for no other reason than to remind me of what I still want to do. I really like what's going on with Ubuntu. Most encouraging are emails I get like the following: ----------------- Dear Scott, I am using your wine packages from: deb http://wine.sourceforge.net/apt/ binary/ deb-src http://wine.sourceforge.net/apt/ source/ and it's just great! Thank you! It would be way cool if your packages could be the official Debian ones. I sincerely hope that some solution can be found, so that it can happen. Best regards, Silvestre ----------------- I also had a man message me on AIM thanking me profusely for the Wine packages. Apparently he had won several hundred dollars using a Windows poker program via Wine. The ability of Wine to put usable icons on the desktop really impresses users, and I really look forward to the day when we can have a usable start menu too. Anyway, I'd appreciate feedback and thoughts about this, as well as help with my package. Meet me in IRC, I'm YokoZar. Thanks, Scott Ritchie

6 6