Re: DInput mouse - where to go from here?

2007-09-27 Thread 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_!
 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

2007-09-27 Thread Stefan Dösinger
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

2007-09-27 Thread Shachar Shemesh
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?

2007-09-27 Thread Stefan Dösinger
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?

2007-09-27 Thread Alexandre Julliard
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

2007-09-27 Thread 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?

-- 
Alexandre Julliard
[EMAIL PROTECTED]




Re: [5/5] WineD3D: Add sincos support to arb shaders

2007-09-27 Thread Ivan Gyurdiev
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

2007-09-27 Thread Stefan Dösinger
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

2007-09-27 Thread Stefan Dösinger
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

2007-09-27 Thread Shachar Shemesh
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

2007-09-27 Thread Alexandre Julliard
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.

2007-09-27 Thread Robert Shearman
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

2007-09-27 Thread Dan Kegel
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

2007-09-27 Thread Mirek Slugeň




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?

2007-09-27 Thread 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

 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?

2007-09-27 Thread Vitaliy Margolen
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?

2007-09-27 Thread Dmitry Timoshkov
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?

2007-09-27 Thread Stefan Dösinger
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

2007-09-27 Thread Juan Lang
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?

2007-09-27 Thread Chris Morgan
 
  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

2007-09-27 Thread Roy Shea
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 :)

2007-09-27 Thread Tomas Zijdemans
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 :)

2007-09-27 Thread Alexander Nicolaysen Sørnes
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

2007-09-27 Thread Juan Lang
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

2007-09-27 Thread Alexandre Julliard
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

2007-09-27 Thread Dmitry Timoshkov
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

2007-09-27 Thread Dmitry Timoshkov
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.