Re: richedit: Mask window id on WM_COMMAND notifications.
On Sat, Jan 3, 2009 at 12:37 AM, Dmitry Timoshkov wrote: > "Dylan Smith" wrote: > > - SendMessageA(GetParent(hWnd), WM_COMMAND, >> (nCode<<16)|GetWindowLongW(hWnd, GWLP_ID), (LPARAM)hWnd); >> + SendMessageA(GetParent(hWnd), WM_COMMAND, (nCode<<16)|(0x & >> GetWindowLongW(hWnd, GWLP_ID)), (LPARAM)hWnd); >> > > MAKEWPARAM and LOWORD are supposed to be used here. Alright, I'll change that before resending. > Also, have you > tested what happens if real window id is larger than a 16-bit value, > or just a negative 16-bit one? > I was just running the test application provided in Bug 16349 and I found while debugging that GetWindowLongW(hWnd, GWLP_ID) was returning 0x20034 which is larger than a 16-bit value. That doesn't seem like a negative 16-bit value. Besides that I know very little about what this value normally would be, and don't know how I would test this in the test suite, since this doesn't always occur (e.g. I got GetWindowLongW(hWnd, GWLP_ID)=0x7d1 when running wine wordpad).
Re: richedit: Mask window id on WM_COMMAND notifications.
"Dylan Smith" wrote: > - SendMessageA(GetParent(hWnd), WM_COMMAND, (nCode<<16)|GetWindowLongW(hWnd, > GWLP_ID), (LPARAM)hWnd); > + SendMessageA(GetParent(hWnd), WM_COMMAND, (nCode<<16)|(0x & > GetWindowLongW(hWnd, GWLP_ID)), (LPARAM)hWnd); MAKEWPARAM and LOWORD are supposed to be used here. Also, have you tested what happens if real window id is larger than a 16-bit value, or just a negative 16-bit one? -- Dmitry.
Re: winequartz.drv Mac OS X UI discontinued?
Emmanuel Maillard wrote: > Hi, > > Le 4 juil. 08 à 12:37, Adam Strzelecki a écrit : > > >> Hi Emmanuel, hello Wine developers, >> >> Latest WineQuartz.drv patch is 0.9.58. Is there any change for more >> recent release? I tried this patch with 1.0-1 however it has too >> many conflicts. >> It would be most convenient if you had just update >> http://repo.or.cz/w/wine/winequartzdrv.git >> to match 1.1.0 somehow and include Quartz. >> > > I resolved conflicts for wine-1.0, but didn't take a look yet for > wine-1.1.0, i just know that's some changes in user32 and winex11.drv > have to be update in winequartz.drv too. > > I will see this week end if i can find free time to make a new patch > for winequartz.drv and send it to SourceForge. > (OpenGL is broken in winequartz.drv actually, because of a lack of > time to fix it) > > > >> Since Wine passed 1.0 (woohoo!) maybe someone from the direction can >> revise Mac support? Even there're numerous Emmanuel efforts to >> provide Mac UI driver instead of X11, it will be always pushed >> aside, and sentenced to death, because it is not in official sources. >> >> I know Alexandre Julliard's decision about NOT taking any Objective- >> C sources (.m) into the Wine, but maybe this can be revised, anyway >> all .m rules will be only present on Mac platforms. Using Objective- >> C is only way to make fair support for Mac OS GUI, as those whole >> GUI system is objective. >> Moreover then what's the point of keeping winex11.drv and all GUI >> driver infrastructure in Wine if nothing else but X11 is NOT >> accepted into official source? >> >> Forgive me what I say now, but I just it would be more fair if >> someone from Codeweavers just said that Wine's official support for >> Mac OS X is against their business with CrossOver and this is the >> real reason they reject winequartz.drv from Emmanuel Maillard. >> Frankly I'd really pay for CrossOver or Wine, if it was what 1.0-1 >> is but with native Mac UI, so each wine process has it's own dock >> icon, and no X11 is needed and native Mac font system. >> >> Regards, >> -- >> Adam Strzelecki |: nanoant.com :| >> >> > > > Cheers > Emmanuel > > Emmanuel: What is the status of winequartz.drv? It looks like your last patch was for 1.1.2. James McKenzie
Re: start.exe: don't use the NO_UI flag when invoked with /unix
On Fri, Jan 2, 2009 at 6:30 PM, Vincent Povirk wrote: > This makes it possible to get feedback when something goes wrong starting a > non-exe file through a Linux gui. > > > You forgot the patch ;-). -- -Austin
Re: start.exe: don't use the NO_UI flag when invoked with /unix
On Fri, Jan 2, 2009 at 4:30 PM, Vincent Povirk wrote: > This makes it possible to get feedback when something goes wrong starting a > non-exe file through a Linux gui. > Forgot the patch. -- James Hawkins
install-wine-deps.sh can now handle 32 bit wine on 64 bit systems
I just improved http://code.google.com/p/winezeug/source/browse/trunk/install-wine-deps.sh so it does all the futzing needed to build 32 bit wine on 64 bit systems (although at the moment it only does this for Ubuntu Intrepid). Because it puts the missing .so files in /usr/lib32, there's no need to futz with LDPATH. For example, after running the script, you can do either ./configure make to build 64 bit wine, or ./configure --target=i686-unknown-gnu-linux make to build 32 bit wine. Easy beans! - Dan
Re: Status of dxdiagn?
On Friday 02 January 2009 10:58:48 Dan Kegel wrote: > Got another game that needs dxdiagn fixes? Personally, I don't know of any other games that need dxdiagn fixes but I guess you already identified potential candidates earlier. > Or they could go ahead and do dxdiag on top of dxdiagn. That might be a good idea as it would simplify dxdiagn development by offering a GUI showing the retrieved values and those still missing. -- Markus
Re: [PATCH] oleaut32: PICTYPE_ICON returns EFAIL for get_hPal (try 2)
Jon Griffiths wrote: > Hi, > > Smaller patch with properly static-ified icon data. > > Cheers > Jon > > > > > > Did this patch get dropped for a reason?
Re: [shell32 5/6] include: Add remotable stubs for non-default-marshallable shobjidl calls.
2009/1/1 Michael Karcher : > Am Donnerstag, den 01.01.2009, 20:43 + schrieb Rob Shearman: >> No, the [string] attribute in this case in redundant and it should >> apply to the first pointer in the parameter. > Now, that makes sense. > >> I'm guessing by the >> change that you had to make that widl doesn't handle this too well... > Seems so. I don't want to hurt anyone, but I somehow get the impression > that the quality of widl is somewhere around works-for-me. The trouble in this case was a corner case that was only tested by some bad IDL. Corner cases are never easy to test for and the best way of fixing bugs is to eliminate them as much as possible. To that end I have some patches queued up that add more of an API to access the parse tree to try to make the generator code more robust. In particular, the C generator code could probably do with a function like type_get_ndr_type that deals with the nuances of detecting strings, user-types, context handles, interface pointers, etc and that would likely have fixed several of the issues you reported. In terms of testing, I want to find and fix these issues before users (i.e. other developers, like you) find them. To that end, I think a good test may be to run "widl -p" on as many of the files in include/ as possible and fix/log any issues that come up, and then to compile each file. There should be no errors in either case, since errors should be reported up front (i.e. even for just generating a header file or a syntax check). I also plan to write a fuzzer for widl someday - if anyone knows of a free fuzzer framework out there somewhere then that would be useful. -- Rob Shearman
Re: Implemented retrieval of szDeviceIdentifier property in dxdiagn
Markus wrote: Few problems with your patch: > +IDirect3D9 *(WINAPI *pDirect3DCreate9)(UINT) = NULL; > +IDirect3D9 *pD3d = NULL; No need to initialize something you'll assign to anyway. > +d3d9_handle = LoadLibraryA( "d3d9.dll" ); You need to unload it when you done. > +memset(&adapter_ident, 0, sizeof(adapter_ident)); No need to clear this structure. > +StringFromGUID2(&adapter_ident.DeviceIdentifier, adapter_ident_str, > 39); Why don't you put it directly into szIdentifierBuffer? > +memcpy( szIdentifierBuffer, adapter_ident_str, > sizeof(adapter_ident_str) * sizeof(WCHAR) ); sizeof() gives size in bytes. You don't need to multiply it by sizeof(WCHAR). > +WCHAR deviceIdentBuffer[256]; First why 256 if all you need is 39? Second, why do you need it at all? There is already "buffer" which is big enough. > +DXDiag_GetDisplayDeviceIdentifier( &deviceIdentBuffer ); You don't need to take a reference from array. It's already a pointer (remove "&"). Any time you pass array like that you should also pass it's size. Vitaliy.
Re: Build wine with gcc-4.3 and ssp
On Fri, Jan 02, 2009 at 11:14:52PM +0100, Stefan Reimer wrote:
> Hi,
> to build wine using gcc 4.3 with enabled ssp (stack-smashing-protector)
> the following patch must be applied to loader/preloader.c
>
> see gcc source ./gcc/config/i386/i386.c around line 24391
>
> /* For 32-bit code we can save PIC register setup by using
>__stack_chk_fail_local hidden function instead of calling
>__stack_chk_fail directly. 64-bit code doesn't need to setup any PIC
> register, so it is better to call __stack_chk_fail directly. */
>
> Patch:
>
> diff --git a/loader/preloader.c b/loader/preloader.c
> index 5fcb974..1143972 100644
> --- a/loader/preloader.c
> +++ b/loader/preloader.c
> @@ -163,6 +163,7 @@ void __bb_init_func(void) { return; }
>
> /* similar to the above but for -fstack-protector */
> void *__stack_chk_guard = 0;
> +void __stack_chk_fail_local(void) { return; }
> void __stack_chk_fail(void) { return; }
>
> /* data for setting up the glibc-style thread-local storage in %gs */
Hmm,
why does this work for me on openSUSE then?
The line:
gcc -c -I. -I. -I../include -I../include-Wall -pipe -fno-strict-aliasing
-Wdeclaration-after-statement -Wwrite-strings -W
type-limits -Wpointer-arith -march=i586 -mtune=i686 -fmessage-length=0 -O2
-Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funw
ind-tables -fasynchronous-unwind-tables -g -o preloader.o preloader.c
works fine here. Are you passing in -fPIC?
Ciao, marcus
Re: [4/5] wined3d: Convert some BOOLs to bitfields in struct IWineD3DDeviceImpl.
2009/1/2 Rob Shearman : > How many instances of this structure are likely to be in a process at > any one time? It seems to me as though as any memory savings gained by > making the BOOLs into bitfields will be taken up by increased code > size. There is also the risk that there will be a small performance > penalty for this and the other similar changes too. > In a typical application there's only one instance of the device struct, but the fields are accessed a lot. The patch isn't so much about saving memory as it's about not wasting cachelines. The SAVEDSTATES struct, which most of the other patches modify is used a bit more, once for each stateblock. Note that that structure was initially 5448 bytes large, using up 86 64-bit cachelines. It should be possible to get that down to 3 or 4. Code size increase should be insignificant for this patch, in case of setting a flag you essentially replace a mov with an or, and testing stays mostly the same. For the SAVEDSTATES patches a couple of extra shifts are introduced, but I'm pretty sure those are worth it compared to the saved cachelines. > These kinds of optimisations need to be backed up by benchmarks, for > both memory and performance. > I did of course run some benchmarks before sending these changes in. 3DMark03 shows a small but consistent improvement. The CSS stress test doesn't get much more than a single fps improvement for the average frame rate, but that one is mostly limited by shader constant loading and sample size & rate conversion in dsound (ignoring sRGB texture loading). I didn't notice any performance regressions in any applications.
Re: question on how to do language bindings to MSHTML's COM interface
2009/1/1 Luke Kenneth Casson Leighton : > folks, hi, > i have a rather intriguing issue i'd like to look at, which takes > quite a bit of explaining as to why i'd like to go about it - if > people are interested i can answer that, but for now i'll leave it at > this: > how, under linux, would i go about making an application that made > _use_ of MSHTML.DLL's functionality, via its COM / DCE/RPC / MSRPC > interface? > in other words, if you are familiar with gecko / XUL, how would i go > about making a gecko / XUL style of application, using MSHTML as the > basis, and, once that was achieved, would it stand a chance of > successfully running under vanilla windows, using MS's own version of > MSHTML? There are a number of parts to your question: 1. Is it OK for the application to be a winelib one (i.e. invoked via or linked to wine, rather than being "native")? 2. What language are you writing the application in? 3. Pretty much all interaction with mshtml happens through COM interfaces, so which interfaces are you interested in? > yes i _am_ fully aware that, underneath, according to the wiki page on > mshtml's implementation, mshtml underneath uses Gecko - but i don't > _want_ to use the Gecko / XUL interface (mostly because it already > exists! i don't like challenges that have already been done :) > specifically, i'd _really_ like to have python bindings to the COM > bindings to MSHTML - all under linux. > so there are some _really_ weird esoteric "sub-questions" involved, such as: > "what are the chances of porting pywin32 - specifically pywin32's COM > bindings - to linux, thanks to widl and friends"? > see http://sourceforge.net/projects/pywin32 > many thanks for any advice and information. We already build a typelib for mshtml using widl and pywin32 can use that to make bindings for use at runtime, so it "should" work, but I fail to see the need for it at the moment. At some point I'd like to see a Python output generator for widl so that it can directly generate Python code that will communicate to a remote process using DCE/RPC, but that comes second place to getting the C generator as close to perfect as possible at the moment. -- Rob Shearman
Re: [4/5] wined3d: Convert some BOOLs to bitfields in struct IWineD3DDeviceImpl.
2008/12/30 Henri Verbeet : > > > From f6e4f88407491db8bb53d22d526f69b9ff761aaf Mon Sep 17 00:00:00 2001 > From: Henri Verbeet > Date: Tue, 30 Dec 2008 14:56:49 +0100 > Subject: wined3d: Convert some BOOLs to bitfields in struct > IWineD3DDeviceImpl. > > Also fills a 3 byte hole. > --- > dlls/wined3d/device.c| 17 +-- > dlls/wined3d/nvidia_texture_shader.c |2 +- > dlls/wined3d/state.c |4 +- > dlls/wined3d/wined3d_private.h | 36 > - > 4 files changed, 26 insertions(+), 33 deletions(-) How many instances of this structure are likely to be in a process at any one time? It seems to me as though as any memory savings gained by making the BOOLs into bitfields will be taken up by increased code size. There is also the risk that there will be a small performance penalty for this and the other similar changes too. These kinds of optimisations need to be backed up by benchmarks, for both memory and performance. -- Rob Shearman
Re: Ubuntu popcon trivia
Dan Kegel wrote: > Did you know that almost as many people have Wine > installed as have Sun's Java 6 installed? > > wget http://popcon.ubuntu.com/by_inst.gz > gunzip by_inst.gz > awk '/wine |sun-java6-jre/' by_inst | head > > rank name instvoteold recent old-files > 1208 sun-java6-jre 390519 68179 313376 7354 1610 (Matthias > Klose) > 1321 wine 338377 42513 282338 1346066 (Scott > Ritchie) > > The highest 'inst' value in the file is 871814, so > it looks like about 39% of machines subscribed > to popcon have wine installed. > > Whoa. That's about 4 times as high as a few months ago, percentage-wise. Thanks, Scott Ritchie
Re: Status of dxdiagn?
On Fri, Jan 2, 2009 at 7:36 AM, Markus wrote: > If my patch above is accepted, only the two b3D properties remain to be > implemented and then WiC should start fine. I don't think that is big enough > of a project. Got another game that needs dxdiagn fixes? Or they could go ahead and do dxdiag on top of dxdiagn.
Re: Status of dxdiagn?
On Thursday 01 January 2009 22:35:51 Dan Kegel wrote: > On Thu, Jan 1, 2009 at 5:13 PM, Dan Kegel wrote: > >> In order to reach support for the two acceleration properties, I have > >> just submitted an updated patch based on my code from mid-2008: > >> http://www.winehq.org/pipermail/wine-patches/2009-January/066929.html > > > > World In Conflict is affected by this, right? > > http://bugs.winehq.org/show_bug.cgi?id=4 > > Looks like it (the demo, too). Yes, World in Conflict is what I am trying to fix dxdiagn for. The szDeviceIdentifier property added by the above patch is a prerequisite to have the game continue checking for 3D capabilities of the system. If szDeviceIdentifier is not present, the check will already consider 3D not to be available. > I got the demo to start by dropping in a native dxdiagn and disabling > d3dx10 as described in the full game's howto at > http://appdb.winehq.org/objectManager.php?sClass=version&iId=9237 > Sadly, I get no video other than the cursor, and I haven't > the foggiest idea of how to quit the game, so I have to kill > it from another terminal. The game used to run very well with previous versions of Wine. I am seeing the black screen too with HEAD, so this is possibly an unrelated recent regression. As long as the game starts, you're ok in regard to dxdiagn. > This is promising, though. The student could have the goal > of fixing dxdiagn so that wic's demo starts. If my patch above is accepted, only the two b3D properties remain to be implemented and then WiC should start fine. I don't think that is big enough of a project. -- Markus
REALLY EXCITING! wine iexplore.exe http://pyjs.org/examples/
aww folks - bless you :) if all of these worked, then it means that mshtml is coming along _really_ well! i went through the kitchen sink example, and it passed - everything - with flying colours. the library unit test - passes everything! even the SVG canvas (in the addons) works! i was _just_ about to get _really_ excited, when i ran the JSONRPC example, but aw, i got this: fixme:mshtml:nsUploadChannel_SetUploadStream Unsupported aContentType argument: "application/x-www-form-urlencoded" darn, darn :) if that had worked first time, it would have been _unbelievable_ - and _so_ exciting. i liked especially the way that internet explorer is detected as Mozilla-compatible. to support IE's javascript features _would_ perhaps bit a _little_ too much :) but the real purpose of this message is to say WELL ING DONE! l.
Re: Testing DIB Engine (second part)
Roderick Colenbrander ha scritto: >> I haven't still any clue if the way I started the DIB engine has the >> correct approach, I mean if I should follow this way with the hope to >> have it included in main tree or not Can please somebody tell me >> something about ? >> >> Ciao >> >> Max >> > > I would recommend you to visit #winehackers and start asking there. AJ is > there too. I believe it was mentioned at WineConf that also Jesse his design > wasn't good. > > Roderick Well, my design is a mix between Jesse's and Huw's ones, more the latter than the former. BTW, both designs are similars in concept. Well I'll wait for some more suggestions :-) Thank you for answer Ciao Max
Re: Testing DIB Engine (second part)
> I haven't still any clue if the way I started the DIB engine has the > correct approach, I mean if I should follow this way with the hope to > have it included in main tree or not Can please somebody tell me > something about ? > > Ciao > > Max > I would recommend you to visit #winehackers and start asking there. AJ is there too. I believe it was mentioned at WineConf that also Jesse his design wasn't good. Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Re: Testing DIB Engine (second part)
I haven't still any clue if the way I started the DIB engine has the correct approach, I mean if I should follow this way with the hope to have it included in main tree or not Can please somebody tell me something about ? Ciao Max
