- Wine-Devel - list.winehq.org

Re: [wined3d] numblends
by Raphael July 21, 2005

July 21, 2005

On Wednesday 20 July 2005 20:18, you wrote: > Hi, > This patch corrects a problem with the way that FVF vertex arrays > containing blends or orthographic is calcualted. > > This patch should get Axis and Allies and Kohan 2 started > Good catch :) Regards, Raphael

2 1

Re: foward declare interfaces in stdole2
by Huw D M Davies July 21, 2005

July 21, 2005

On Thu, Jul 21, 2005 at 12:06:15PM +0530, Vijay Kiran Kamuju wrote: > This fixes the below problem, same problem i faced with msxml > interfaces and forward declarations fixed it. > > ChangeLog > ---------------- > Forward declare interfaces This isn't what we want anyway, since it changes the order of the typeinfos in the typelib. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Run-time error '13'
by Savio Ramos July 21, 2005

July 21, 2005

Hi, I am using wine without problems but after upgrade for release 0.0.20050628-2, this error appeared in a window after SISUPFOR.exe started: Run-time error '13' Type mismatch Any help? Thanks. -- Savio Martins Ramos - Arquiteto Rio de Janeiro ICQ 174972645 Pirataria não! Seja livre: Linux http://www.debian.org _______________________________________________________ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/

3 5

std* streams in MSVC
by Saulius Krasuckas July 21, 2005

July 21, 2005

I am testing code: | #include <stdio.h> | | void main( void ) | { | printf( "The file handle for stdin is %p %d\n", stdin, _fileno( stdin )); | printf( "The file handle for stdout is %p %d\n", stdout, _fileno( stdout )); | printf( "The file handle for stderr is %p %d\n", stderr, _fileno( stderr )); | } I link with no libraries and get following output: | The file handle for stdin is 00424A30 0 | The file handle for stdout is 00424A50 1 | The file handle for stderr is 00424A70 2 If I link with msvcrtd.lib, then output is: | The file handle for stdin is 004150B0 270578480 | The file handle for stdout is 004150D0 270608264 | The file handle for stderr is 004150F0 0 And this I get with msvcrt.lib: | The file handle for stdin is 004150B0 2013313950 | The file handle for stdout is 004150D0 2013328746 | The file handle for stderr is 004150F0 0 Calls to freopen(), fprintf(), setvbuf() using any std* stream throws an exception in last two cases (msvcrtd.lib and msvcrt.lib). I guess pointers are left uninitialized. Anybody knows why and how to make this code work in all three cases?

1 0

Re: stdole2.tlb
by Ivan Gyurdiev July 21, 2005

July 21, 2005

> I've not tested this with an InstallShield installer - feedback > welcome. Thank you very much - GTA will now begin installing, will get through all the InstallShield screens, and then it gets to the last one where it should begin installing, and it freezes and nothing happens. fixme:font:load_VDMX Failed to retrieve vTable fixme:font:load_VDMX Failed to retrieve vTable fixme:font:load_VDMX Failed to retrieve vTable fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects ... (more of this) fixme:win:SetWindowTextA setting text "TITLE_CAPTIONBAR" of other process window (nil) should not use SendMessage fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff fixme:win:SetWindowTextA setting text "GTA San Andreas - InstallShield Wizard" of other process window (nil) should not use SendMessage fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff .... fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fcad3f8,0x7fcad3fc), stub! fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fcad2f8,0x7fcad2fc), stub! fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fcad37c,0x7fcad380), stub! fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fcad8e4,0x7fcad8e8), stub! fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fcad7e4,0x7fcad7e8), stub! fixme:ole:RpcChannelBuffer_GetDestCtx (0x7fcad868,0x7fcad86c), stub! ... (more of this)

1 0

Re: headers: handle sizeof(long)==8
by Raphael July 21, 2005

July 21, 2005

On Wednesday 20 July 2005 05:00, Kevin Koltzau wrote: > Changelog > If sizeof(long)==8, define DWORD and LONG as 32bit int Hi, Why not using basetsd.h defines instead ? Regards, Raphael

2 1

Re: File dialogs *should* browse to the directory when a directory name is typed in and the "Open" button or save button is clicked
by Huw D M Davies July 20, 2005

July 20, 2005

On Wed, Jul 20, 2005 at 04:18:55PM +1000, Troy Rollo wrote: > This patch reverses the change made by change set 17928 > <http://cvs.winehq.org/patch.py?id=17928>. Under windows if you type in the > name of a directory these dialogs do browse to that directory. As far as I > can tell 17928 does nothing other than make the Wine dialog's behaviour > diverge from native Windows behaviour. > > ChangeLog: > Reverse change set 17928 - the correct behaviour in Windows is to > browse to the directory if a directory name is typed into the edit box > of a file dialog and the confirmation button (or Enter key) is hit. Hmm, there's clearly something else going on here as I didn't just make up this behaviour. Huw. -- Huw Davies huw(a)codeweavers.com

2 1

Today's winetest build?
by Paul Millar July 20, 2005

July 20, 2005

Hi, I've noticed that the test site (test.winehq.org/data) has no mention of today's cron-build of winetest. Having monkeyed about with the build process over the weekend (but, I thought, not that part) I'm a little worried I might have inadvertently upset the part that registers a new cron-build. Could someone check that test.winehq.org/service received a (http) hit today? Cheers, Paul.

5 6

Celebrating some hard work
by Jeremy White July 20, 2005

July 20, 2005

Hi folks, You may have noticed Rob submitting a long string of OLE patches. That is formally the last set of 'hard work' we planned to do as part of our work on our 5.0 release. Now we just have to do the 'easy part' - stabilizing for release <g>. The big picture items included the window manager rewrite, the OLE/COM work, and the work on MSI. I'd like to take a minute to thank all the people, both inside and outside CodeWeavers, that helped to work on these projects. I think that these tasks represent a fairly signficant milestone for Wine - we seem to have enough working that Alexandre is willing to contemplate a non alpha release; that's a pretty big deal. (Another 11 years, and maybe 1.0 will actually happen :-/). At any rate, this work has been a bit hard on us, because it's largely been under the hood, unsexy work that tends to cause regressions. So from a customer perspective, the rational analysis is: "you did all that work and now my windows don't scroll right? Morons!" But one of the key benefits that the OLE/MSI work gives us, in particular, is that we can now intelligently debug issues with COM, which was always a nightmare to debug before. And, as you all probably know, many installers rely heavily on both COM and MSI to do their work. So we now believe that many, many more installers will 'just work' than before. And we further believe that those that don't work can be fixed in a much more straightforward way. Thus, I am now making good on my promise to lock Rob and Aric in a room and make installers go. We've announced a formal, CrossOver based program over on our web site. However, I wanted to let you know that we'll do the same on an informal basis, particularly for known Wine developers. I'm hoping that as a result of this work we'll soon be able to claim with a straight face: "Most things install." So, if you have an app that doesn't install, post a message to wine-devel, and let's see if we can't make some lemonade and have a party! Cheers, Jeremy

9 9

Re: WLDAP32: implement ldap_simple_bind* and ldap_unbind* functions
by Felix Nawothnig July 20, 2005

July 20, 2005

Hans Leidekker wrote: > Although not strictly necessary, I did the ldap_unbind functions > as wrappers because I'd like the debug logging to show ldap_bind > and matching ldap_unbind calls. Does +relay not work here? Felix

1 0