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

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

Jan. 31, 2005

[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 Jan. 31, 2005

Jan. 31, 2005

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 Jan. 30, 2005

Jan. 30, 2005

-----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 Jan. 30, 2005

Jan. 30, 2005

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 Jan. 30, 2005

Jan. 30, 2005

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

RICHEDIT once again
by Krzysztof Foltman Jan. 30, 2005

Jan. 30, 2005

My rich text control is still far from even semi-complete, but I think too much is done to start over, so I'm releasing it today. The number one reason of its incompleteness is that I put more emphasis on making things work exactly like in the original than on implementing more functions. It's been neglected for weeks, and only recently I've fixed some old bugs and slowly started implementing the simplest parts of the RICHEDIT control API. I'm still not done with the basic stuff, like undo stack, so there is not much to hack on. On the other hand, it's likely I've made some bad decisions during design, and having someone experienced to look at that seemed to be a good idea to me. Some things look really tricky to implement with the current architecture, like the printing API (it will likely be an ugly hack, but I expect the same from the original, as screen formatting and print formatting may be very different). Some things just need time. I will probably need others' help to do the RTF parser. It's just way too much work. So, if anyone cares: http://foltman.com/richtext-20050130.tar.gz Compile using the recent-ish mingw (plus original SDK richedit header file). Have fun, Krzysztof

4 8

Re: KERNEL: stub implementation for ReadDirectoryChangesW
by Vincent Béron Jan. 30, 2005

Jan. 30, 2005

Le dim 30/01/2005 à 13:37, Hans Leidekker a écrit : > > This prevents a crash in Picasa2. > > -Hans > > Changelog: > Stub implementation for ReadDirectoryChangesW. You forgot to remove the stub entry in kernel32.spec and replace it by a line with proper argument types. Vincent

1 0

Fwd: Re: Q? system wide variables
by Oliver Stieber Jan. 30, 2005

Jan. 30, 2005

Thought I should send this to winedev as well, is it just me, or is the reply address set to the sender and not winedev? > > --- Mike Hearn <mh(a)codeweavers.com> wrote: > > Yes, the registry is fine though if you are going > to > > detect this at > > startup it may be worth making it volatile. > > > > I'm not sure it makes sense to have a config > option > > here. How many people > > will think to adjust it? > > > Well, initially I can't won't be able to detect the > value since I don't known of any other way that > talking to the video card and requesting one of it's > registers. (I've got the Matrox g400 code somewhere > on an old HDD written in djgcc for dos about 5 years > ago) Transgaming make this user configurable so I > shouldn't imagine it's an 'easy' task to detect the > top ten cards. > > It could also be handy for stubborn applications > when > I want to lie and don't care how slow the > application > runs (or if it slips into AGP instead of > on-videoboard > ram) you can get something for windows that fakes a > lot of directX functions so that you can play games > that must have pixelshaders 2.0 on older cards just > missing some effects. > > I would send the link, but I can't remember right > now > and I'm just off down the pub. > > I'll start by getting everthing to talk to the > registry and work on the volile bit when we have > some > detection code. > > > > > > > > > > ___________________________________________________________ > > ALL-NEW Yahoo! Messenger - all new features - even > more fun! http://uk.messenger.yahoo.com > ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

3 2

Q? system wide variables
by Oliver Stieber Jan. 30, 2005

Jan. 30, 2005

Hi, I need to track the 'fake' amount of video memory in total, allocated and left for Directx 9 and would like to track it across wine so that DDraw, DirectX, DxDiag and X11 driver can all sing from the same song sheet. What's the best place to do this? is the registry code fast enough or should I add a new function to the X11 driver so that I can request and release 'fake' video memory and make all other AvailableVideoMemory requests ask X11 driver? I would expect the use to be able to override by the initial amount, even if there's code that detects it since wine,X and openGL manage video memory differently to windows, direct draw and D3D. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

5 5

Re: small fix SafeArryDestroy
by Rob Shearman Jan. 30, 2005

Jan. 30, 2005

Rein Klazes wrote: >Hi, > >Makes WJChess, a French made chess game, accept moves. > >Changelog: > dlls/oleaut32 : safearray.c > SafeArrayDestroy() returns success when called with a NULL > pointer. > > It would be nice to have a test for this as there are already a large number of SafeArray tests. Rob

1 0

