Re: Get font file (full) path from HFONT
Dmitry Timoshkov ha scritto: Massimo Del Fedele m...@veneto.com wrote: In order to use Freetype library I need to get font file full path from an HFONT handle. Is there a simple way to do it or should I scan the registry/font dirs to pair font faces/font paths ? Do you need this under Wine? In the app code, or Wine code? For which purpose? It was in wine code, for my dib driver. But it's (to some extent) solved by examining gdiFont list passed by SetFont() function, it already contains an FT_Font handle for every used font (I think). Weird way to do it, but I couldn't find any simpler one BTW, I still don't understand the purpose of gdiFont parameter, and in which cases it can be null. Ciao Max
Re: Windows version autodetection
On Sun, Dec 21, 2008 at 4:14 AM, Damjan Jovanovic damjan@gmail.com wrote: The bulk download would only work if you install applications to their default location, but it seems like a good idea. Not necesarily. This is where sha1sums/file name/file size are useful.
Re: Patchwatcher offline?
On Sat, Dec 20, 2008 at 7:03 PM, Francois Gouget fgou...@free.fr wrote: On Sat, 20 Dec 2008, Paul Vriens wrote: IneedAname wrote: Looks like Patchwatcher has being offline from 09-Dec-2008. Did I miss something or did someone trip over the mains cable? http://www.winehq.org/pipermail/wine-devel/2008-December/071059.html Well, obviously that's more than a day (I'm not complaining, just saying the above post may not explain everything). -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't. I had asked Dan a couple days ago, he's been busy with work, sick kid, holidays, etc. Probably needs a few days for things to calm down, and a nice cold beer :-). -- -Austin
Re: [2/2] mshtml: Add VT_INT support in IHTMLElementCollection_item
Hi, Jacek!
On Friday 19 December 2008 18:04:45 Jacek Caban wrote:
You're duplicating the code that handles VT_I4 case. Please avoid it.
Do you think, this code will be better? And can I truncate VT_I4 from trace?
if(V_VT(name) == VT_I4 || V_VT(name) == VT_INT) {
int i;
if (V_VT(name) == VT_I4) {
i = V_I4(name);
TRACE(name is VT_I4: %d\n, i);
}
else {
i = V_INT(name);
TRACE(name is VT_INT: %d\n, i);
}
if(i 0)
return E_INVALIDARG;
if(i = This-len)
return S_OK;
*pdisp = (IDispatch*)This-elems[i];
IDispatch_AddRef(*pdisp);
TRACE(Returning pdisp=%p\n, pdisp);
return S_OK;
}
And about my test for this problem - it's OK?
--
Best regards,
Konstantin Kondratyuk.
Re: Windows version autodetection
Am 22.12.2008 um 05:16 schrieb Chris Robinson: On Sunday 21 December 2008 07:48:58 pm Damjan Jovanovic wrote: The heuristic isn't app works on this Windows version, it's app is designed for this Windows version. Should that matter? Plenty of Win95 apps will work in WinXP. ... because WinXP has such a version heuristic already in place? I think it's perfectly possible to do an heuristic which is sometimes useful, but never harms. As already mentioned, the age of the installer/installed files is such a data point: Apps written in 1996 are never ever designed to run on WinXP. It's a matter of being conservative enough. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
winehq.org language selection suggestion
Hi, instead of having the change language link at the bottom of the main page, why not display the country flags directly and shade the ones that are inactive (or find some other way of indicating the active one)? Then non-english users had a better clue that language options are available at all and wouldn't have to figure out what change language means ;-) Cheers, -Maik
Re: Windows version autodetection
2008/12/22 Markus Hitter m...@jump-ing.de: Am 22.12.2008 um 05:16 schrieb Chris Robinson: Should that matter? Plenty of Win95 apps will work in WinXP. ... because WinXP has such a version heuristic already in place? I think it's perfectly possible to do an heuristic which is sometimes useful, but never harms. As already mentioned, the age of the installer/installed files is such a data point: Apps written in 1996 are never ever designed to run on WinXP. It's a matter of being conservative enough. You could possibly do that for Windows 95 applications (unless the application was written for Windows 3.1 and released in 96), and put an upper version limit on the application, but that doesn't mean that it will work best using the latest version of Windows as reported by Wine. The same goes for applications released after Vista was released, but only work well on XP. The date heuristic will say Vista, but the application will fall over if it is not designed for some of Vista's behaviour. For Wine, this may not be too big an issue as Wine tries to work as any version of Windows, so shouldn't differ in behaviour. Also, it does not matter how well the application works on a Windows box, but how well it currently runs on Wine. If an application supports Vista, but is making some calls that Wine does not support yet, the application is going to break if the Windows version is reported as Vista. Similarly if the application supports XP and GDI+ or themes, but has a fallback path for 2000 and happens to call an API that is missing or broken on Wine. Older applications designed for earlier versions of Windows are more likely to work on Wine, as it is designed to be version independent and doesn't completely change it's implementation with every other release. The only case where this will not work is if the application writers have got the version detection logic wrong and bail out. The main issue is for applications written for newer versions of Windows, or Windows components that are not yet supported, or not completely supported in Wine. These applications may work when set to earlier versions of Windows because they have a fallback to support older versions. - Reece
Re: Windows version autodetection
Am 22.12.2008 um 11:51 schrieb Reece Dunn: The same goes for applications released after Vista was released, but only work well on XP. The date heuristic will say Vista, ... just like the current-heuristic-less assumption. Undoubtly, there are many cases where a date heuristic doesn't help, but it won't worsen matters either. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Re: Windows version autodetection
On Sunday 21 December 2008 07:48:58 pm Damjan Jovanovic wrote: The heuristic isn't app works on this Windows version, it's app is designed for this Windows version. Should that matter? Plenty of Win95 apps will work in WinXP. ... because WinXP has such a version heuristic already in place? I think it's perfectly possible to do an heuristic which is sometimes useful, but never harms. As already mentioned, the age of the installer/installed files is such a data point: Apps written in 1996 are never ever designed to run on WinXP. It's a matter of being conservative enough. The way Windows solves application compatibility is way, way, way more involved then a date check or checking the build id an app. Basically microsoft ships its own 'appdb' which contains the windows version an app wants to see and in general much, much more things. For instance their appdb allows windows to override the return values of functions, it can fake the presence of certain files/directories/registry keys, it can perform memory hacks and so on. Adding an automatic mechanism to Wine creates much more issues thant it solves. If someone wants to create something like this the best thing would be to have a proper appdb which can somehow be exported to lets say a xml file. Just look for a page on windows application compatibility / shim engine and you see how huge it is. (http://technet.microsoft.com/en-us/library/bb457032.aspx for instance see the application management console shot there) Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (redux)
Hmm... Wouldn't this bug also affect surfaces without a PBO? -Original Message- From: wine-patches-boun...@winehq.org [mailto:wine-patches- boun...@winehq.org] On Behalf Of Nick Burns Sent: Sunday, December 21, 2008 12:36 PM To: wine-patc...@winehq.org Subject: [PATCH] Fix glReadPixels call from read_from_framebuffer (redux) This is a resubmission of my previous patch I fixed the issues Jeff found 1 - email address in the patch file/git 2 - move declartions to block beginning (no warnings now) 3 - hotmail spacing (well i think this is as good as I can make it...) This is my last gfx fix for SHOGO (now its quite legible and playable) The readpixels call was putting data into the wrong place in the pbo (fixed with pixelstore) And the y-flip code was flipping the wrong data as well (set the bottom row to the bottom row and not the height'th row) The code handled fullscreen 2d blits (or blts without any colorkey masking) correctly However sub-blits had issues (in the pbo path) 1 - readpixels read into the wrong part of the pbo (as a line and not a rect) 2 - the y-flip code would move around the uninited data (from the readpixels) and it read from the wrong place 3 - After 1 and 2 the pbo is corrupt and the blt code had no chance... This patch fixes 1 and 2 -- letting the blt code shine This can be seen in the SHOGO menu (now not corrupt!) Changelog Fix glReadPixels call from read_from_framebuffer Fix the call to readpixels so that 2d blts going thru the pbo path end up in the right place and get flipped correctly - Nick
Re: Windows version autodetection
2008/12/22 Roderick Colenbrander thunderbir...@gmx.net Basically microsoft ships its own 'appdb' which contains the windows version an app wants to see and in general much, much more things. For instance their appdb allows windows to override the return values of functions, it can fake the presence of certain files/directories/registry keys, it can perform memory hacks and so on. Something like that, not necessarily as a core part of wine but a side project in the manner of winetricks, might actually be a good idea from a user's point of view. A wine app launcher that maintains a list of known applications and the compatibility tweaks that are required in order to get them to run, or at least offer sensible advice (eg, where an app requires a native dll that is missing in order to work correctly). Its database would, I guess, be against app name and wine version, and then as wine improved it would need to do less and less. -- Chris
Re: Windows version autodetection
Markus Hitter m...@jump-ing.de writes: Am 22.12.2008 um 11:51 schrieb Reece Dunn: The same goes for applications released after Vista was released, but only work well on XP. The date heuristic will say Vista, ... just like the current-heuristic-less assumption. Undoubtly, there are many cases where a date heuristic doesn't help, but it won't worsen matters either. It definitely will. There are many cases where reporting Win9x even for an old app will actually break things, because we don't (and can't) implement the Win9x architecture. -- Alexandre Julliard julli...@winehq.org
Re: bugfix: resend: fix serial_flush
Wolfgang Walter w...@stwm.de writes:
@@ -201,7 +202,17 @@ static void serial_flush( struct fd *fd, struct event
**event )
/* MSDN says: If hFile is a handle to a communications device,
* the function only flushes the transmit buffer.
*/
-if (tcflush( get_unix_fd(fd), TCOFLUSH ) == -1) file_set_error();
+/* FlushFileBuffers does NOT have the semantics of tcflush.
+ * Whereas tcflush discards any data not yet transmitted
+ * FlushFileBuffers ensures they are written out.
+ * The POSIX equivalent is tcdrain
+ */
+while (tcdrain( get_unix_fd(fd)) == -1) {
+ if (errno != EINTR) {
+file_set_error();
+return;
+}
This will block, you can't do that in the server.
--
Alexandre Julliard
julli...@winehq.org
Re: wine.inf: Create fake pidgen.dll.
Hans Leidekker h...@codeweavers.com writes: The ie7 installer makes this call: LoadLibraryExA(C:\\windows\\system32\\pidgen.dll, 0, LOAD_LIBRARY_AS_DATAFILE) which fails if the file doesn't exist. No, it should work just fine. You shouldn't need a fake library for that. -- Alexandre Julliard julli...@winehq.org
Re: [02/10] wintrust: Convert crypt tests to Unicode.
Hans Leidekker h...@codeweavers.com writes: diff --git a/dlls/wintrust/tests/crypt.c b/dlls/wintrust/tests/crypt.c index 6811fd4..41cb39a 100644 --- a/dlls/wintrust/tests/crypt.c +++ b/dlls/wintrust/tests/crypt.c @@ -27,8 +27,8 @@ #include wine/test.h -static char selfname[MAX_PATH]; -static CHAR CURR_DIR[MAX_PATH]; +static WCHAR selfname[MAX_PATH]; +static WCHAR current_dir[MAX_PATH]; Is that really useful? It seems to me it will break the tests on Win9x for no good reason. -- Alexandre Julliard julli...@winehq.org
Re: [07/10] wintrust: Implement CryptCATEnumerateMember.
Hans Leidekker h...@codeweavers.com writes:
@@ -496,12 +496,208 @@ BOOL WINAPI CryptCATClose(HANDLE hCatalog)
return TRUE;
}
+static BOOL guid_from_string(const WCHAR *str, GUID *guid)
+{
+unsigned int i = 0;
+unsigned char *b = (unsigned char *)guid;
+const WCHAR *p = str;
Please call one of the existing functions for this instead of
reinventing the wheel.
--
Alexandre Julliard
julli...@winehq.org
Re: [02/10] wintrust: Convert crypt tests to Unicode.
On Monday 22 December 2008 14:54:28 Alexandre Julliard wrote: -static char selfname[MAX_PATH]; -static CHAR CURR_DIR[MAX_PATH]; +static WCHAR selfname[MAX_PATH]; +static WCHAR current_dir[MAX_PATH]; Is that really useful? It seems to me it will break the tests on Win9x for no good reason. Well, wintrust is a Unicode only API and we already skip the tests if wintrust is not fully supported. -Hans
Re: [07/10] wintrust: Implement CryptCATEnumerateMember.
On Monday 22 December 2008 14:55:29 Alexandre Julliard wrote:
+static BOOL guid_from_string(const WCHAR *str, GUID *guid)
+{
+unsigned int i = 0;
+unsigned char *b = (unsigned char *)guid;
+const WCHAR *p = str;
Please call one of the existing functions for this instead of
reinventing the wheel.
I did that at some point but it seemed overkill to me to import
ole32 for just one function. I'll change it.
-Hans
RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (redux)
'You are correct sir' I just disabled PBO on my wine build and ran SHOGO The poor menu system was all garbled... (the same issue that the pbo path had) I cleaned-up my patch and made it apply in general (to both paths) Now SHOGO looks good under both paths Good catch and thanks -- I will re-resubmit my patch - Nick From: ste...@codeweavers.com To: wine-devel@winehq.org; wine-patc...@winehq.org Subject: RE: [PATCH] Fix glReadPixels call from read_from_framebuffer (redux) Date: Mon, 22 Dec 2008 13:05:36 +0100 Hmm... Wouldn't this bug also affect surfaces without a PBO? -Original Message- From: wine-patches-boun...@winehq.org [mailto:wine-patches- boun...@winehq.org] On Behalf Of Nick Burns Sent: Sunday, December 21, 2008 12:36 PM To: wine-patc...@winehq.org Subject: [PATCH] Fix glReadPixels call from read_from_framebuffer (redux) This is a resubmission of my previous patch I fixed the issues Jeff found 1 - email address in the patch file/git 2 - move declartions to block beginning (no warnings now) 3 - hotmail spacing (well i think this is as good as I can make it...) This is my last gfx fix for SHOGO (now its quite legible and playable) The readpixels call was putting data into the wrong place in the pbo (fixed with pixelstore) And the y-flip code was flipping the wrong data as well (set the bottom row to the bottom row and not the height'th row) The code handled fullscreen 2d blits (or blts without any colorkey masking) correctly However sub-blits had issues (in the pbo path) 1 - readpixels read into the wrong part of the pbo (as a line and not a rect) 2 - the y-flip code would move around the uninited data (from the readpixels) and it read from the wrong place 3 - After 1 and 2 the pbo is corrupt and the blt code had no chance... This patch fixes 1 and 2 -- letting the blt code shine This can be seen in the SHOGO menu (now not corrupt!) Changelog Fix glReadPixels call from read_from_framebuffer Fix the call to readpixels so that 2d blts going thru the pbo path end up in the right place and get flipped correctly - Nick
Re: [02/10] wintrust: Convert crypt tests to Unicode.
Hans Leidekker h...@codeweavers.com writes: On Monday 22 December 2008 14:54:28 Alexandre Julliard wrote: -static char selfname[MAX_PATH]; -static CHAR CURR_DIR[MAX_PATH]; +static WCHAR selfname[MAX_PATH]; +static WCHAR current_dir[MAX_PATH]; Is that really useful? It seems to me it will break the tests on Win9x for no good reason. Well, wintrust is a Unicode only API and we already skip the tests if wintrust is not fully supported. Wintrust being Unicode doesn't mean the rest of the system has to be. The tests currently run (with some errors) on WinME. -- Alexandre Julliard julli...@winehq.org
Re: [07/10] wintrust: Implement CryptCATEnumerateMember.
Hans Leidekker h...@codeweavers.com writes:
On Monday 22 December 2008 14:55:29 Alexandre Julliard wrote:
+static BOOL guid_from_string(const WCHAR *str, GUID *guid)
+{
+unsigned int i = 0;
+unsigned char *b = (unsigned char *)guid;
+const WCHAR *p = str;
Please call one of the existing functions for this instead of
reinventing the wheel.
I did that at some point but it seemed overkill to me to import
ole32 for just one function. I'll change it.
You can always use RtlGUIDFromString or something like that.
--
Alexandre Julliard
julli...@winehq.org
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
On Sun, Dec 21, 2008 at 9:22 PM, Zach Drayer z...@drayer.name wrote: Can we convince Mike and Zach to switch names to just plain Wine? I'd have no problems switching over to just using Wine instead of Darwine. Also, maybe Jim White or someone else that actually developed Darwine could comment? All I do is package it.. and even the, I haven't really had time to do so recently. FWIW, I'm building 1.1.11 right now though. I asked Jim White (who's an old friend of mine from early LAJUG days) whether I was right to assume that Darwine referred to the original powerpc project with an x86 emulator hooked up to it, and whether Wine for Mac OS X x86 should just be called Wine, and he said: Yes, of course. Darwine is quite quiescent, but I think it did some real good in getting the Wine port to Mac started... BTW, Zach, do you apply any patches as you package it? - Dan
Re: Functions that should be static
Francois Gouget a écrit :
On Sat, 20 Dec 2008, Christian Costa wrote:
[...]
If you have a class A (with methods implemented in file 1) that inherits from
another class B (methods in file B).
The class A may overrides some methods of B which may become unused if B is
never instanciated and B methods not reused.
They will be tracked by your script then.
We could make these functions static or worst remove then but from object
programming pov is not good.
I don't see any reason not to make the methods of B static, whether
class A exists or not. Note that 'static' does not prevent a function
from being called from another object file if you give a pointer to them
to that other file (as you do with the virtual table).
Also the compiler will not complain that these functions are unused
because they are indeed used: you take their address.
Yes. That's right we can pick the function address from a vtable but in
that case
we cannot build another one statically as we use to i.e :
const IPinVtbl MyInputPin_Vtbl = {
InputPin_Vtbl.QueryInterface, = not a constant
MyInputPin_AddRef,
...
}
The compiler will complain this is not a constant. We could never build
a vtable statically except for the top base class.
And how could we build a vtable dynamically from another one which is
also build dynamically ?
I guess, we need to rely on constructor of the parent class which will
call in turn his own parent and so on. This is a big change.
Maybe it's off topic, but msvcirt exports methods as well as vtables. I
don't know how all of this works !
Re: question about translating winehq.org
Currently you cannot. Sometime I will look into making the site theme translatable. -Newman Maik Schulz wrote: Hi, how can I translate the top navigation bar (Forums would be Foren in German) and the word Search (would be Suche in German) next to the search box? Cheers, -Maik
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
On Sun, Dec 21, 2008 at 9:50 AM, Dan Kegel d...@kegel.com wrote: Say, http://www.kronenberg.org/darwine/ seems to be a popular source of nearly up to date wine builds for the mac. How about we link to it from http://winehq.org/download/ ? Furthermore, are his packages good enough to support? If so, how 'bout we ask him to add links to bugzilla and the appdb from his page? It currently has a few 'OS X-isms'. The patch that causes 100% cpu usage on SSL sites in IE6 is reverted, as well as a few x11 hacks. The other main problem is fonts. I think we need to fix the X11 hacks needed before doing considering it 'official' wine. We don't want a flood of bug reports for that problem. -- -Austin
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
-Original Message- From: Dmitry Timoshkov dmi...@codeweavers.com Sent: Dec 21, 2008 10:45 PM To: Dan Kegel d...@kegel.com, Roderick Colenbrander thunderbir...@gmx.net Cc: wine-devel@winehq.org, z...@drayer.name, ies4...@kronenberg.org Subject: Re: Linking to a Mac OS X build of Wine from winehq.org/download ? Dan Kegel d...@kegel.com wrote: On Sun, Dec 21, 2008 at 8:27 AM, Roderick Colenbrander thunderbir...@gmx.net wrote: Say, http://www.kronenberg.org/darwine/ seems to be a popular source of nearly up to date wine builds for the mac. How about we link to it from http://winehq.org/download/ ? Furthermore, are his packages good enough to support? If so, how 'bout we ask him to add links to bugzilla and the appdb from his page? Most importantly we need to get rid of the Darwine name. It causes a lot of unneeded confusion. Yes, I would like to keep Darwine as the name of the old powerpc project that combined an x86 emulator and wine. Can we convince Mike and Zach to switch names to just plain Wine? And change the licencing conditions to LGPL, currently that page states Darwine and wine are released under the gpl. They also have to remove any differences between WineHQ sources and their ones, otherwise it can't be supported via WineHQ. Dan and Dmitry: What I would like to see is the changes made by Zach and Mike incorporated back into the main Wine code. Both Mike and Zach have approached building Wine releases in the two structures supported by Apple: Drag and Drop where you grab a pre-built Application object and move it into the Applications folder and the use of the Apple installer with an installable 'package' much like the use of apt or yum. There is great debate as to which is the best approach and, basing this on the struggle within and outside of the OpenOffice.org/NeoOffice.org MacOSX porting projects, I would like to avoid this problem as best we can. Firefox and Thunderbird use the first approach, but many projects use the latter. The Wine project should pick one as the formally supported installation method and allow others to support the second. I don't have a favorite, as deinstallation of the program is easy and involves an additional step when using the second installation method. Again, restating my first sentence in the last paragraph is that we need to bring back into the Main Wine codebase those changes needed to successfully complete a build on the Intel MacOSX system. Darwine should remain a project for incorporating the x86 emulator, Qemu and Wine. This should reduce MacOSX user confusion and get all of the pieces together. Further work may be required to fully support all functionality of the Wine project, such as font support, as time progresses. James McKenzie
Re: Linking to a Mac OS X build of Wine from winehq.org/download ?
Yes, I would like to keep Darwine as the name of the old powerpc project that combined an x86 emulator and wine. Can we convince Mike and Zach to switch names to just plain Wine? I'd have no problems switching over to just using Wine instead of Darwine. Also, maybe Jim White or someone else that actually developed Darwine could comment? All I do is package it.. and even the, I haven't really had time to do so recently. FWIW, I'm building 1.1.11 right now though. -Zach
Re: [06/10] wintrust: Implement CryptCATOpen and CryptCATClose.
Hi Hans, this is a really minor comment:
+struct cryptcat
+{
+DWORD magic;
+HANDLEmsg;
msg's type should be HCRYPTMSG instead.
+for (i = 0; i cc-attr_count; i++)
+{
+if (!CryptMsgGetParam(hmsg, CMSG_ATTR_CERT_PARAM, i, NULL, size))
Out of curiosity, how did you test this?
--Juan
Re: [06/10] wintrust: Implement CryptCATOpen and CryptCATClose.
On Monday 22 December 2008 16:59:29 Juan Lang wrote:
+struct cryptcat
+{
+DWORD magic;
+HANDLEmsg;
msg's type should be HCRYPTMSG instead.
Thanks for catching that.
+for (i = 0; i cc-attr_count; i++)
+{
+if (!CryptMsgGetParam(hmsg, CMSG_ATTR_CERT_PARAM, i, NULL,
size))
Out of curiosity, how did you test this?
That would be a question for Maarten since he mostly wrote this code.
-Hans
Re: [06/10] wintrust: Implement CryptCATOpen and CryptCATClose.
Out of curiosity, how did you test this? That would be a question for Maarten since he mostly wrote this code. Well, last he asked me about it, I hadn't had a chance to look at attribute certs in messages yet (they're stubbed out.) That's why I was curious ;-) --Juan
Re: RFC: Proposed new web site design
Hey Tom, That was slick, the mock up listed Bordeaux under third party apps and when the site went live it was somehow removed :D Well, the mockup had a fairly crummy presentation of Bordeaux; I meant to ask Steven to submit a better put together version, with nicer graphics and such, but I forgot. Hopefully this will serve for that. Cheers, Jeremy
Re: d3d9 patch include a test needs testing in windows
On Sun, Dec 21, 2008 at 10:58 AM, Pauli Nieminen suok...@gmail.com wrote: Hi! I have tried to get Civ4 running in my machine and successed with some minor wine modifications but this patch needs testing in windows how d3d9 handles this case in there. Preferable test system should be include graphic card that supports some but not all shader versions. (That means readeon 8500+ and Geforce 3/4+). I think it should be ok to run in any windows version if there is just dx9 installed. Patch set includes 3 patches but you realy only need to apply the test portion of 2nd patch. The latest patch version is available at http://repe.ath.cx/wine/ and bug report is http://bugs.winehq.org/show_bug.cgi?id=16444 . Thanks for help. Pauli C:\Documents and Settings\Austin\Desktopd3d9_crosstest.exe shader shader.c:193: SetPixelShaderConstantF was able to set 224 shader constants shader: 16 tests executed (0 marked as todo, 0 failures), 0 skipped. C:\Documents and Settings\Austin\Desktopd3d9_crosstest_new.exe shader shader.c:96: Test failed: Vertex shader (0xfffe02ff) creation succesed but d3dcaps claim not to support it. hret = 0x0, vshader_ptr = 00259740 shader.c:92: Test failed: Vertex shader (0xfffe0300) creation failed but d3dcaps claim to support it. hret = 0x8876086c, vshader_ptr = shader.c:115: Test failed: Pixel shader (0x0300) creation failed but d3dcaps claim to support it. hret = 0x8876086c, pshader_ptr = shader.c:432: SetPixelShaderConstantF was able to set 224 shader constants shader: 33 tests executed (0 marked as todo, 3 failures), 0 skipped. This was with a Nvidia GeForce 7600 GT. -- -Austin
Re: ntdll: fix a compiler warning on PC-BSD
On Sun, Dec 21, 2008 at 3:33 AM, Francois Gouget fgou...@free.fr wrote: I'm a bit surprised that PC-BSD/FreeBSD's mkdir() does not take a mode argument. Are you sure this is really the case? Maybe we are just mising a #include directive on BSD? (Unfortunately I don't really have access to a FreeBSD box right now) -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands. I didn't investigate further, Alexandre committed a fix: http://source.winehq.org/git/wine.git/?a=commitdiff;h=921e6624ad63a026b27753c3ae06f931c6d65eba -- -Austin
Re: New Gecko package - call for tests
On Sun, Dec 21, 2008 at 4:49 PM, Jacek Caban ja...@codeweavers.com wrote: Hi, I've released first (and hopefully last) RC build of new Gecko package and attached a patch against current Wine Git to bug 16198 http://bugs.winehq.org/show_bug.cgi?id=16198 It's critical to make sure, that there will be no regressions due to the new Gecko, it'd much more work to fix such regression than a usual regressions. I'd appreciate any help with testing it. Instructions how to do it are in the bug report. Any application that uses MSHTML is worth testing, esp ones that extensively use it. I will write more about the new release and future plans later in an other subject. Thanks, Jacek (Let me know if you'd prefer to discuss this in the bug report instead) The patch didn't apply cleanly against today's wine-git. Can you regenerate the patch? I tried applying the patch by hand, compiled, but running wine iexplore causes a crash. Maybe I didn't apply the patch correctly?
Re: New Gecko package - call for tests
Hi Lei, Lei Zhang wrote: (Let me know if you'd prefer to discuss this in the bug report instead) It doesn't matter for me. The patch didn't apply cleanly against today's wine-git. Can you regenerate the patch? That was because it contained a few patches that were committed today. I've attached a new patch. I tried applying the patch by hand, compiled, but running wine iexplore causes a crash. Maybe I didn't apply the patch correctly? That may be the reason. Thanks! Jacek
MSVCP80 implementation
Hi all, I'm attempting to get software to run which requires some functions in MSVCP80 to be implemented. Using the original DLLs is not an option for us. In particular, a couple of the allocator functions are being called (msvcp80.dll.??0?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@xz to give one such example). I am sure there are more after this is fixed too. Browsing the WINE source, I found references to some similarly mangled functions in MSVCRT (the stream classes), but they did not seem to be actually implemented: in msvcrt/tests/cpp.c there was a demangling test, but I didn't find much else that was directly related. So, my question is how WINE handles calls to any STL or C++ library functions which may be included in these DLLs, and what approach I should use to implement or forward calls to these kinds of functions. Any help would be much appreciated. Thanks in advance, Louis Gorenfeld Muse Research
Re: [RFC] wined3d: Avoid triggering OPENGL errors when setting point size
2008/12/23 Vincent Pelletier plr.vinc...@gmail.com: If WINED3DRS_POINTSCALEENABLE is false and WINED3DRS_POINTSIZE render state is set to an invalid size, glPointSize will fail. This happens in Black White 2, causing log/stderr to be flooded with opengl errors. I'm not sure if this should be fixed here, or when setting state value. Also, maybe it should be avoided to double-check against opengl bounds when WINED3DRS_POINTSCALEENABLE is true. I think it makes more sense to clamp the value to be within the limits, rather than using whatever was used last.
Re: bugfix: resend: fix serial_flush
On Monday 22 December 2008, Alexandre Julliard wrote:
Wolfgang Walter w...@stwm.de writes:
@@ -201,7 +202,17 @@ static void serial_flush( struct fd *fd, struct event
**event )
/* MSDN says: If hFile is a handle to a communications device,
* the function only flushes the transmit buffer.
*/
-if (tcflush( get_unix_fd(fd), TCOFLUSH ) == -1) file_set_error();
+/* FlushFileBuffers does NOT have the semantics of tcflush.
+ * Whereas tcflush discards any data not yet transmitted
+ * FlushFileBuffers ensures they are written out.
+ * The POSIX equivalent is tcdrain
+ */
+while (tcdrain( get_unix_fd(fd)) == -1) {
+ if (errno != EINTR) {
+file_set_error();
+return;
+}
This will block, you can't do that in the server.
--
Alexandre Julliard
julli...@winehq.org
Would it be acceptable to call tcdrain directly in NtFlushBuffersFile:
=
NTSTATUS WINAPI NtFlushBuffersFile( HANDLE hFile, IO_STATUS_BLOCK*
IoStatusBlock )
{
NTSTATUS ret;
HANDLE hEvent = NULL;
enum server_fd_type type;
NTSTATUS status;
unsigned int options;
int needs_close;
int unix_handle;
status = server_get_unix_fd( hFile, FILE_WRITE_DATA, unix_handle,
needs_close, type, options );
if (type == FD_TYPE_SERIAL) {
while (tcdrain(unix_handle) == -1) {
if (errno != EINTR) {
return FILE_GetNtStatus();
}
}
return STATUS_SUCCESS;
}
SERVER_START_REQ( flush_file )
{
req-handle = wine_server_obj_handle( hFile );
ret = wine_server_call( req );
hEvent = wine_server_ptr_handle( reply-event );
}
SERVER_END_REQ;
if (!ret hEvent)
{
ret = NtWaitForSingleObject( hEvent, FALSE, NULL );
NtClose( hEvent );
}
return ret;
}
=
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Leiter EDV
Leopoldstraße 15
80802 München
Re: MSVCP80 implementation
lo...@museresearch.com wrote: Hi all, I'm attempting to get software to run which requires some functions in MSVCP80 to be implemented. You need to install msvc2005 redistributable runtime. The simplest way is using winetricks: http://wiki.winehq.org/winetricks Implementing all that is a huge waste of time. Vitaliy.
Re: MSVCP80 implementation
Vitaliy Margolen wrote: lo...@museresearch.com wrote: Hi all, I'm attempting to get software to run which requires some functions in MSVCP80 to be implemented. You need to install msvc2005 redistributable runtime. The simplest way is using winetricks: http://wiki.winehq.org/winetricks Implementing all that is a huge waste of time. Legally speaking, we should start implementing all of the functions in the Win32/Win64 API. Louis: If you feel that you have the technical capabilities and can understand the method of implementing code in a clean room environment, please go ahead and start working on this. Remember, test cases first that prove what the Win32/64 API does with this dll as implemented through Windows and then code the dll's functions. Remember: You cannot do this if you EVER looked at Windows code for this dll or attempt to reverse engineer it. There are many legal reasons for this, the biggest is that Microsoft can attempt to shutdown this project. For now, Vitally's suggestion is what we are using to implement this dll's functionality. James McKenzie
Re: Patchwatcher offline?
Austin English wrote: On Sat, Dec 20, 2008 at 7:03 PM, Francois Gouget fgou...@free.fr wrote: On Sat, 20 Dec 2008, Paul Vriens wrote: IneedAname wrote: Looks like Patchwatcher has being offline from 09-Dec-2008. Did I miss something or did someone trip over the mains cable? http://www.winehq.org/pipermail/wine-devel/2008-December/071059.html Well, obviously that's more than a day (I'm not complaining, just saying the above post may not explain everything). -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't. I had asked Dan a couple days ago, he's been busy with work, sick kid, holidays, etc. Probably needs a few days for things to calm down, and a nice cold beer :-). I'd be willing to help with the last item. :-) Kids, I'm not so good with, especially sick ones. BTW, I passed the exam at the end of four weeks of classes, that means I'm certified... James McKenzie
Re: winecfg: Disable nonfunctional advanced drive settings
On Tue, Dec 23, 2008 at 2:36 AM, M.Kiesel wine-de...@continuity.cjb.net wrote: In the winecfg drive tab, advanced drive settings (setting label and serial) seem to be broken currently due to other Wine bugs (see drive.c apply_drive_changes comments). Disable these settings for now since this only confuses users. Changelog: winecfg: Disable nonfunctional advanced drive settings Rather than disable it and cause more confusion when it does work, focus on fixing the actual bug instead. -- -Austin
Re: MSVCP80 implementation
James McKenzie jjmckenzi...@earthlink.net wrote: I'm attempting to get software to run which requires some functions in MSVCP80 to be implemented. You need to install msvc2005 redistributable runtime. The simplest way is using winetricks: http://wiki.winehq.org/winetricks Implementing all that is a huge waste of time. Legally speaking, we should start implementing all of the functions in the Win32/Win64 API. MSVCP80 is not a part of win32 API, that's a redistributable run-time library supposed to be provided by an application. -- Dmitry.
Re: MSVCP80 implementation
James McKenzie jjmckenzi...@earthlink.net wrote: I'm attempting to get software to run which requires some functions in MSVCP80 to be implemented. You need to install msvc2005 redistributable runtime. The simplest way is using winetricks: http://wiki.winehq.org/winetricks Implementing all that is a huge waste of time. Legally speaking, we should start implementing all of the functions in the Win32/Win64 API. MSVCP80 is not a part of win32 API, that's a redistributable run-time library supposed to be provided by an application. Dimtry: Thank you for the clarification on its use and where it should come from. I will correct then: Get it through Winetricks or insure that it is packaged with the executable. James McKenzie
Re: winecfg: Disable nonfunctional advanced drive settings
On Tue, 23 Dec 2008, Austin English wrote: In the winecfg drive tab, advanced drive settings (setting label and serial) seem to be broken currently due to other Wine bugs (see drive.c apply_drive_changes comments). Disable these settings for now since this only confuses users. [...] Rather than disable it and cause more confusion when it does work, focus on fixing the actual bug instead. Sorry, impossible for me. Sure fixing the underlying bug would be nice but I'm far from experienced enough with the Wine code for doing this (if this changes in future I'll happily revert that patch). I think fixing winecfg to show only options that actually do something is something worth doing though for the time being, especially for Wine users. Also, for PR it's not too good that of the few options winecfg actually offers several are just plain broken. BTW I don't quite understand how the nonfunctional winecfg code showed up in the first place. Can I submit some Perfect Windows compatibility checkbox for winecfg and then tell the one trying to revert that to please just fix the underlying bug? :-) Regards
Re: cryptui(0/24)
Juan Lang wrote: This patch series implements the remaining portions of CryptUIWizImport, and calls it from the certificate dialog. If all of this is accepted, this is one lengthy and needed functional implementation. Good job, Juan! James McKenzie
Re: cryptui(0/24)
If all of this is accepted, this is one lengthy and needed functional implementation. Good job, Juan! Good job Seattle for having lots of snow and cancelling my flight. I had extra time on my hands :) Thanks! --Juan
how to create a broken .tlb file
Hello developers, while debugging problems with and old version of Sonic Stage, I found that sonic stage includes broken type libraries, i.e. the TYPEFLAG_FDISPATCHABLE bit is generally missing. As widl (and probably midl too) set this bit automatically, I have some problems in creating a .tlb file for a test case for my one-line patch that also misses this bit. There are some possibilities to get around the problem: a) Include a broken (hand-patched) tlb file as binary file in git b) Include a program that breaks tlb files and call it while building tests c) Include tlb file patching into the testcase (i.e. copy a good tlb, patch it, and perform some tests with the copy, than delete it) Which approach would have the highest chance of getting the fix (including the testcase that tests broken type libraries) included into Wine? Regards, Michael Karcher
