Re: DInput mouse - where to go from here?
On Thu, Sep 27, 2007 at 04:48:23AM +, L. Rahyen wrote: On Thursday September 27 2007 04:07, Vitaliy Margolen wrote: The point I'm trying to make is: can we once put our right ways of doing things aside and fix something that never worked before? And fix it _for good_! I strongly agree here with Vitaliy. Personally I think that using evdev for this purpose IS the right way. Yes it will not work with remote X but Windows doesn't support this too (as far as I know at least). WINE purpose is to conform with Windows behavior. Therefore use of evdev will be correct. Even if above isn't true (I think it is) full support of remote X by dinput component isn't something useful for about 100% of users anyway. Of course everything above is just my opinion. on the other hand what is the use of playing a game over a remote machine? or are there apps, that suffer from this too? i can only figure out two things: - running a game server (unlikely one uses a direct X session - maybe only for games that need a client to configure the server) - play multiplayer games on one machine exporting it to the network (i doubt many do this - excepcially with windows games; it is more likely the other way around: host a linux game to a buddy with a windows notebook) one other concern i have is compatibility with other platforms. wine runs more or less fine at least on freebsd and osx - and others. so we keep the old code around, right? in general i would like to point out, that we have already similar stuff going on with the joystick drivers. the /dev/js joystick was/is(?) not useable for serious sims, due to its dead zone coming from somewhere in the kernel. so the /dev/input option is there - linux only i asume - which works great. so if the evdev path is a choice one can choose at compile time or even by config: go for it! even if unofficial - the gamers out there are used to hack stuff into wine to make their favourite games work _at_once_ after patches or after release - no matter if they break windows comptibility or other in their wine instance. -- cu pgp9k6fetU7tY.pgp Description: PGP signature
Re: [5/5] WineD3D: Add sincos support to arb shaders
Am Donnerstag, 27. September 2007 02:57:01 schrieb Ivan Gyurdiev: Aren't most of these 2.0 and 3.0 instructions ? What's the goal of adding them to ARB - you won't be able to implement full 2.0/3.0 support in ARB. We can implement 2.0(but not 2.a/b). Whenever it's easy to do, I'm adding 3.0-Specific behavior too. The reason is that GLSL is a bloody pain on MacOS, with ARB I can bypass many abstraction layers that have a huge number of software fallback pitfalls. signature.asc Description: This is a digitally signed message part.
Re: Total bidi regression
Maarten Lankhorst wrote: I may have slightly misunderstood those flags then. I was under the impression that the FORCE flags would be similar to LRO/RLO. The only thing that behaves like LRO and RLO are LRO and RLO. Believe you me, no one was more surprised than me when I found out that Windows actually respected them - they are as far away from an end user's experience as you might get (though useful, if you know about them). The Unicode algorithm keeps talking about setting the paragraph direction based on the first strong direction character in the paragraph (P2). As nice as that may have sound to the people drafting it, it only sort of works in real life. Either way, Window's BiDi doesn't work that way. The paragraph direction is set explicitly by the calling program (or, failing that, by the HDC, or, failing that, by an EXT_STYLE in the Window, you get the picture). This means the end of section 3.3.1, instructing implementors to ignore P2 and P3 in case of higher-level protocol apply here. Instead, the paragraph direction is explicitly passed to BIDI_Reorder through the dwWineGCP_Flags argument. Instead they are probably more like LRE/RLE. It's better to say that LRE and RLE allows one to switch paragraph direction for a specific part of the paragraph. In other words, LRE/RLE are like the paragraph direction, not vice versa. If that is a real problem I will send in a patch. If? I would still rather prefer a real bidi implementation, so that selecting and deleting characters would work properly. Lost you there completely. What do you mean by selecting and deleting? If you mean a BiDi editor, I think you have the tasks confused. Reordering characters in order to get them out on screen for printing has very little to do with string editing. It's one minor small step to start with. Bidi editing is a lot more complex. To my defense, there was no real clarification for them in the source. The comments in the code used the same terminology used by Annex 9. The parameters were passed almost directly from the inputs in BIDI_Reorder to ICU's input functions, where they are documented in the ICU documentation. These parameters were also received, pretty directly, from ExtTextOut, again, where they are documented in MSDN. To my eyes, this is the level of documentation any Wine hacker should need. I don't believe code comments should start explaining algorithms, particularly algorithms implemented by a library and documented in an international standard. And I should warn you that edit control is several magnitudes more complicated. Questions such as cursor position when the cursor is between two letters that are, after reordering (i.e. - on display) not adjacent, what happens if a given cursor location is clicked which has two possible logical locations, and what to do if the user then clicks del or types a letter in an RTL or an LTR language. Editing is COMPLEX, and the road is not paved and documented. Matti Alluche wrote a document once that gives specifications for BiDi editing, but after Mozilla implemented it, I whole heartedly recommend that you avoid it. Your best course of action is to find out what Windows does for its edit control and copy that. Cheers, Maarten Shachar
Re: DInput mouse - where to go from here?
Am Donnerstag, 27. September 2007 08:04:30 schrieb Christoph Frick: On Thu, Sep 27, 2007 at 04:48:23AM +, L. Rahyen wrote: On Thursday September 27 2007 04:07, Vitaliy Margolen wrote: The point I'm trying to make is: can we once put our right ways of doing things aside and fix something that never worked before? And fix it _for good_! so if the evdev path is a choice one can choose at compile time or even by config: go for it! even if unofficial - the gamers out there are used to hack stuff into wine to make their favourite games work _at_once_ after patches or after release - no matter if they break windows comptibility or other in their wine instance. You have my vote on an evdev dinput backend too, however, we get some problems which the X server used to solve for us: 1) Multiple Mice. If there are 2 mouse devices, the X server manages them and combines them to one core pointer. These configurations are pretty common, for example on laptops with touchpad + usb mouse. 2) Different devices: An USB mouse creates a /dev/input/eventX node, but other devices, like my synaptics touchpad do not. In the worst case we need a driver for each mouse type, USB, serial, PS2, Synaptics, busmouse, logitech, ... 3) Other OSes: This was mentioned already, but I wanted to add that the problem seems X11-only. MacOS reports relative mouse movements like Windows does, so a quartz driver will not have this issue. Perhaps the evdev reading should be implemented in winex11.drv? I think as a first step, we should ask the X11 developers for their advice. Maybe we're missing some option here? I doubt it, but we should give it a try. signature.asc Description: This is a digitally signed message part.
Re: DInput mouse - where to go from here?
Vitaliy Margolen [EMAIL PROTECTED] writes: Anything else I missed? Are there are any better ways to solve these problems? Any other ways at all? The right way is to use XInput, and work with the X.org guys to fix what's necessary to make it work for our needs. -- Alexandre Julliard [EMAIL PROTECTED]
Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation
Roy Shea [EMAIL PROTECTED] writes: Resubmission of a bare bones bits implementation. There is no bits.dll on any Windows version I've checked. Where does this dll come from? -- Alexandre Julliard [EMAIL PROTECTED]
Re: [5/5] WineD3D: Add sincos support to arb shaders
Stefan Dösinger wrote: Am Donnerstag, 27. September 2007 02:57:01 schrieb Ivan Gyurdiev: Aren't most of these 2.0 and 3.0 instructions ? What's the goal of adding them to ARB - you won't be able to implement full 2.0/3.0 support in ARB. We can implement 2.0(but not 2.a/b). Whenever it's easy to do, I'm adding 3.0-Specific behavior too. The reason is that GLSL is a bloody pain on MacOS, with ARB I can bypass many abstraction layers that have a huge number of software fallback pitfalls. Are you saying you intend to advertise 3.0 support on ARB only? If not, then why add any 3.0 features at all ? Ivan
Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation
Am Donnerstag, 27. September 2007 12:58:46 schrieb Alexandre Julliard: Roy Shea [EMAIL PROTECTED] writes: Resubmission of a bare bones bits implementation. There is no bits.dll on any Windows version I've checked. Where does this dll come from? It is an extra download, but requires a WGA check. signature.asc Description: This is a digitally signed message part.
Re: [5/5] WineD3D: Add sincos support to arb shaders
Am Donnerstag, 27. September 2007 13:02:31 schrieb Ivan Gyurdiev: Are you saying you intend to advertise 3.0 support on ARB only? If not, then why add any 3.0 features at all ? No, I certainly do not intend to advertise 3.0 because we cannot implement things like branching, dsx/dsy or vertex textures, but I'll propably advertise 2.0 some day, if I feel like causing a lot of extensions(Or I think that our shader tests are good enough to safely do this). The ARB shader backend tries to eat everything it is fed with though, even 3.0 shaders. Some games require a specific shader model, but use only a subset of it that is supportable. Having the code to support some 3.0 specials makes my life easier since I can just go and lie about the caps on macos for specific games(e.g. in crossover). I don't put special focus on SM 3.0 support, but if I come across something that is easy to add, I'm adding it. Also, some day we may implement the 3.0 features using the NV extensions. Of course if it's preferred to keep the arb shader backend clean from version == 3.0 checks I can keep the things I have in my junk branch, as long as I don't have to explain why I'm not submitting $GAMEFIX to Wine. Pretending SM 3.0 support is a hack, implementing the parts of 3.0 we can implement properly isn't IMHO. signature.asc Description: This is a digitally signed message part.
Re: gdi: Fix meaning and use of bidirectionality flags
Maarten Lankhorst wrote: According to shachar shamesh they have a slightly different meaning. This should fix it. First of all, things seem much much better with this patch. I would direct your attention to the fact that, when I run it, I get: $ programs/notepad/notepad fixme:bidi:mirror stub: mirroring of characters not yet implemented fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveWeak assert failed: pcls[ich] = BN fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveNeutrals assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 fixme:bidi:resolveImplicit assert failed: pcls[ich] 5 As far as I can tell, an assert should not be a fixme, but that's something else. Shachar
Re: [PATCH 1/2] [try2] Allow completion object to be attached to an fd object
Andrey Turkin [EMAIL PROTECTED] writes:
+DECL_HANDLER(set_completion_info)
+{
+struct fd *fd = get_handle_fd_obj( current-process, req-handle, 0 );
+
+if (fd)
+{
+if (fd-completion)
+release_object( fd-completion );
+fd-completion = get_completion_obj( current-process, req-chandle,
IO_COMPLETION_MODIFY_STATE );
+fd-comp_key = req-ckey;
+release_object( fd );
You need to check that the completion object is valid before you start
modifying the fd.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Alexandre Julliard : gdi32: Don' t pass a DC handle to WineEngGetFontUnicodeRanges.
Alexandre Julliard wrote:
-DWORD WineEngGetFontUnicodeRanges(HDC hdc, LPGLYPHSET glyphset)
+DWORD WineEngGetFontUnicodeRanges(GdiFont *font, LPGLYPHSET glyphset)
{
FIXME((%p, %p): stub\n, hdc, glyphset);
You forgot to change hdc to font in the FIXME call.
--
Rob Shearman
re: I need help, please
David, sorry, Wine's not likely to be able to run Corel Draw X3 without several months worth of work, and nobody's focusing on it at the moment. - Dan
Re: WineD3D surface management cleanup
I tried those patches with git and it works without problems in my D3D apps. Mirek Stefan Dösinger napsal(a): Hi, This mail is mainly addressed at Henri and Roderick, but I'll send it here to allow others to read it too. These patches contain some cleanups of the d3d surface loading code. It's main aim is to put the code that copies the surface between system memory, texture and drawable into a centralized place, make LockRect simpler and pbo creation and surface memory allocation in one place(surface allocation is not completely there yet). It also makes other parts of the code simpler, avoids playing with the surface flags in other places, and it will allow us to centralize the logic that in the case of fbo offscreen rendering the drawable is the same as the texture(This is also not implemented yet). The patches don't aim at fixing any bugs themselves, and I hardly tested them, so there may be a truckload of regressions. I'm mainly showing them to show the general direction I'm heading into. Notification from NOD32 Warning: This message was not checked by NOD32 Antivirus System for Linux Mail Servers. - is OK - is OK part000.txt - is OK Archiv.tar.gz - is OK Archiv.tar.gz - GZ - R9B9aa.tar - is OK Archiv.tar.gz - GZ - R9B9aa.tar - TAR - 0039-WineD3D-Begin-centralizing-surface-location-managem.patch - too many archives embedded Archiv.tar.gz - GZ - R9B9aa.tar - TAR - 0040-WineD3D-Add-a-method-for-surface-location-updates.patch - too many archives embedded Archiv.tar.gz - GZ - R9B9aa.tar - TAR - 0041-WineD3D-Move-regular-surface-texture-downloading.patch - too many archives embedded Archiv.tar.gz - GZ - R9B9aa.tar - TAR - 0042-WineD3D-Move-drawable-sysmem-reading-to-UpdateLoca.patch - too many archives embedded Archiv.tar.gz - GZ - R9B9aa.tar - TAR - 0043-WineD3D-Add-a-comment-explaining-what-RequestLocati.patch - too many archives embedded Archiv.tar.gz - GZ - R9B9aa.tar - TAR - 0044-WineD3D-Move-sysmem-drawable-copying-to-RequestLoc.patch - too many archives embedded Archiv.tar.gz - GZ - R9B9aa.tar - TAR - 0045-WineD3D-Move-texture-loading-to-RequestLocation.patch - too many archives embedded Archiv.tar.gz - GZ - R9B9aa.tar - TAR - 0046-WineD3D-Move-memory-allocation-and-pbo-creation-to.patch - too many archives embedded Archiv.tar.gz - GZ - R9B9aa.tar - TAR - 0047-WineD3D-Move-a-part-of-LockRect-to-the-base-class.patch - too many archives embedded signature.asc - is OK part001.txt - is OK http://www.eset.com
Re: DInput mouse - where to go from here?
Stefan Dösinger wrote: 1) Multiple Mice. If there are 2 mouse devices, the X server manages them and combines them to one core pointer. These configurations are pretty common, for example on laptops with touchpad + usb mouse. This is true, each mouse will have it's own device. However I have never seen a single person who used 2 or more mice while playing games g 2) Different devices: An USB mouse creates a /dev/input/eventX node, but other devices, like my synaptics touchpad do not. In the worst case we need a driver for each mouse type, USB, serial, PS2, Synaptics, busmouse, logitech, ... Not true. That's what so great about evdev driver - it's unified. Everything is handled by the kernel, and we get common interface to things like axis movement and buttons. I have tested this with USB and PS/2 mouse - works properly in each case. Vitaliy
Re: DInput mouse - where to go from here?
Alexandre Julliard wrote: Vitaliy Margolen [EMAIL PROTECTED] writes: Anything else I missed? Are there are any better ways to solve these problems? Any other ways at all? The right way is to use XInput, and work with the X.org guys to fix what's necessary to make it work for our needs. I don't see how will that solve (c,d,f,g)? Also how long should we wait on that? Year? 5 years? I looked at the current Xorg source and it still explicitly forbidding opening of the mouse and keyboard devices. Yet some one mentioned they would change that. I'm talking about solutions right now, so we can move on and fix other related issues, not sit and wait for some one to give us what we need. Vitaliy.
Re: DInput mouse - where to go from here?
Vitaliy Margolen [EMAIL PROTECTED] wrote: Alexandre Julliard wrote: Vitaliy Margolen [EMAIL PROTECTED] writes: Anything else I missed? Are there are any better ways to solve these problems? Any other ways at all? The right way is to use XInput, and work with the X.org guys to fix what's necessary to make it work for our needs. I don't see how will that solve (c,d,f,g)? Also how long should we wait on that? Year? 5 years? I looked at the current Xorg source and it still explicitly forbidding opening of the mouse and keyboard devices. Yet some one mentioned they would change that. I'm talking about solutions right now, so we can move on and fix other related issues, not sit and wait for some one to give us what we need. We can always send patches to the projects for the things we would like to see improved support. That was the case for kernel, gnome, freetype, binutils, cygwin, mingw, and many others. -- Dmitry.
Re: DInput mouse - where to go from here?
Am Donnerstag, 27. September 2007 17:23:42 schrieb Vitaliy Margolen: Stefan Dösinger wrote: 1) Multiple Mice. If there are 2 mouse devices, the X server manages them and combines them to one core pointer. These configurations are pretty common, for example on laptops with touchpad + usb mouse. This is true, each mouse will have it's own device. However I have never seen a single person who used 2 or more mice while playing games g I do That's the great thing about laptops, at least when playing Battlefield 1942. You can keep an aircraft controlled with one hand, but for serious fighting you need the real mouse. Imagine a LAN Party, running bf1942, some pizza next to you. With the thumb on the touchpad and the WASD keys, you can take off with a plane and steer to the battle, while the right hand is free to grab a glass or some pizza. Yes, it makes the keyboard and mouse oily and there's a risk to poor liquid over the laptop, but it works with the current dinput code :-) Not true. That's what so great about evdev driver - it's unified. Everything is handled by the kernel, and we get common interface to things like axis movement and buttons. I have tested this with USB and PS/2 mouse - works properly in each case. Should all mouse types create a event device node? Maybe I've done something wrong on my new laptop. On the old laptop, the touchpad had such a node, on the new one it doesn't. signature.asc Description: This is a digitally signed message part.
Re: mpr: Changes comparison of dwScope in WNetOpenEnum function
Hi Konstantin, I have one more question. To add realization of new function, I can add it in struct WNetProvider? For example: typedef struct _WNetProvider (snip) PF_NPGetResourceInformation getResourceInformation; //my added function } WNetProvider, *PWNetProvider; It is correct? Yes, precisely correct. --Juan
Re: DInput mouse - where to go from here?
The right way is to use XInput, and work with the X.org guys to fix what's necessary to make it work for our needs. I don't see how will that solve (c,d,f,g)? Also how long should we wait on that? Year? 5 years? I looked at the current Xorg source and it still explicitly forbidding opening of the mouse and keyboard devices. Yet some one mentioned they would change that. I'm talking about solutions right now, so we can move on and fix other related issues, not sit and wait for some one to give us what we need. We can always send patches to the projects for the things we would like to see improved support. That was the case for kernel, gnome, freetype, binutils, cygwin, mingw, and many others. -- I'd suggest we see if we can get someone from X.org involved in the discussion. While this wouldn't result in a fix today it would certainly let us get cooperation which is likely to result in a better fix. We might have to wait half a year for the full fix to get out there but we can always provide a short term work around and see if we can't run-time detect the improved correct way of doing it. Chris
Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation
Howdy, On Thu, Sep 27, 2007 at 02:55:40PM +0200, Stefan D?singer wrote: Am Donnerstag, 27. September 2007 12:58:46 schrieb Alexandre Julliard: Roy Shea [EMAIL PROTECTED] writes: Resubmission of a bare bones bits implementation. There is no bits.dll on any Windows version I've checked. Where does this dll come from? It is an extra download, but requires a WGA check. Argh! My bad. I just finished looking into this a bit more and here is my current understanding. You can download bits from Microsoft, but I don't think you are going to get a bits.dll out of it. The dll that I'm working on is intended to stand in for the collection of dlls available at http://support.microsoft.com/?kbid=923845, although most Windows users should already have the dlls: Qmgr.dll - Very old version of bits that appears to be heading towards deprecation. Bitsprx2.dll - Base version of bits that I'm trying to implement for wine. Bitsprx3.dll - Version 2.0 of bits adding features to the base version (gotta love the off by one numbering scheme!). Bitsprx4.dll - Newest extensions to bits available on some systems. As far as I can tell the Bitsprx2.dll is generated from Bits.Idl, that is equivalent to the bits.idl I'm developing. Since my dll is not acting as a proxy, at least as I understand proxy dlls (I'm still digging through COM books), I thought it would be more accurate to not include the prx in the name of my dll. Simply changing the name from bits.dll to bitsprx2.dll is easy enough, but I worry that the semantics between a regular dll and a proxy dll would cause confusion or problems. My understanding of proxies is that they allow cross-apartment access to a COM object. Ideally, I'd like to first get in process support of bits (CLSCTX_INPROC_SERVER object instantiation), and then worry about support across apartments. I am new to both COM and Wine and I may be a bit off in my understanding of some of these points. I would love any advice on how to get my current code in shape for Wine. In particular, should I provide a full proxy version of bits and resubmit it as Bitsprx2.dll or should I introduce basic functionality first, perhaps through bits.dll or something else, and then jump in on the proxy code. Thanks for the advice! -Roy
Wine gets exposed in Norway :)
The most visited and respected technology related site in Norway (210 000 unique norwegian hits a week), is now launching a series of articles where they will test 3 games thoroughly in wine each month! Today the first article tested Fahrenheit, Guild Wars: Nightfall and Civilization IV: Warlords. The results where good and focused on what users should do to make them work smoothly. Hope this is an encouragement for Stefan and all the others of you working to get games working :)
Re: Wine gets exposed in Norway :)
On Thursday 27 September 2007 19:58:29 Tomas Zijdemans wrote: The most visited and respected technology related site in Norway (210 000 unique norwegian hits a week), is now launching a series of articles where they will test 3 games thoroughly in wine each month! Today the first article tested Fahrenheit, Guild Wars: Nightfall and Civilization IV: Warlords. The results where good and focused on what users should do to make them work smoothly. Hope this is an encouragement for Stefan and all the others of you working to get games working :) Please note that this is a secret website, so we Norwegians cannot send the website address to the list. :) Alexander N. Sørnes
Re: iTunes 7.4.2 doesn't even install for me
Hi Paul, I saw your bug 9765 but I don't even get that far. The install crashes for me with something that appears to be connected to a driver: Actually, I see that crash too. I meant to log a bug for it, but never did. Would you mind? (snip) LC:\\windows\\System32\\Drivers\\GEARAspiWDM.sys (native) at 0x46 trace:module:process_attach (LGEARAspiWDM.sys,(nil)) - START trace:module:MODULE_InitDLL (0x46 LGEARAspiWDM.sys,PROCESS_ATTACH,(nil)) - CALL trace:seh:raise_exception code=c005 flags=0 addr=0x464010 trace:seh:raise_exception info[0]=0001 trace:seh:raise_exception info[1]=00460038 trace:seh:raise_exception eax=0046137e ebx=7bc90dc8 ecx=001c edx=0046 esi=7bc87f5b edi=00460038 That address (0x00460038) is suspect. It looks like part of a Unicode string. Something about how this driver is loaded is buggy, I'm guessing ntoskrnl.exe is a bit too stubby for it yet. Nevertheless, iTunes starts for me after this crash, it just warns about the registry entries needed for CD/DVD drives being missing, and I suspect that's due to this driver not being registered correctly. I just ignore that warning. As your so busy with iTunes these days, I thought I contact you directly. I don't mind, but I'm actually off it now. I've tried to stay up to date this week, but no guarantees now that I'm back in school. --Juan
Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation
Roy Shea [EMAIL PROTECTED] writes: As far as I can tell the Bitsprx2.dll is generated from Bits.Idl, that is equivalent to the bits.idl I'm developing. Since my dll is not acting as a proxy, at least as I understand proxy dlls (I'm still digging through COM books), I thought it would be more accurate to not include the prx in the name of my dll. Simply changing the name from bits.dll to bitsprx2.dll is easy enough, but I worry that the semantics between a regular dll and a proxy dll would cause confusion or problems. The only way to avoid confusion and problems is for your dll to have the same name, and behave the same way, as the Windows one. -- Alexandre Julliard [EMAIL PROTECTED]
Re: version resource for ole2nls.dll
Stefan Leichter [EMAIL PROTECTED] wrote: This patch fixes Bug 9747 ChangeLog - added version resource for ole2nls.dll +#define WINE_FILEVERSION_STR 2.10.3050.1 +#define WINE_FILEDESCRIPTION_STR Wine OLE dll +#define WINE_FILENAME_STR OLE2NLS.DLL + +#include wine/wine_common_ver.rc Why do you define WINE_FILEVERSION_STR but not WINE_FILEVERSION? That not creates a confusion but could lead to hard debuggable problems with application which test only one of them. -- Dmitry.
Re: version resource for ole2nls.dll
Dmitry Timoshkov [EMAIL PROTECTED] wrote: Stefan Leichter [EMAIL PROTECTED] wrote: This patch fixes Bug 9747 ChangeLog - added version resource for ole2nls.dll +#define WINE_FILEVERSION_STR 2.10.3050.1 +#define WINE_FILEDESCRIPTION_STR Wine OLE dll +#define WINE_FILENAME_STR OLE2NLS.DLL + +#include wine/wine_common_ver.rc Why do you define WINE_FILEVERSION_STR but not WINE_FILEVERSION? That not creates a confusion but could lead to hard debuggable problems with application which test only one of them. The above should be read as: That not only creates a confusion but could lead to hard debuggable problems with application which test only one of them. -- Dmitry.