ole:register_ifstub couldn't get IPSFactory buffer for interface
by Uwe Bonnes Jan. 29, 2005

Jan. 29, 2005

Hallo, trying to install the the German TAX software "Steuersparerklaerung 2005" the Installshield installer runs into: err:ole:register_ifstub couldn't get IPSFactory buffer for interface {00000131-0000-0000-c000-000000000046} and aborts. The IRemUnknown implementation seems to be brand new from Robert as of this monday. Is there any fix to get around above problem? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 7

Re: MSVCRT: Re-implement *printf
by Aneurin Price Jan. 29, 2005

Jan. 29, 2005

Changelog: > Re-implement all *printf functions in msvcrt.dll, according to > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html… > > and descriptions of appropriate functions. > This should fix, among other things, bugs 321 and 2075. > Nobody has any comments about this?

3 3

Re: [shlwapi/tests/shreg] Tests question
by Juan Lang Jan. 29, 2005

Jan. 29, 2005

> What's the best approach in this? > - fix Wine (but what should be the correct returned buffer?) Definitely fix Wine. Hopefully there isn't an app that depends on one behavior under Windows 98, and a different one under Windows XP. It's perhaps less likely because Wine's implementation isn't correct in either case? Pick one of the versions to match, document the difference with other versions. If needed later someone can change the function to check at runtime which version of Windows is being emulated, and match the behavior accordingly. See e.g. http://source.winehq.org/source/dlls/kernel/process.c#L2800 for where this is done. --Juan __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

2 2

Slick build output
by Jason But Jan. 29, 2005

Jan. 29, 2005

Hello all, Not really related to the actual wine development but more to the make/build/install environment. Remembering the most wine users will not necessarily be developers we should consider improving the output of running (./configure && make) to make it more user friendly. Hopefully it should also be less confronting and confusing to non developers. I propose something similar to the way the Linux kernel currently compiles. The included patch changes make so that a regular make will produce much nicer output while for those die-hards who prefer the original output this can be achieved by executing make VERBOSE=yes I personally prefer the neater output even for development work, the compile output doesn't scroll off the screen as quickly and warnings/errors can be more easily spotted. This patch doesn't do the complete job, instead only produces output for the compile (gcc) stages. In fact, (make install) will produce no output at all! If people think this is a good idea, simple extensions will lead to complete output, just add the necessary $(NICE_ECHO) " whatever" to the proper places in each Make*.in file I am willing to do this if it is deemed to be good. Jason

8 10

Re: [IWineD3d + d3d9] bogus query implemetation
by Juan Lang Jan. 29, 2005

Jan. 29, 2005

