September 2004 - Wine-Devel

Re: dinput header fixes
by Alexandre Julliard Sept. 18, 2004

Sept. 18, 2004

Robert Reif <reif(a)earthlink.net> writes: > Add some more version checks. As a rule we avoid such version checks in Wine, they are not necessary and will only cause trouble since we compile our code with the same headers. I know there are some similar checks in there already but they should probably be removed. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: buffer: ref count cleanup
by Robert Reif Sept. 18, 2004

Sept. 18, 2004

James Hawkins wrote: >Changelog > * Use InterlockedDecrement and InterlockedIncrement instead of ++/--. > > > That ref doesn't belong to a com object. I belongs to a duplicated memory buffer and should probably be protected by a lock someday.

1 0

[OT] AMD64 Implications
by Ann and Jason Edmeades Sept. 17, 2004

Sept. 17, 2004

Hello, Slightly off topic, but I am looking at purchasing a new PC and intend to continue doing wine development on it (especially d3d9). Is there any wine implications to buying an AMD64 compared to a 'normal' 32 bit chip. Will I be able to continue my wine development, obviously for running emulation of 32 bit windows apps (games)? Would I need to ensure I use 32 bit kernels, or can I make use of any 64 bit ones (dont know if these exist even!). Sorry if this is an obvious question, but I didnt want to go so far and find I have caused myself problems Jason

2 1

Re: fonts: wine_marlett
by Ivan Leo Puoti Sept. 17, 2004

Sept. 17, 2004

> That works but then we're maintaining two codepaths, one or other of > which will hardly be tested at all. Why not just check in the font > binaries? What is required to build the fonts? Should I install fontforge? I've been in hospital with appendicitis and haven't followed wine development recently. Ivan.

1 0

Re: olefont: ref count cleanup
by Robert Shearman Sept. 17, 2004

Sept. 17, 2004

James Hawkins wrote: >Changelog > * Use InterlockedDecrement and InterlockedIncrement instead of ++/--. > > Again, all of these patches do not fix the whole point about using the Interlocked* functions, which is that the variable must always be used *atomically*. That means if you grep the file for uses of "This->ref" (or the equivalent) then they should all only be as parameters to Interlocked* functions. Rob

2 2

Re: InternetSetStatusCallback Fix (resend)
by Alexandre Julliard Sept. 17, 2004

Sept. 17, 2004

Robert Shearman <rob(a)codeweavers.com> writes: > Any reason this patch wasn't applied? Yes, it doesn't apply. Could you please resend an updated patch? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: olepicture: ref count cleanup
by Alexandre Julliard Sept. 17, 2004

Sept. 17, 2004

James Hawkins <truiken(a)gmail.com> writes: > Changelog > * Use InterlockedDecrement and InterlockedIncrement instead of ++/--. When making these changes please fix the rest of the function too, any place that uses This->ref directly is broken, it should use the return value of the Interlocked call instead. Otherwise there's no point in making the changes since it still won't be thread-safe. -- Alexandre Julliard julliard(a)winehq.org

1 0

autoconf issues on HP-UX
by Warren_Baird＠cimmetry.com Sept. 17, 2004

Sept. 17, 2004

Hi all, I'm in the process of trying to get winelib working on an HP-UX / PA-RISC machine. The first issue I've come across is related to autoconf, and I'm afraid I'm far from an autoconf guru, so I wanted to post my proposed solution here before submitting a patch. The problem is that the current autoconf tests done to determine how to link a shared library aren't very good - they use WINE_TRY_CFLAGS, which builds a c file containing something like "void main() { } " and tries to link it. The problem is that this isn't a very good test about whether you can link a *shared library* - since you've got a main line defined. Unfortunately the gnu ld doesn't work on hpux, so I have to use the system linker, and the UnixWare link test succeed when it should fail - since the HPUX linker doesn't understand the arguments it is given, it goes on to link an executable and generates a warning about not being able to hide symbol "conftest.so.1.0". I believe that a better test is to try to link a shared lib from a C file containing "void myfunc() {}" - this way if the provided arguments don't convince the linker to create a shared lib, you'll get a error about "main" being undefined. My proposed solution is to define a new function "WINE_TRY_SHLIB" that does what I describe above, and then use it in the 3 existing places we're checking for shared libs, and add a new test specifically for hpux. I've attached my proposed patch file (although I'm still trying to sort out exactly what flags I need for hpux libs)... Does this seem reasonable? thanks, Warren (See attached file: patch.txt)

2 1

Re: fonts: wine_marlett
by Robert Shearman Sept. 17, 2004

Sept. 17, 2004

Huw D M Davies wrote: > TransGaming > Add a Marlett replacement font > > Cool! Is there any policy for using it? E.g. a lot of the arrows and stuff in the native comctl32 are drawn using this font, so would we now be able to do this with our version of the common controls? Rob

5 5

Re: [DPNET] Cleanup/Correct
by Alexandre Julliard Sept. 17, 2004

Sept. 17, 2004

Raphael <fenix(a)club-internet.fr> writes: > I'm back (after a long time without coding) and seems that many directx dlls > are brokens after COM "migrations" No, the dlls are fine, probably your tree has not been updated properly. -- Alexandre Julliard julliard(a)winehq.org

1 0