Re: Excluding a Windows version from the tests
Stefan Dösinger [EMAIL PROTECTED] writes: Shouldn't then the wine code do a version check too and behave differently if the winver is set to win98? Only if there is an app that does the same version check and depends on both behaviors. It's very unlikely that an app would want to crash when the version is win98, so we don't need to replicate that behavior. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH 18/18] XCOPY: Add help
Umm, is there a specific reason why you created the mails by replying to the previous patch? This doesn't look that good with mailers that keep track of replies and e.g. indents them. ciao Joerg
Re: [PATCH 13/18] XCOPY: Add support for /EXCLUDELIST:file1+file2 etc
Jason Edmeades [EMAIL PROTECTED] writes:
+/* Loop through testing each exclude line */
+while (pos) {
+if (wcsstr(copyFromUpper, pos-name) != NULL) {
+WINE_TRACE(Skipping file as matches exclude '%s'\n,
+ wine_dbgstr_w(pos-name));
wcsstr() doesn't seem the right way to compare file names. You
probably want to do a wcsicmp() of the end of the name or something
like that.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: winex11.drv: Remove an unnecessary XFlush().
Huw Davies [EMAIL PROTECTED] writes:
--- a/dlls/winex11.drv/xrender.c
+++ b/dlls/winex11.drv/xrender.c
@@ -596,7 +596,6 @@ void X11DRV_XRender_UpdateDrawable(X11DRV_PDEVICE
*physDev)
if(physDev-xrender-pict)
{
TRACE(freeing pict = %lx dc = %p\n, physDev-xrender-pict,
physDev-hdc);
-XFlush(gdi_display);
pXRenderFreePicture(gdi_display, physDev-xrender-pict);
physDev-xrender-pict = 0;
}
This causes a test failure here:
../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p
comctl32_test.exe.so header.c touch header.ok
X Error of failed request: BadPixmap (invalid Pixmap parameter)
Major opcode of failed request: 54 (X_FreePixmap)
Resource id in failed request: 0x2400023
Serial number of failed request: 461
Current serial number in output stream: 472
make: *** [header.ok] Error 1
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [1/2 RESEND] gdi32: Add failing metrics test for negative font widths
Felix Nawothnig [EMAIL PROTECTED] writes: Please tell me if this still fails on your box (both versions pass on mine). Now it succeeds where it shouldn't... ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c touch font.ok font.c:541: Tests skipped: Symbol is not installed so skipping this test font.c:784: Tests skipped: Arial is not installed font.c:1094: Tests skipped: Arial is not installed font.c:1228: Tests skipped: Arial Black is not installed font.c:1228: Tests skipped: Symbol is not installed font.c:1688: Tests skipped: Arial Black or Symbol/Wingdings is not installed font.c:1514: Test succeeded inside todo block: gm1=62,57,0,60,61,0 gm2=62,57,0,60,61,0 make: *** [font.ok] Error 1 -- Alexandre Julliard [EMAIL PROTECTED]
Re: Stub for all raw input functions
Kovács András [EMAIL PROTECTED] wrote:
+LRESULT WINAPI DefRawInputProc( PRAWINPUT *paRawInput, INT nInput, UINT
cbSizeHeader )
+{
+FIXME((paRawInput=%p, nInput=%d, cbSizeHeader=%d) stub!\n, *paRawInput,
nInput, cbSizeHeader);
+
+return S_OK;
+}
Although MSDN documents that on success DefRawInputProc returns S_OK,
that's most likely a misguided documenters error: S_OK is an HRESULT
and an OLE error value, while it's user32 and return type is LRESULT.
So IMO simply returning 0 should be OK here.
+BOOL WINAPI RegisterRawInputDevices( PRAWINPUTDEVICE pRawInputDevices, UINT
uiNumDevices, UINT cbSize )
+{
+FIXME((pRawInputDevices=%p, uiNumDevices=%d, cbSize=%d) stub!\n,
pRawInputDevices, uiNumDevices, cbSize);
+
+return TRUE;
+}
Probably this stub should return FALSE.
+UINT WINAPI GetRawInputBuffer( PRAWINPUT pData, PUINT pcbSize, UINT
cbSizeHeader )
+{
+FIXME((pData=%p, pcbSize=%p, cbSizeHeader=%d) stub!\n, pData, pcbSize,
cbSizeHeader);
+
+return 0;
+}
MSDN says that an error indicator is -1, not 0, same as for others raw
input APIs.
--
Dmitry.
Re: extracting info from a minidump via winedbg
2007/3/29, Dennis Schridde [EMAIL PROTECTED]: Am Donnerstag, 29. März 2007 schrieb Eric Pouech: Dennis Schridde a écrit : Hello Wine users! I've got a minidump from a (real) Windows user of our game and would like to extract information from it using winedbg. The information winedbg gives me by default, is this: [...] Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid locations in our sourcefiles. My questions are: - Why doesn't winedbg extract the sourcecode locations itself? because it needs the original PE files (.exe, .dll) to get to the debug information those files must be seated in directories listed in the _NT_SYMBOL_PATH environment variable Maybe I am just doing it wrong, but _NT_SYMBOL_PATH=. winedbg warzone2100.mdmp doesn't change anything... (Even supplying the full path doesn't.) The exe (not all dlls, because I don't have a copy of the user's system) is of course in the working directory. But the debug info is not always in the .exe itself. the .exe can contain only a pointer to the debug info what does 'winedbg -x debug -g warzone2100.exe' give ? - Why doesn't winedbg show me the other information included in the minidump, like the loaded modules, commandline options or version information? 'info share' should do part of it... winedbg doesn't show the command line info nor options That only shows me the memory ranges of some modules. The minidump includes more info, like the paths to dlls and similar. I am not sure whether it includes version information, but it certainly contains the commandline used to start the app. other thing you can do is to use winedump (man winedump) How do I do this? And what will it provide? I tried winedump -G warzone2100.exe but I have no idea what I shall do with that tremedously long and cryptic list. winedump warzone2100.mdmp - How can I get the parameters to the last called function(s)? see above for debug info If the general debug info worked, that would also show me the function parameters? yes -- Eric Pouech
RE: Jason Edmeades : xcopy: Add support for COPYCMD override and fix /-y.
Hello,
wouldn't it be nicer to use sizeof(copyCmd) here?
if (GetEnvironmentVariable(COPYCMD, copyCmd, MAXSTRING)) {
There are many spots like this in wcmdmain.c
Regards
Alex
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ext Alexandre
Julliard
+/* Preinitialize flags based on COPYCMD */
+if (GetEnvironmentVariable(COPYCMD, copyCmd, MAXSTRING)) {
+if (wcsstr(copyCmd, PROMPTSTR1) != NULL ||
+wcsstr(copyCmd, PROMPTSTR2) != NULL) {
+flags |= OPT_NOPROMPT;
+}
+}
+
Re: Excluding a Windows version from the tests
On 30.03.2007 09:14, Alexandre Julliard wrote: Stefan Dösinger [EMAIL PROTECTED] writes: Shouldn't then the wine code do a version check too and behave differently if the winver is set to win98? Only if there is an app that does the same version check and depends on both behaviors. It's very unlikely that an app would want to crash when the version is win98, so we don't need to replicate that behavior. Wasn't there some weird installshield behaviour where we had to crash like windows to make installshield happy? Regards, Carl-Daniel
Re: extracting info from a minidump via winedbg
Am Freitag, 30. März 2007 schrieb Eric Pouech: 2007/3/29, Dennis Schridde [EMAIL PROTECTED]: Am Donnerstag, 29. März 2007 schrieb Eric Pouech: Dennis Schridde a écrit : Hello Wine users! I've got a minidump from a (real) Windows user of our game and would like to extract information from it using winedbg. The information winedbg gives me by default, is this: [...] Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid locations in our sourcefiles. My questions are: - Why doesn't winedbg extract the sourcecode locations itself? because it needs the original PE files (.exe, .dll) to get to the debug information those files must be seated in directories listed in the _NT_SYMBOL_PATH environment variable Maybe I am just doing it wrong, but _NT_SYMBOL_PATH=. winedbg warzone2100.mdmp doesn't change anything... (Even supplying the full path doesn't.) The exe (not all dlls, because I don't have a copy of the user's system) is of course in the working directory. But the debug info is not always in the .exe itself. the .exe can contain only a pointer to the debug info This exe was compiled using the GCC switch -g and was not striped afterwards, it is ~10MB big (the usual size of our app when compiled in debug mode) and winedump drops a long list of I don't know what when I run winedump -G warzone2100.exe. what does 'winedbg -x debug -g warzone2100.exe' give ? Usage information... winedbg has neither a -x nor a -g parameter. winedump has a -x parameter (which takes no option) and a -G parameter. It complains about not being able to treat multiple files. So you probably meant a completely different tool... - Why doesn't winedbg show me the other information included in the minidump, like the loaded modules, commandline options or version information? 'info share' should do part of it... winedbg doesn't show the command line info nor options That only shows me the memory ranges of some modules. The minidump includes more info, like the paths to dlls and similar. I am not sure whether it includes version information, but it certainly contains the commandline used to start the app. other thing you can do is to use winedump (man winedump) How do I do this? And what will it provide? I tried winedump -G warzone2100.exe but I have no idea what I shall do with that tremedously long and cryptic list. winedump warzone2100.mdmp This is actually useful. Things like file versions, modules and so on are printed. What's still missing (and only visible in the binary listing of Memory ranges is the commandline. Are there plans to make this info accessible from winedbg? Or to include things like backtrace information into winedump? --Dennis pgpWXSBuLcPvQ.pgp Description: PGP signature
Corrupted system.reg in clustered environment - where to look?
Hello Wine developers, we try to use Wine in clustered environment with multiple Wine processes being started simultaneously on 8 to 80 Linux machines by a modified GNU make. The source code being built is located on an NFS mount visible by all cluster machines. Unfortunately Wine fails after some time because of corrupted ~/.wine/system.reg. I guess multiple Wine processes try to update some keys in that file, like (differing) processor steppings etc. and this goes wrong at some point. Also I've noticed, that the registry is being re-saved every 30 seconds (why?) - here in wine-0.9.32/server/registry.c: static const int save_period = 3; /* delay between periodic saves (in ms) */ I've tried adding file locking using fcntl() (which should work over NFS too) by modifiyng load_registry() and save_registry() as in the attached diff, but unfortunately it doesn't help. Does anybody have a hint where to look? Why updating registry is needed at all and can I disable it maybe? (And where would be the good spot to do that?) Thank you Alex registry.c.diff Description: registry.c.diff
Re: Corrupted system.reg in clustered environment - where to look?
[EMAIL PROTECTED] writes: I've tried adding file locking using fcntl() (which should work over NFS too) by modifiyng load_registry() and save_registry() as in the attached diff, but unfortunately it doesn't help. For the standard registry files you'd have to do it in load_init_registry_from_file() and save_branch(). It still won't prevent one server from overwriting changes made by others of course. Why updating registry is needed at all and can I disable it maybe? (And where would be the good spot to do that?) If you make the WINEPREFIX directory and the registry files read-only that should prevent the server from updating them. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Stub for all raw input functions
2007. március 30. 13.28 dátummal ezt írta:
Kovács András [EMAIL PROTECTED] wrote:
+LRESULT WINAPI DefRawInputProc( PRAWINPUT *paRawInput, INT nInput, UINT
cbSizeHeader ) +{
+FIXME((paRawInput=%p, nInput=%d, cbSizeHeader=%d) stub!\n,
*paRawInput, nInput, cbSizeHeader); +
+return S_OK;
+}
Although MSDN documents that on success DefRawInputProc returns S_OK,
that's most likely a misguided documenters error: S_OK is an HRESULT
and an OLE error value, while it's user32 and return type is LRESULT.
So IMO simply returning 0 should be OK here.
+BOOL WINAPI RegisterRawInputDevices( PRAWINPUTDEVICE pRawInputDevices,
UINT uiNumDevices, UINT cbSize ) +{
+FIXME((pRawInputDevices=%p, uiNumDevices=%d, cbSize=%d) stub!\n,
pRawInputDevices, uiNumDevices, cbSize); +
+return TRUE;
+}
Probably this stub should return FALSE.
I decided to return this stub TRUE, because Rayman Raving Rabbids won't start
otherwise. It won't hurt, because app just won't get WM_INPUT messages.
+UINT WINAPI GetRawInputBuffer( PRAWINPUT pData, PUINT pcbSize, UINT
cbSizeHeader ) +{
+FIXME((pData=%p, pcbSize=%p, cbSizeHeader=%d) stub!\n, pData,
pcbSize, cbSizeHeader); +
+return 0;
+}
MSDN says that an error indicator is -1, not 0, same as for others raw
input APIs.
Same as the another function, I just represent, that nothing will be returned.
This function won't be called, because app will call if it received a WM_INPUT
message.
--
Kovács András (andras)
NetClub Vezető Rendszergazda
Lamarr
csevego.net
[EMAIL PROTECTED]
re: Corrupted system.reg in clustered environment - where to look?
Alexander.Farber at nokia.com wrote: [I use wine on multiple machines with ~/.wine shared via NFS, and after a while, the registry is corrupt.] Well, if it hurts, don't do it :-) Seriously. NFS is not a good place to put WINEPREFIX. In my testing, it causes serious performance problems. And NFS file locking has been broken from day 1. They keep trying to make it work, but it's never going to make you happy. So why not take the easy way out, and put WINEPREFIX on local disk? Surely you can do this. If you really need the Wine applications to share data, you can do it by creating D: or some directory in C: as a shared folder. Just don't share everything. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Hardware cursor patch that does not break 'make test'.
Am Freitag 30 März 2007 16:36 schrieb Andrew Riedi: Here is the patch, opps, forgot to attach. On 3/30/07, Andrew Riedi [EMAIL PROTECTED] wrote: Here is an updated patch that does not break make test. Sorry about sending in a bad patch, I always saw that regular make would create stuff in /tests dir's and thought that tested stuff. :\ Anyhow, this one should be fine. changelog: wined3d: Add hardware cursor support. Wouldn't you have to restore the original cursor in device::release? In general this shouldn't matter because 99% of all applications will terminate after destroying the device, but I think we should take care of that. What happens to cursorInfo.hbmMask and cursorinfo.hbmcolor after CreateIconIndirect? Is it destroyed with the cursor, or does it leak after cursorInfo, which sits on the stack, is destroyed? pgpni8igS69ZX.pgp Description: PGP signature
Cross-Library tests, tests using multiple processes
Hi, Screen resolution setting in DirectX games is still a huge mess. I want to fix it properly finally. Write tests to find out what really happens in windows, then implement it. Unfortunately that fails at the tests already. Our test framework is mainly limited to test single DLLs, and all tests I have been used to so far were in one single process. I would have to test what happens if there is one process requesting exclusive ddraw access and once process requesting explusive d3d9 access at once, and maybe a third process doing a screen resolution change, etc. Is there a way to write a test accross multiple libraries? I guess it is not hard to do, but it would look a bit bad if a ddraw test started using d3d9 directly. And is there a prefered way to spawn new processes and do communication between them? (Windows IPC I guess). pgpVMwOxn0QyG.pgp Description: PGP signature
Re: Excluding a Windows version from the tests
Alexandre Julliard wrote:
Paul Vriens [EMAIL PROTECTED] writes:
So if we only have crashes on win9x we don't care. If we can avoid
crashes/failures on win9x (by skip or other means) we don't run them
on win9x. And if they crash on something higher then win9x we disable
them totally.
Does that make sense?
Sure; the thing we want to avoid is version checks in tests, because
then things don't get tested on Wine when the version is changed. But
as long as win98 is detected by its missing features then skipping
things is fine.
Ok, I've got an example attached. I'm currently cleaning up the registry tests
before I can/will start doing stuff with RegDeleteTree.
It turns out we had a lof of failures with this test on win98. It looks like
win98 doesn't assign a new handle when the same registry key is opened. This
means that the close test close the main handle and we thus have an issue in the
first test after that (which assumes to have a valid handle).
The attached file uses the GetVersion to check for win9x, is that acceptable in
this case? Or is just an extra RegOpenKey (with comments) enough?
The todo_wine is only there btw. to don't have an error when run in win9x
emulated mode. That brings up another question. Should all test succeed in Wine
regardless of the emulated mode?
Cheers,
Paul.
diff --git a/dlls/advapi32/tests/registry.c b/dlls/advapi32/tests/registry.c
index f67364a..eb0713b 100644
--- a/dlls/advapi32/tests/registry.c
+++ b/dlls/advapi32/tests/registry.c
@@ -619,6 +619,15 @@ static void test_reg_close_key(void)
* hkHandle remains changed after call to RegCloseKey
*/
ret = RegOpenKeyA(HKEY_CURRENT_USER, Software\\Wine\\Test, hkHandle);
+
+/* Windows 98 returns the same handle when the same key is opened.
+ * When this handle is closed effectively all handles are closed to this key.
+ */
+if (GetVersion() 0x8000)
+todo_wine ok(hkey_main == hkHandle, Expected handles to be the same\n);
+else
+ok(hkey_main != hkHandle, Expected handles to be different\n);
+
ret = RegCloseKey(hkHandle);
ok(ret == ERROR_SUCCESS, expected ERROR_SUCCESS, got %d\n, ret);
@@ -763,6 +772,12 @@ static void test_reg_query_value(void)
static const WCHAR expected[] = {'d','a','t','a',0};
+/* The test_reg_close_key test closes the handle to the main key on Win98.
+ * Open it again in this case.
+ */
+if (GetVersion() 0x8000)
+RegOpenKeyA( HKEY_CURRENT_USER, Software\\Wine\\Test, hkey_main );
+
ret = RegCreateKeyA(hkey_main, subkey, subkey);
ok(ret == ERROR_SUCCESS, Expected ERROR_SUCCESS, got %d\n, ret);
ExtTextOut with rotation and MM_ANISOTROPIC inverted coordinates
Hi,
I have a problem with rotated Text displayed by ExtTextOut after
SetMapMode(hdc, MM_ANISOTROPIC);
SetWindowExtEx(hdc, 1000, -1000, NULL);
Basically, giving one negative parameter to SetWindowExtEx should
reverse the direction (clockwise/counterclockwise) in which
rotation is done. It works in Windows, but has no effect in wine.
The patch I created uses a side effect of the WMF file I had as
test case, basically it sets lfClipPrecision = CLIP_LH_ANGLES
and triggers direction inversion based on that instead of checking
the WindowExtEx settings. That is of course wrong, but it is
available almost everywhere in the text output paths and served
me nicely as inverse rotation flag.
Instead of abusing lfClipPrecision, what should we use? The
SetWindowExtEx call sets some_matrix.eM11 to a negative value
if its first argument is negative and eM22 to a negative value
if its second argument is negative.
So checking (eM11 * eM22 0) (mapmode == MM_ANISOTROPIC)
should be the correct solution. Problem: You can't always check
these things because the dc is not available everywhere.
In case you have a GdiFont, you can check
(font-font_desc.matrix.eM11 * font-font_desc.matrix.eM22 0)
or in case you have a LOGFONT
(dc-xformWorld2Vport.eM11 * dc-xformWorld2Vport.eM22 0)
I have not tested whether the parameters of the current dc,
the parameters at the time CreateFontIndirect was run or the
parameters at the time SelectObject(hdc, hfont) was run are
responsible for the rotation inversion.
What works?
With the patch, lfClipPrecision = CLIP_LH_ANGLES has the effect
SetWindowExtEx(hdc, positivevalue, negativevalue, NULL) should
have. Exception: The text is clipped at the border, while Windows
auto-extends the borders to avoid clipping.
What doesn't work?
SetWindowExtEx(hdc, positivevalue, negativevalue, NULL) still
has no effect on the rotation angle.
Attached are:
create_mf.c: Testcase in C (thanks to Dmitry Timoshkov, who
created the C code from a reduced WMF testcase I sent him)
create_mf_generated.wmf: WMF file output by ./create_mf file.wmf
wine-fontdirection-24.diff: Preliminary patch described above
If somebody can take a look at the patch and mangle it so
that it does the right thing, I'd be very grateful.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
#include windows.h
#include stdio.h
static void print_LPtoDP_map(HDC hdc, int x, int y)
{
POINT pt = { x, y };
LPtoDP(hdc, pt, 1);
printf(%d,%d - %d,%d\n, x, y, pt.x, pt.y);
}
static int create_wmf(const char *fname)
{
static const char txt_string[] = Should be top-down if not MM_ISOTROPIC mode;
HMETAFILE hmf;
HDC hdc;
LOGFONT lf;
HFONT hfont;
hdc = fname ? CreateMetaFile(fname) : GetDC(0);
if (!hdc)
{
printf(CreateMetaFile(%s) failed\n, fname);
}
//if (!fname)
{
//SetMapMode(hdc, MM_ISOTROPIC);
SetMapMode(hdc, MM_ANISOTROPIC);
}
print_LPtoDP_map(hdc, 100, 100);
SetWindowExtEx(hdc, 1000, -1000, NULL);
SetWindowOrgEx(hdc, 0, 0, NULL);
print_LPtoDP_map(hdc, 100, 100);
if (!fname)
{
SetViewportExtEx(hdc, 1000, 1000, NULL);
SetViewportOrgEx(hdc, 0, 200, NULL);
}
print_LPtoDP_map(hdc, 100, 100);
memset(lf, 0, sizeof(lf));
lf.lfHeight = -20;
//lf.lfEscapement = 2700;
//lf.lfOrientation = 2700;
lf.lfEscapement = 900;
lf.lfOrientation = 900;
lf.lfClipPrecision = CLIP_LH_ANGLES;
strcpy(lf.lfFaceName, Arial);
hfont = CreateFontIndirect(lf);
SelectObject(hdc, hfont);
ExtTextOut(hdc, 100, 100, 0, NULL, txt_string, strlen(txt_string), NULL);
MoveToEx(hdc, 100, 100, NULL);
LineTo(hdc, 200, 200);
LineTo(hdc, 200, -100);
LineTo(hdc, 0, 100);
DeleteObject(hfont);
if (fname)
{
hmf = CloseMetaFile(hdc);
DeleteMetaFile(hmf);
}
else
ReleaseDC(0, hdc);
return 0;
}
int main(int argc, char *argv[])
{
create_wmf(argc 2 ? NULL : argv[1]);
return 0;
}
diff --git a/dlls/gdi32/font.c b/dlls/gdi32/font.c
index ea2e66c..40d76c4 100644
--- a/dlls/gdi32/font.c
+++ b/dlls/gdi32/font.c
@@ -1944,6 +1944,10 @@ BOOL WINAPI ExtTextOutW( HDC hdc, INT x,
{
cosEsc = cos(lf.lfEscapement * M_PI / 1800);
sinEsc = sin(lf.lfEscapement * M_PI / 1800);
+if (lf.lfClipPrecision CLIP_LH_ANGLES)
+{
+sinEsc = - sinEsc;
+}
}
else
{
diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c
index f7b1220..730725a 100644
--- a/dlls/gdi32/freetype.c
+++ b/dlls/gdi32/freetype.c
@@ -2675,10 +2675,10 @@ GdiFont *WineEngCreateFontInstance(DC *d
if (!GetObjectW( hfont, sizeof(lf), lf )) return NULL;
can_use_bitmap = GetDeviceCaps(dc-hSelf, TEXTCAPS) TC_RA_ABLE;
-TRACE(%s, h=%d, it=%d, weight=%d, PandF=%02x, charset=%d orient %d
escapement %d\n,
+TRACE(%s, h=%d, it=%d, weight=%d, PandF=%02x, charset=%d orient %d
escapement %d clipprecision %d\n,
Re: Is Wine a platform for Codeweaver to make money?! Please help me understand.
On Thu, Mar 29, 2007 at 03:17:35PM -0700, Sasan Iman wrote: I don't know how much effort it would take to get Office working on Wine but if getting it to work out-of-the-box means putting it on many more systems (leading to more people getting interested, more mileage leading to more bug reports, more people finding reason to get involved to fix bugs, etc.) then the extra effort may well be worth it. I think the applications that would give Wine the most popularity are the current long term top games. I don't have any need for MS Office at all. It differs from person to person what they think is most needed in wine. And that is fine, because fixing wine properly for one application doesn't prevent fixing it properly for another one and one fix often helps many applications. If someone has the money to pay for MS Office, they certainly have the (comparably) peanuts to pay for CrossOver. Paying CX means paying someone to make wine better. Why wouldn't they want to do this? If many people are interested in getting MS Office to run on wine (in a turn key way or even only in a follow a how-to way) surely one of them is willing to work on it, right? With an application that already runs on CrossOver it's even something that doesn't need too much work as all the hard things were already done by CX. If anyone needs help on how to work on wine, I'll be happy to help anyone help wine (best done on IRC). How good an application is supported by the wine community obviously depends on how much work people put into it. You can see that there is a difference by e.g. comparing the appdb entries of World of Warcraft and MS Office. WoW has since some time details on the appdb on how to make it run in wine. There are none for MS Office and there aren't even detailed bug reports (on those versions I looked at). Working to get an application in wine running usually also has the benefit that sometimes people help achieving that, who don't have any specific interest in that application. So I expect you to follow up on what you said and scratch your personal wine itch. Free software is about sharing work. In the sense that when we put our effort together we get something that is more than what we would have when we didn't share. This can also mean paying someone to do the work for you. Jan
request to look into this bug
Hi, while working through the test reports in the appdb, i saw users submitting
crashes with applications , all similar to bug 7380, so i decided to take
it here. The applications that crash are
*WinMerge (newest version)
*BookWorms Adventures + several other PopCap games ( i tested them)
*5 other applications listed under bug 7380.
So i know of at least 10 applications that crash this way. They all start fine
using the buggy pointer patch from Rein Klazes below. However, i think it's
becoming rahter strange that all these (just released!) applications pass
buggy pointers, so i'm beginning to think the problem must be somewhere else.
I've sent in a patch to work around this bug by an exception handler a few
weeks ago, but that's likely not the way to go either then. Anyone an idea how
to tackle this problem? Thanks.
diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c
index cec2058..4e61da4 100644
--- a/dlls/winex11.drv/dib.c
+++ b/dlls/winex11.drv/dib.c
@@ -3861,6 +3861,7 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph
X11DRV_DIB_IMAGEBITS_DESCR descr;
BITMAP bitmap;
LONG width, height, tmpheight;
+ int nrsrcbytes, dibpitch;
INT result;
descr.physDev = physDev;
@@ -3880,6 +3881,17 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph
if (startscan + lines height) lines = height - startscan;
+
+ /* pointer check */
+ dibpitch = ((width * descr.infoBpp + 23) ~23) / 8;
+ if( descr.compression)
+ nrsrcbytes = 1;
+ else {
+ nrsrcbytes = lines * dibpitch;
+ if( nrsrcbytes 0) nrsrcbytes = - nrsrcbytes;
+ }
+ if( IsBadReadPtr( bits, nrsrcbytes)) return 0;
+
switch (descr.infoBpp)
{
case 1:
@@ -3926,7 +3938,7 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph
descr.width = bitmap.bmWidth;
descr.height= lines;
descr.useShm= FALSE;
- descr.dibpitch = ((descr.infoWidth * descr.infoBpp + 31) ~31) / 8;
+ descr.dibpitch = dibpitch;
X11DRV_DIB_Lock( physBitmap, DIB_Status_GdiMod, FALSE );
result = X11DRV_DIB_SetImageBits( descr );
X11DRV_DIB_Unlock( physBitmap, TRUE );
-
New Yahoo! Mail is the ultimate force in competitive emailing. Find out more
at the Yahoo! Mail Championships. Plus: play games and win prizes.
RE: [PATCH 13/18] XCOPY: Add support for /EXCLUDELIST:file1+file2 etc
+if (wcsstr(copyFromUpper, pos-name) != NULL) {
wcsstr() doesn't seem the right way to compare file names. You
probably want to do a wcsicmp() of the end of the name or something
like that.
It's not a file compare, it's a substring compare, eg if the file contains
just the letter s, all files with s(/S) in either the directory, name or
extension will not get copied. Because there is not a stristr / strstri type
function, I uppercase the lines as read from the exclude file when I save
them away, and then uppercase the source names when doing the search. Hence
I can use strstr (wcsstr) to do the substring matching.
So I think the patch was right...
Until I started thinking harder about it...
There is another unrelated bug, in that the matching should only occur in
the new parts of the tree, not in the original stem. My patch would fail all
files if you put eg, a ':' in there as I am strstr'ing against an expanded
path.
I'll fix that bit and resubmit. If there's anything wrong with the wcsstr
logic though, please let me know.
Thanks for the commits
Jason
[PATCH 18/18] XCOPY: Add help
Er... I have just managed to get git send-email set up and working, and it would appear to be a feature of it. I do get one question which I answered n to, perhaps I should anser yes to it and see what happens :-) Anyone else using git send-email want to comment on how to avoid this? Thanks! Jason
Jason Edmeades : xcopy: Add support for COPYCMD override and
wouldn't it be nicer to use sizeof(copyCmd) here?
if (GetEnvironmentVariable(COPYCMD, copyCmd, MAXSTRING)) {
There are many spots like this in wcmdmain.c
Yes... I'm blaming cut and paste as I didn't do all the wcmd ones :-)
Once I get all my xcopy patches in I want to continue my rework of the cmd
commands, finishing off some more inbuilt ones which I know are broken. I
also want to extend your last patch to ensure all parts which process a
command line are using the MAXSTRING length, and I'll do a patch for this
while I am at it.
Thanks,
Jason
Release notes
I have a question about the Wine release notes. Do the Wine developers work from bugzilla or do they usually just work on a specific application feature? Would it require too much extra effort on the release notes to associate a specific change with a bugzilla bug-fix or specific application/feature fix? I believe IMHO that this would make the release notes more relevant and useful to the end user. I never can tell what was actually fixed in a particular release because of the obscure developer notes. I've been lurking on the wine-devel list watching how development progresses, because at some point I would like to attempt joining in on the development effort. -- John Voltz
[msi OLE automation] Re: msi patches info pls
On Fri, 2007-03-09 at 17:27 +0100, Alexandre Julliard wrote: Sorry for the lack of response, I'm currently waiting for our lawyers to determine if it's ok to use code based on an oleview dump of a native typelib, as that situation is not clear from a copyright POV. I'm afraid I can't do more until they come to a conclusion on that point. So it looks like I will have some free time soon (hopefully) and will be able to redo the IDL file properly (also another Vector NTI/Linux user has offered up his help). However, I wanted to double check the proper way to make such a file as I know this is what is important in copyright (the process, such as dirty-clean room, vs the actual end result). From http://www.winehq.org/pipermail/wine-devel/2007-March/054589.html (posted by Rob Shearman) this is what I understand the correct process to be (I would like to understand the process in detail so I don't do something wrong to taint the wine copyright): As one is looking at the oleview output of the native IDL file, one starts a blank document and begins to make the wine IDL file. One defines all the appropriate interfaces, etc. using the UUID's, names, etc. from the native interface. All the function names and parameter types are declared the same, as well as function attributes, but I should use different names for the parameters and try to put the attributes in a different order (although if I understand correctly the order of these attributes comes from our oleview implementation and not from the interface per se so there shouldn't be any reason to change their order??). Also, what does one do for enums? It does not seem like there is anything that can be changed in this case, so it is alright just to re-create them verbatim (without copying and pasting, and of course the indentation will be prettier)? Thank you very much for your help. Misha
RE: [PATCH 13/18] XCOPY: Add support for /EXCLUDELIST:file1+file2 etc
Further investigations shows the strstr bit is right, but the string I am comparing with differs from windows. I have fixed up xcopy's output display to mirror windows, and added that as a patch on the end of the resubmitted patchset, as it is not directly related to the strstr bit Regards, Jason
Re: Release notes
Am Freitag 30 März 2007 22:26 schrieb John Voltz: I have a question about the Wine release notes. Do the Wine developers work from bugzilla or do they usually just work on a specific application feature? Would it require too much extra effort on the release notes to associate a specific change with a bugzilla bug-fix or specific application/feature fix? I believe IMHO that this would make the release notes more relevant and useful to the end user. I never can tell what was actually fixed in a particular release because of the obscure developer notes. I've been lurking on the wine-devel list watching how development progresses, because at some point I would like to attempt joining in on the development effort. I am personally mostly working on certain application features. If I am working on a bugzilla bug then I'll write a comment asking for retest there. pgpqT79FM0HNq.pgp Description: PGP signature
Re: DirectDrawRenderer - opengl non power of 2 windows
My first patch!
Sorry this took so long for such a simple patch, I have just been run
off my feet until now.
Before I submit this to wine-patches, is anyone able to do some
further testing for me, to make sure it doesn't break any currently
working games?
This patch fixes a bug that causes a crash for direct draw games when
using opengl as the DirectDrawRenderer.
I wanted to make sure this works and is safe, before I venture into
making it optimized as Stefan suggested.
On 3/25/07, Stefan Dösinger [EMAIL PROTECTED] wrote:
case WINED3DFMT_P8:
{
int height = This-glRect.bottom - This-glRect.top; --!!!
type = GL_UNSIGNED_BYTE;
fmt = GL_RGBA;
mem = HeapAlloc(GetProcessHeap(), 0, This-resource.size * sizeof(DWORD));
if(!mem) {
ERR(Out of memory\n);
return;
}
memory_allocated = TRUE;
d3dfmt_convert_surface(This-resource.allocatedMemory,
...
I think the int height = This-glRect.bottom - This-glRect.top is the
problem. It should use This-currentDesc.Height instead. The opengl rectangle
is a helper for surfaces which are bigger than the max size supported by
opengl If they are used for 2D blits. For example swat3 creates a 3000x32
surface to blit text in 32x32 rectangles. In this case only the needed area
is uploaded to gl and used for blits.
Here the gl rectangle does not apply. For the sake of optimization you may
change the code to only convert the dirty rectangle instead of the whole
surface.
--
Nathan
From 0842a21fd3a43643af3c7ff543804ad2823a91d4 Mon Sep 17 00:00:00 2001
From: Nathan Williams [EMAIL PROTECTED]
Date: Sat, 31 Mar 2007 10:05:39 +1000
Subject: Fixing power of 2 assumptions in the OpenGL ddraw renderer
---
dlls/wined3d/surface.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 8ac924b..6b6c70d 100644
--- a/dlls/wined3d/surface.c
+++ b/dlls/wined3d/surface.c
@@ -955,7 +955,6 @@ static void
flush_to_framebuffer_drawpixels(IWineD3DSurfaceImpl *This) {
case WINED3DFMT_P8:
{
-int height = This-glRect.bottom - This-glRect.top;
type = GL_UNSIGNED_BYTE;
fmt = GL_RGBA;
@@ -969,7 +968,7 @@ static void
flush_to_framebuffer_drawpixels(IWineD3DSurfaceImpl *This) {
mem,
pitch,
pitch,
- height,
+ This-currentDesc.Height,
pitch * 4,
CONVERT_PALETTED,
This);
@@ -3194,6 +3193,7 @@ static HRESULT WINAPI
IWineD3DSurfaceImpl_PrivateSetup(IWineD3DSurface *iface) {
} else {
/* No oversize, gl rect is the full texture size */
This-Flags = ~SFLAG_OVERSIZE;
+This-Flags = SFLAG_NONPOW2;
This-glRect.left = 0;
This-glRect.top = 0;
This-glRect.right = This-pow2Width;
--
1.4.4.4
Re: [PATCH 1/1] wined3d: Make 8bpp a valid depth in EnumAdapterModes
On Friday 30 March 2007 08:11:54 pm Vitaly Budovski wrote: Make 8bpp a valid depth in EnumAdapterModes. This allows Age of Empires to start. --- dlls/wined3d/directx.c |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) This causes the d3d8 device test to fail for me: device.c:755: Test failed: Unexpected display mode returned for mode 42: 0x29 ...all the way through to... device.c:755: Test failed: Unexpected display mode returned for mode 83: 0x29 D3D8 only supports 32-bit X8R8G8B8 and 16-bit R5G6B5 modes as far as Windows testing has shown, and passing WINED3DFMT_UNKNOWN to WineD3D for mode enumeration makes it work on D3D8 modes only. You'll probably need to wait for Stefan or Henri to respond to figure out what to do. Though, it appears DDraw can be patched to do a second enumeration loop with WINED3DFORMAT_P8 if the first was with WINED3DFMT_UNKNOWN.. whether or not this is acceptable, I'm not sure, but it's an idea I just had.
Re: [PATCH 1/1] wined3d: Make 8bpp a valid depth in EnumAdapterModes
Chris Robinson wrote: On Friday 30 March 2007 08:11:54 pm Vitaly Budovski wrote: Make 8bpp a valid depth in EnumAdapterModes. This allows Age of Empires to start. --- dlls/wined3d/directx.c |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) This causes the d3d8 device test to fail for me: device.c:755: Test failed: Unexpected display mode returned for mode 42: 0x29 ...all the way through to... device.c:755: Test failed: Unexpected display mode returned for mode 83: 0x29 D3D8 only supports 32-bit X8R8G8B8 and 16-bit R5G6B5 modes as far as Windows testing has shown, and passing WINED3DFMT_UNKNOWN to WineD3D for mode enumeration makes it work on D3D8 modes only. You'll probably need to wait for Stefan or Henri to respond to figure out what to do. Though, it appears DDraw can be patched to do a second enumeration loop with WINED3DFORMAT_P8 if the first was with WINED3DFMT_UNKNOWN.. whether or not this is acceptable, I'm not sure, but it's an idea I just had. I haven't really tested this patch much and I don't expect it to be applied. There was just a regression that prevented AOE from starting due to it not finding an 8bpp mode. The regression was caused by this patch: http://www.winehq.com/pipermail/wine-cvs/2007-February/030394.html BTW.