Hi Oliver, +HRESULT WINAPI IWineD3DDeviceImpl_CreateQuery(IWineD3DDevice *iface, D3DQUERYTYPE Type, IWineD3DQuery** ppQuery){ + IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; + + if(NULL == ppQuery){ + /*Just a check to see if we support this type of query*/ + HRESULT hr = D3DERR_NOTAVAILABLE; + /*Lie and say everything is good (we can return ok fake data from a stub)*/ + switch(Type){ + case WINED3DQUERYTYPE_VCACHE: + hr = D3D_OK; + case WINED3DQUERYTYPE_RESOURCEMANAGER: + hr = D3D_OK; These are missing a break statement. Better style would be to take advantage of the fallthrough like so: + switch(Type){ + case WINED3DQUERYTYPE_VCACHE: + case WINED3DQUERYTYPE_RESOURCEMANAGER: (all the other WINED3DQUERYTYPE_ cases) + hr = D3D_OK; + break; +struct IWineD3DQueryImpl +{ + IWineD3DQueryVtbl *lpVtbl; + DWORD ref; /* Note: Ref counting not required */ + IWineD3DDeviceImpl *wineD3DDevice; + /* IWineD3DQuery fields */ + D3DQUERYTYPE type; + void *data; + int dataSize; + + +}; What's with the couple of blank lines in the struct declaration? Yeah, so I'm picky ;) +DWORD WINAPI IWineD3DQueryImpl_GetDataSize(IWineD3DQuery* iface){ + IWineD3DQueryImpl *This = (IWineD3DQueryImpl *)iface; + FIXME("(%p) : stub \n", This); + int dataSize = 0; + switch(This->type){ + case WINED3DQUERYTYPE_VCACHE: + dataSize = sizeof(D3DDEVINFO_VCACHE); + case WINED3DQUERYTYPE_RESOURCEMANAGER: Aren't these case statements missing a break statement too? --Juan __________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com

3 3

[AppDB] Beef up the Application Rating Guidelines
by Francois Gouget Jan. 29, 2005

Jan. 29, 2005

I feel that the current 'Maintainers Ratings System Help' is awfully vague and needs to be beefed up. So I'm attaching a proposal in which I tried to keep the original spirit but make things more precise. * First I'd like to rename this page from Maintainers Ratings System Help to Maintainer's Application Rating Guidelines - I added 'Application' to the title because that's what is being rated, not the maintainers. - I removed 'System' because it does not bring anything. - And I changed 'Help' to 'Guidelines' because this page does not juse tries to help maintainers give a random rating to an application, it tries to define which rating an application can have depending on how it runs. - Finally once the old ratnig system is removed we can remove "Maintainer's" since there will be only one left. * I've also reversed the order of the medals, because it seems a more logical progression and can simplify the explanations: in order to get a Silver medal you must pass all the criterias for a Bronze medal, plus some new ones. * I still feel there's a huge gap between 'Garbage' and 'Bronze' and that it would be interesting to have statistics about the percentage of applications that fail to install, and those that install but crash on startup, both cases which are included in the Garbage category along with those that install and start up but are still not usable. (Chocolate and Tin medals?) I'm attaching the full file as it's much easier to read than a diff. I'll send a diff to wine-patches once the final form has been reached. For reference the original can be found there: http://appdb.winehq.org/help/?topic=maintainer_ratings -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

2 1

[AppDB] Proposed Maintainer Guide
by Francois Gouget Jan. 29, 2005

Jan. 29, 2005

The Application Database is missing a description of the job of an Application Maintainer. So I cleaned up the Maintainer Guide I posted earlier and prepared it for integration into the Application Database site. I attached it to this email for review. Let me know if there is anything missing, things to change, etc. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

2 1

[shlwapi/tests/shreg] Tests question
by Paul Vriens Jan. 29, 2005

Jan. 29, 2005

Hi, I've been testing some of these test extensively and can make them pass on all the windows versions I have running. Doing this however means it breaks the wine test. An example is: /* * string grows during expanding * dwSize is larger then the size of part before the backslash but smaller then the expanded string * if the unexpanded string fits into the buffer it can get cut when expanded */ strcpy(buf, sEmptyBuffer); dwSize = sExpLen2 - 4; dwType = -1; dwRet = SHQueryValueExA( hKey, "Test3", NULL, &dwType, buf, &dwSize); ok( (0 == strcmp("", buf)) | (0 == strcmp(sEnvvar2, buf)), "Buffer should be the first part of the string (win98) or empty otherwise, it's (%s)\n", buf); Wine returns a part of the expanded string here: (ImARatherLongButIndeedNeededString\sub) So Wine doesn't do what either win98/winnt/win2k/winxp does (all latest version of the OS's). What's the best approach in this? - fix Wine (but what should be the correct returned buffer?) - extend the ok, by the returned buffer that Wine gives and effectively ignore the differences. Cheers, Paul.

1 0

Intent to package Winetools for Debian
by Scott Ritchie Jan. 29, 2005

Jan. 29, 2005

A user recently pointed out how hard it is to install winetools on Debian. Of course he's right, so I'm making a winetools debian package much like the wine package. I'll put it in the apt repository along with the regular wine packages when I'm done. Also, I'm thinking of putting winetools in the "recommends" section of the wine package, so it's installed alongside it by default. Any objections? Thanks, Scott Ritchie

3 2

Re: ptrace single-stepping change breaks Wine
by Eric Pouech Jan. 29, 2005

Jan. 29, 2005

> Btw, does wine ever _use_ PTRACE_SINGLESTEP for any of the things it does? > > If it does, then that woulc certainly explain why my "fix" made no > difference: my fix _only_ handles the case where the ptracer never > actually asks for single-stepping, and single-stepping was started > entirely by the program being run (ie by setting TF in eflags from within > the program itself). > > But if wine ends up using PTRACE_SINGESTEP because wine actually wants to > single-step over some instructions, then the kernel will set the PT_DTRACE > bit, and start tracing through signal handlers too. The way Wine doesn't > want.. wine mixes both approches, we have (to control what's generated inside the various exception) to ptrace from our NT-kernel-like process (the ptracer) to get the context of the exception. Restart from the ptracer is done with PTRACE_SINGLESTEP. (BTW: I also CC:ed wine-devel ML, that might be of interest to them too) A+

14 85

[Fwd: Wine-Wiki.org]
by Ivan Leo Puoti Jan. 28, 2005

Jan. 28, 2005

Forwarding in case someone cares about this. Ivan.

13 31

unicode "tables"
by Jonathan Wilson Jan. 28, 2005

Jan. 28, 2005

I remember some people talking about some kind of "unicode tables" that WINE has but that dont match with the MS implementation. What are the tables for? And what API call(s) are involved?

4 3

Re: MSVCRT: Re-implement *printf
by Juan Lang Jan. 28, 2005

Jan. 28, 2005

Hi Aneurin, > Nobody has any comments about this? Well, I held off thinking I'd give Alexandre a chance to chime in. As it's a large patch, I knew it could take a while. But since he hasn't.. My advice isn't going to be as specific as it has been in the past. You've obviously done a lot on this, and it looks like useful and well-done work. A couple tips to improve its chances then: 1. Write some test cases. For example, in the code you comment: /* Further size specifiers are swallowed; this isn't specified, but was determined from testing. * Thus "ll", for example, does not mean "long long" (I64 should be used instead), but "long" */ Writing a test case that checks this is better than commenting the code, because it really ensures future changes won't break it. Generally, test cases help demonstrate the correctness of the patch (and the incorrectness of what's already there.) Once you're written one, they get pretty simple to do. 2. I'm troubled a bit by the memory allocation. It seems as though it should be possible to output characters or formatted output one at a time, keeping track of where you are in the format string and how many characters you are allowed to output. I realize it's a bit difficult since you may be outputting to either a file pointer or to a buffer, but modulo that complication you should be able to avoid allocating temporary buffers. I know, somewhere in the FAQ it says something about correctness before efficiency, but this bit of inefficiency seems pretty avoidable ;) Hope that helps, --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: v2.: [IWineD3d + d3d9] bogus query implemetation
by Juan Lang Jan. 28, 2005

Jan. 28, 2005

Hi again Oliver, > this should be better. Yeah, but this function is still borked, I think: +HRESULT WINAPI IWineD3DDeviceImpl_CreateQuery(IWineD3DDevice *iface, D3DQUERYTYPE Type, IWineD3DQuery** ppQuery){ + IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; + + if(NULL == ppQuery){ + /*Just a check to see if we support this type of query*/ + HRESULT hr = D3DERR_NOTAVAILABLE; + /*Lie and say everything is good (we can return ok fake data from a stub)*/ + switch(Type){ + case WINED3DQUERYTYPE_VCACHE: + hr = D3D_OK; + case WINED3DQUERYTYPE_RESOURCEMANAGER: + hr = D3D_OK; (a bunch more) + default: + FIXME("(%p) Unhandled query type %d\n",This , Type); + } Do you mean to print a fixme for every one? If so, why not just do it once before or after the switch? Or if you don't, something like this would be better: + switch(Type){ + case WINED3DQUERYTYPE_VCACHE: + case WINED3DQUERYTYPE_RESOURCEMANAGER: (all the other supported ones) + hr = D3D_OK; + break; + default: + FIXME("(%p) Unhandled query type %d\n",This , Type); + } Notice the added break. Also, for conciseness, I wouldn't duplicate the hr = D3D_OK assignment for each supported type; I'd just let all the supported ones fall through to one assignment statement, like I show here. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

1 0

Can winedbg --auto backtrace all threads?
by Michael Ost Jan. 28, 2005

Jan. 28, 2005

Is there a way to have winedbg --auto do a backtrace of all the threads in an app at exception time? In order to help track down sporadic runtime crashes in our testing process, I have turned on winedbg --auto when wine handles exceptions via the AeDebug registry entry. This is working pretty well except that often winedbg does a backtrace on a thread that I know is not the problem. If I could see a backtrace of all the threads --- lots of data, I know --- the tool might be more useful. Is this already possible? How about advisable %) ? Or must I patch winedbg to do it? Sometimes winedbg appears to hang when handling the exception, or at least doesn't print out any information. When could this happen? Is there something I could do to improve winedbg's chances of working? Cheers... mo PS: our system is using wine-20040914

3 6