- wine-devel - winehq.org

linux build broken
by Ivan Leo Murray-Smith 24 Mar '04

24 Mar '04

The build of gdi.dll.so fails miserably, with the following error, maybe because of the dlls building with winegcc? gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o printdrv.o printdrv.c ../../tools/winebuild/winebuild -D__WINESRC__ -D_GDI32_ -o gdi32.dll.dbg.c --debug -C. ../../objects/bitmap.c ../../objects/brush.c ../../objects/clipping.c ../../objects/dc.c ../../objects/dcvalues.c ../../objects/dib.c ../../objects/enhmetafile.c ../../objects/font.c ../../objects/gdiobj.c ../../objects/linedda.c ../../objects/metafile.c ../../objects/palette.c ../../objects/pen.c ../../objects/region.c ../../objects/text.c bidi.c bitblt.c driver.c enhmfdrv/bitblt.c enhmfdrv/dc.c enhmfdrv/graphics.c enhmfdrv/init.c enhmfdrv/mapping.c enhmfdrv/objects.c freetype.c gdi_main.c icm.c mapping.c mfdrv/bitblt.c mfdrv/dc.c mfdrv/graphics.c mfdrv/init.c mfdrv/mapping.c mfdrv/objects.c mfdrv/text.c painting.c path.c printdrv.c bidi16.c dispdib.c env.c gdi16.c wing.c gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -D__WINESRC__ -D_GDI32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o gdi32.dll.dbg.o gdi32.dll.dbg.c ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./gdi32.spec dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o dispdib.o env.o gdi16.o wing.o ../../objects/bitmap.o ../../objects/brush.o ../../objects/clipping.o ../../objects/dc.o ../../objects/dcvalues.o ../../objects/dib.o ../../objects/enhmetafile.o ../../objects/font.o ../../objects/gdiobj.o ../../objects/linedda.o ../../objects/metafile.o ../../objects/palette.o ../../objects/pen.o ../../objects/region.o ../../objects/text.o bidi.o bitblt.o driver.o enhmfdrv/bitblt.o enhmfdrv/dc.o enhmfdrv/graphics.o enhmfdrv/init.o enhmfdrv/mapping.o enhmfdrv/objects.o freetype.o gdi_main.o icm.o mapping.o mfdrv/bitblt.o mfdrv/dc.o mfdrv/graphics.o mfdrv/init.o mfdrv/mapping.o mfdrv/objects.o mfdrv/text.o painting.o path.o printdrv.o gdi32.dll.dbg.o version.res -o gdi32.dll.so -L../../dlls -ladvapi32 -lkernel32 -lntdll -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode /usr/lib/libicuuc.a /usr/lib/libicudata.a -lstdc++ -lgcc_s -L../../libs/port -lwine_port -lm gcc: /usr/lib/libicuuc.a: linker input file unused because linking not done gcc: /usr/lib/libicudata.a: linker input file unused because linking not done libicuuc-JrTm9s.o is an empty file winegcc: ../../tools/winebuild/winebuild failed. make[2]: *** [gdi32.dll.so] Error 2 make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls' make: *** [dlls] Error 2 [ivan@localhost wine]$ Ivan.

1 0

Problem with code in WWN 214
by Francois Gouget 24 Mar '04

24 Mar '04

WWN 214 contains some sample code and in my browser I see: #include #include #include #include #include static jmp_buf jmpbuf; int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow) [...] There are two things that are wrong: * The #include statements are incomplete. That's because the HTML looks like this: #include <wine/library.h> Of course the correct form would be: #include <wine/library.h> And yet the XML source seems correct since it contains </>. * The line spacing is wrong. That's because the HTML contains: #include <wine/library.h> ' ' results in two line feeds eventhough that may be a bug in Mozilla. This might come from the ' ' tags in the XML source. But maybe the best approach would be to side-step ' ' altogether and use <pre> to generate something like this: <pre> #include >wine/library.h< #include >stdio.h< #include >windows.h< ... But maybe the idea behind <code> is that it makes the lines wrappable. In that case we need to fix the issue. Maybe removing it altogether would work? I see the same problems in other issues of WWN such as 139, 149 and 155. WWN 102 has the same double interline for a diff and there's probably other issues that are affected. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

1 0

Re: [dinput/linux input] two fixes/added missing axis and button polling
by Christoph Frick 24 Mar '04

24 Mar '04

On Wed, Mar 24, 2004 at 12:58:21AM +0100, Christoph Frick wrote: hi, im terribly sorry and hope this patch is not yet submited. > - changed the mapping of the axis to a simplier formula, that ignores > the middle of an axis this code lacked the "shifting" of the result by ``wanted min'' also not stated on the first posting: this patch is LGPL licensed below you find the complete patch again with the fixed part. -- cu Index: joystick_linuxinput.c =================================================================== RCS file: /home/wine/wine/dlls/dinput/joystick_linuxinput.c,v retrieving revision 1.1 diff -u -r1.1 joystick_linuxinput.c --- joystick_linuxinput.c 12 Feb 2004 23:28:00 -0000 1.1 +++ joystick_linuxinput.c 24 Mar 2004 07:23:15 -0000 @@ -239,7 +239,12 @@ for (i=0;i<ABS_MAX;i++) { newDevice->wantmin[i] = -32768; newDevice->wantmax[i] = 32767; - newDevice->deadz[i] = 1024; /* guessing */ + /* TODO: + * direct input defines a default for the deadzone somewhere; but as long + * as in map_axis the code for the dead zone is commented out its no + * problem + */ + newDevice->deadz[i] = 0; } return newDevice; } @@ -412,8 +417,8 @@ This->axes[i][AXE_ABSFUZZ], This->axes[i][AXE_ABSFLAT] ); - This->havemax[i] = This->axes[i][AXE_ABSMIN]; - This->havemin[i] = This->axes[i][AXE_ABSMAX]; + This->havemin[i] = This->axes[i][AXE_ABSMIN]; + This->havemax[i] = This->axes[i][AXE_ABSMAX]; } } MESSAGE("\n"); @@ -460,12 +465,8 @@ if (xmin == xmax) return val; if ((hmin == hmax) || (hmax==xmid) || (hmin==xmid)) return val; - /* don't assume total linearity, but linearity starting from a zeropoint */ - if (val > xmid) { - ret = (val-xmid)*((wmax-wmin)/2)/(hmax-xmid)+0; - } else { - ret = (xmid-val)*((wmax-wmin)/2)/(hmin-xmid)+0; - } + /* map the value from the hmin-hmax range into the wmin-wmax range */ + ret = (val * (wmax-wmin)) / (hmax-hmin) + wmin; #if 0 /* deadzone doesn't work comfortably enough right now. needs more testing*/ @@ -519,8 +520,54 @@ GEN_EVENT(DIJOFS_BUTTON(2),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); This->js.rgbButtons[2] = ie.value?0x80:0x00; break; + case BTN_TOP: + case BTN_X: + case BTN_4: + GEN_EVENT(DIJOFS_BUTTON(3),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); + This->js.rgbButtons[3] = ie.value?0x80:0x00; + break; + case BTN_TOP2: + case BTN_Y: + case BTN_5: + GEN_EVENT(DIJOFS_BUTTON(4),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); + This->js.rgbButtons[4] = ie.value?0x80:0x00; + break; + case BTN_PINKIE: + case BTN_Z: + case BTN_6: + GEN_EVENT(DIJOFS_BUTTON(5),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); + This->js.rgbButtons[5] = ie.value?0x80:0x00; + break; + case BTN_BASE: + case BTN_TL: + case BTN_7: + GEN_EVENT(DIJOFS_BUTTON(6),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); + This->js.rgbButtons[6] = ie.value?0x80:0x00; + break; + case BTN_BASE2: + case BTN_TR: + case BTN_8: + GEN_EVENT(DIJOFS_BUTTON(7),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); + This->js.rgbButtons[7] = ie.value?0x80:0x00; + break; + case BTN_BASE3: + case BTN_TL2: + case BTN_9: + GEN_EVENT(DIJOFS_BUTTON(8),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); + This->js.rgbButtons[8] = ie.value?0x80:0x00; + break; + case BTN_BASE4: + case BTN_TR2: + GEN_EVENT(DIJOFS_BUTTON(9),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); + This->js.rgbButtons[9] = ie.value?0x80:0x00; + break; + case BTN_BASE5: + case BTN_SELECT: + GEN_EVENT(DIJOFS_BUTTON(10),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); + This->js.rgbButtons[10] = ie.value?0x80:0x00; + break; default: - FIXME("unhandled joystick axe %x, value %d\n",ie.code,ie.value); + FIXME("unhandled joystick button %x, value %d\n",ie.code,ie.value); break; } break; @@ -533,9 +580,22 @@ case ABS_Y: GEN_EVENT(DIJOFS_Y,ie.value,ie.time.tv_usec,(This->dinput->evsequence)++); This->js.lY = map_axis(This,1,ie.value); + break; case ABS_Z: GEN_EVENT(DIJOFS_Z,ie.value,ie.time.tv_usec,(This->dinput->evsequence)++); This->js.lZ = map_axis(This,2,ie.value); + break; + case ABS_RX: + GEN_EVENT(DIJOFS_RX,ie.value,ie.time.tv_usec,(This->dinput->evsequence)++); + This->js.lRx = map_axis(This,3,ie.value); + break; + case ABS_RY: + GEN_EVENT(DIJOFS_RY,ie.value,ie.time.tv_usec,(This->dinput->evsequence)++); + This->js.lRy = map_axis(This,4,ie.value); + break; + case ABS_RZ: + GEN_EVENT(DIJOFS_RZ,ie.value,ie.time.tv_usec,(This->dinput->evsequence)++); + This->js.lRz = map_axis(This,5,ie.value); break; default: FIXME("unhandled joystick axe event (code %d, value %d)\n",ie.code,ie.value);

1 0

RFC - Program to schedule download of winetest.exe
by Jakob Eriksson 24 Mar '04

24 Mar '04

I have hacked together a little program to download winetest.exe and run it every 24h. Here is the URL: http://vmlinux.org/jakov/Wine/testloader/ There are more binaries and stuff there too. I know this is not a windows service, but at least it is something. Keep this console aplication open and it will download winetest.exe every 24h, with some randomness, to go easy on the server. .----------------------------------. What the code looks like: #include <string> #include <stdlib.h> #include <stdio.h> #include <time.h> #include <windows.h> #include <io.h> #include <process.h> using namespace std; static void await(int hour) { int right_time = 0; do { time_t now = time(NULL); struct tm comp = *gmtime(&now); if (comp.tm_hour == hour) { Sleep((rand()%60) * 60000); // Introduce randomness right_time = 1; } else { Sleep(10000); } } while(!right_time); } #define WINETESTS "winetests.exe" #define TESTCOPY "testcopy.exe" static void runtest() { SetCurrentDirectory(getenv("TEMP")); _unlink(WINETESTS); system("wget --no-clobber http://vmlinux.org/jakov/Wine/" WINETESTS); // Validate GPG signature for winetest.exe -- TODO // silly wget makes file not executable if (!CopyFile(WINETESTS, TESTCOPY, FALSE)) { printf("Problem with file " WINETESTS "\n"); return; } _unlink(WINETESTS); rename(TESTCOPY, WINETESTS); printf("execl %s returns: %d\n", WINETESTS, _execl(WINETESTS, WINETESTS, NULL)); } int main(int argc, char **argv) { int run_once = 0; if (argc != 2) { printf("Usage:\n%s < hour_of_download | once >\n", argv[0]); return 0; } srand((unsigned int)time(NULL)); if (2 == argc) { if (string(argv[1]) == "once") { run_once = 1; } } if (run_once) { runtest(); return 0; } while (1) { await(atoi(argv[1])); runtest(); } return 0; }

1 0

winegcc: don't mess with the DLL ext
by Dimitrie O. Paun 23 Mar '04

23 Mar '04

ChangeLog Dimitrie O. Paun <dpaun(a)rogers.com> Don't adjust the extension for DLLs. Index: tools/winegcc/winegcc.c =================================================================== RCS file: /var/cvs/wine/tools/winegcc/winegcc.c,v retrieving revision 1.21 diff -u -r1.21 winegcc.c --- tools/winegcc/winegcc.c 23 Mar 2004 00:14:54 -0000 1.21 +++ tools/winegcc/winegcc.c 23 Mar 2004 18:00:24 -0000 @@ -348,7 +348,7 @@ strarray *spec_args, *comp_args, *link_args; char *output_file; const char *spec_c_name, *spec_o_name; - const char *output_name, *spec_file, *def_ext; + const char *output_name, *spec_file; const char* winebuild = getenv("WINEBUILD"); int generate_app_loader = 1; int j; @@ -378,11 +378,10 @@ generate_app_loader = 0; /* normalize the filename a bit: strip .so, ensure it has proper ext */ - def_ext = opts->shared ? ".dll" : ".exe"; if (strendswith(output_file, ".so")) output_file[strlen(output_file) - 3] = 0; - if(!strendswith(output_file, def_ext)) - output_file = strmake("%s%s", output_file, def_ext); + if (!opts->shared && !strendswith(output_file, ".exe")) + output_file = strmake("%s.exe", output_file); /* get the filename by the path, if present */ if ((output_name = strrchr(output_file, '/'))) output_name++; -- Dimi.

1 0

compile errors with glibc 2.3.3
by Nerijus Baliunas 23 Mar '04

23 Mar '04

Hello, trying to build wine-20040309 in separate build directory. ../wine-20040309/configure completed correctly, but running make depend gives me: cd ./tools && make `basename tools/makedep` make[1]: Entering directory `/usr/src/wine-build/tools' gcc -c -I../../wine-20040309/tools -I. -I../../wine-20040309/include -I../include -DLEX_OUTPUT_ROOT="\"lex.yy\"" -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o makedep.o ../../wine-20040309/tools/makedep.c In file included from ../../wine-20040309/tools/makedep.c:21: ../include/config.h:871:27: missing terminating " character config.h line 871 is: #define SONAME_LIBNCURSES "libncurses.so.5 (really missing terminating " here) configure output was: checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking for waddch in -lncurses... yes ... checking for -lncurses soname... libncurses.so.5 libncurses.so.4 checking for -lcurses soname... libcurses.so I have both libncurses.so.4 and libncurses.so.5 on my system: # rpm -qf libncurses.so.4.0 libncurses.so.5.3 ncurses4-5.0-12 ncurses-5.3-9 After adding missing " I get the next error: In file included from ../../wine-20040309/tools/makedep.c:23: ../../wine-20040309/include/wine/port.h:53: error: conflicting types for `mode_t' /usr/include/sys/types.h:72: error: previous declaration of `mode_t' # rpm -qf /usr/include/sys/types.h glibc-headers-2.3.3-17 (from Fedora devel) types.h 71 line: #ifndef __mode_t_defined typedef __mode_t mode_t; # define __mode_t_defined #endif After commenting out lines 52-72 of include/wine/port.h make depend completed successfully, but make failed with more errors: In file included from ../../../wine-20040309/libs/port/getpagesize.c:22: ../../../wine-20040309/include/wine/port.h:251: error: conflicting types for `getpagesize' /usr/include/unistd.h:872: error: previous declaration of `getpagesize' ../../../wine-20040309/include/wine/port.h:259: error: conflicting types for `lstat' /usr/include/sys/stat.h:365: error: previous declaration of `lstat' ... After fixing these by commenting out more lines I got more errors and stopped here. Regards, Nerijus

1 0

Audit of comctl32 for the PSDK - listview.c
by Steven Edwards 22 Mar '04

22 Mar '04

Hello, Its time for another round of PSDK porting fixes. I am going to start on comctl32. Most of if builds fine except for some internal or non-documented defines that we need to figure out how to handle. The only big issue we have is listview... Compiling... listview.c C:\source\wine\dlls\comctl32\listview.c(503) : warning C4018: '<' : signed/unsigned mismatch C:\source\wine\dlls\comctl32\listview.c(503) : warning C4018: '<' : signed/unsigned mismatch C:\source\wine\dlls\comctl32\listview.c(1620) : warning C4018: '<' : signed/unsigned mismatch C:\source\wine\dlls\comctl32\listview.c(1655) : warning C4018: '<' : signed/unsigned mismatch C:\source\wine\dlls\comctl32\listview.c(2593) : error C2065: '__FUNCTION__' : undeclared identifier C:\source\wine\dlls\comctl32\listview.c(2593) : warning C4047: 'function' : 'const char *' differs in levels of indirection from 'int ' C:\source\wine\dlls\comctl32\listview.c(2593) : warning C4024: 'ranges_assert' : different types for formal and actual parameter 3 C:\source\wine\dlls\comctl32\listview.c(2635) : warning C4047: 'function' : 'const char *' differs in levels of indirection from 'int ' C:\source\wine\dlls\comctl32\listview.c(2635) : warning C4024: 'ranges_assert' : different types for formal and actual parameter 3 C:\source\wine\dlls\comctl32\listview.c(2704) : warning C4047: 'function' : 'const char *' differs in levels of indirection from 'int ' C:\source\wine\dlls\comctl32\listview.c(2704) : warning C4024: 'ranges_assert' : different types for formal and actual parameter 3 C:\source\wine\dlls\comctl32\listview.c(2708) : warning C4047: 'function' : 'const char *' differs in levels of indirection from 'int ' C:\source\wine\dlls\comctl32\listview.c(2708) : warning C4024: 'ranges_assert' : different types for formal and actual parameter 3 C:\source\wine\dlls\comctl32\listview.c(2718) : warning C4047: 'function' : 'const char *' differs in levels of indirection from 'int ' C:\source\wine\dlls\comctl32\listview.c(2718) : warning C4024: 'ranges_assert' : different types for formal and actual parameter 3 C:\source\wine\dlls\comctl32\listview.c(2776) : warning C4047: 'function' : 'const char *' differs in levels of indirection from 'int ' C:\source\wine\dlls\comctl32\listview.c(2776) : warning C4024: 'ranges_assert' : different types for formal and actual parameter 3 C:\source\wine\dlls\comctl32\listview.c(2780) : warning C4047: 'function' : 'const char *' differs in levels of indirection from 'int ' C:\source\wine\dlls\comctl32\listview.c(2780) : warning C4024: 'ranges_assert' : different types for formal and actual parameter 3 C:\source\wine\dlls\comctl32\listview.c(3974) : warning C4244: '=' : conversion from 'long ' to 'unsigned short ', possible loss of data C:\source\wine\dlls\comctl32\listview.c(4008) : warning C4244: '=' : conversion from 'long ' to 'unsigned short ', possible loss of data C:\source\wine\dlls\comctl32\listview.c(4015) : warning C4244: '=' : conversion from 'long ' to 'unsigned short ', possible loss of data C:\source\wine\dlls\comctl32\listview.c(4017) : warning C4244: '=' : conversion from 'long ' to 'unsigned short ', possible loss of data C:\source\wine\dlls\comctl32\listview.c(5061) : warning C4013: 'offsetof' undefined; assuming extern returning int C:\source\wine\dlls\comctl32\listview.c(5061) : error C2143: syntax error : missing ')' before 'type' C:\source\wine\dlls\comctl32\listview.c(5066) : error C2143: syntax error : missing ')' before 'type' C:\source\wine\dlls\comctl32\listview.c(5242) : error C2061: syntax error : identifier 'LISTVIEW_GetItemExtT' C:\source\wine\dlls\comctl32\listview.c(5242) : error C2059: syntax error : ';' C:\source\wine\dlls\comctl32\listview.c(5242) : error C2059: syntax error : 'type' C:\source\wine\dlls\comctl32\listview.c(5600) : warning C4013: 'LISTVIEW_GetItemExtT' undefined; assuming extern returning int C:\source\wine\dlls\comctl32\listview.c(5648) : warning C4018: '==' : signed/unsigned mismatch C:\source\wine\dlls\comctl32\listview.c(5680) : warning C4013: 'ListView_FindItemW' undefined; assuming extern returning int C:\source\wine\dlls\comctl32\listview.c(6102) : error C2143: syntax error : missing ')' before 'type' C:\source\wine\dlls\comctl32\listview.c(6107) : error C2143: syntax error : missing ')' before 'type' C:\source\wine\dlls\comctl32\listview.c(6180) : error C2061: syntax error : identifier 'LISTVIEW_RedrawItems' C:\source\wine\dlls\comctl32\listview.c(6180) : error C2059: syntax error : ';' C:\source\wine\dlls\comctl32\listview.c(6180) : error C2059: syntax error : 'type' C:\source\wine\dlls\comctl32\listview.c(6458) : warning C4013: 'Header_GetItemW' undefined; assuming extern returning int C:\source\wine\dlls\comctl32\listview.c(6618) : warning C4013: 'Header_SetItemW' undefined; assuming extern returning int C:\source\wine\dlls\comctl32\listview.c(7389) : warning C4244: '=' : conversion from 'long ' to 'short ', possible loss of data C:\source\wine\dlls\comctl32\listview.c(7568) : warning C4146: unary minus operator applied to unsigned type, result still unsigned C:\source\wine\dlls\comctl32\listview.c(7671) : warning C4146: unary minus operator applied to unsigned type, result still unsigned C:\source\wine\dlls\comctl32\listview.c(7753) : warning C4018: '<' : signed/unsigned mismatch C:\source\wine\dlls\comctl32\listview.c(8293) : warning C4244: '=' : conversion from 'long ' to 'short ', possible loss of data C:\source\wine\dlls\comctl32\listview.c(8822) : error C2065: 'LPLVFINDINFOW' : undeclared identifier C:\source\wine\dlls\comctl32\listview.c(8822) : warning C4047: 'function' : 'const struct tagLVFINDINFOW *' differs in levels of indirection from 'int ' C:\source\wine\dlls\comctl32\listview.c(8822) : warning C4024: 'LISTVIEW_FindItemW' : different types for formal and actual parameter 3 C:\source\wine\dlls\comctl32\listview.c(8822) : error C2146: syntax error : missing ')' before identifier 'lParam' C:\source\wine\dlls\comctl32\listview.c(8822) : error C2059: syntax error : ')' C:\source\wine\dlls\comctl32\listview.c(8825) : error C2065: 'LPLVFINDINFOA' : undeclared identifier C:\source\wine\dlls\comctl32\listview.c(8825) : warning C4047: 'function' : 'const struct tagLVFINDINFOA *' differs in levels of indirection from 'int ' C:\source\wine\dlls\comctl32\listview.c(8825) : warning C4024: 'LISTVIEW_FindItemA' : different types for formal and actual parameter 3 C:\source\wine\dlls\comctl32\listview.c(8825) : error C2146: syntax error : missing ')' before identifier 'lParam' C:\source\wine\dlls\comctl32\listview.c(8825) : error C2059: syntax error : ')' C:\source\wine\dlls\comctl32\listview.c(9007) : warning C4013: 'LISTVIEW_RedrawItems' undefined; assuming extern returning int __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

1 0

Re: Pipe Tests corrected[Resent]
by Alexandre Julliard 22 Mar '04

22 Mar '04

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > +void test_CreatePipe(void) > +{ > + /* Adapted from the MSDN SDK example > + * "Creating a Child Process with Redirected Input and Output" > + */ You can't do that, MSDN examples are copyright Microsoft. You have to write your own code from scratch. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Some DirectDraw stubs
by Alexandre Julliard 22 Mar '04

22 Mar '04

Mike Hearn <mh(a)codeweavers.com> writes: > The parameters for these functions have not been verified as in native ddraw.dll > they are some kind of circular forward, it's rather confusing. The proper way to determine the number of parameters is to check what the caller does. And if nobody calls them there's no point in adding them. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wine/dlls/d3d8/device.c cleanup
by Dimitrie O. Paun 22 Mar '04

22 Mar '04

On March 20, 2004 3:42 pm, hatky wrote: > tabs -> spaces (the cause of the bloated file) You got to be kindin', right? -- Dimi.

3 4

OFC ( MFC-like classes )
by Jakob Eriksson 22 Mar '04

22 Mar '04

I thought I should mention: http://cvs.sourceforge.net/viewcvs.py/ofc/ofc/test/ The OFC project actually has a few classes now. Might be of use to somebody porting stuff to Linux. Jakob

1 0

Link with ICU in documentation
by Boaz Harrosh 22 Mar '04

22 Mar '04

- Where is the official place to download the ICU library for support of BIDI? - Should we not have a BIDI section in documentation? - Is there a place on winehq with links to extra needed downloads? should ICU be there 2? Free Life Boaz

2 1

CDRoms & SCSI
by Robert Lunnon 22 Mar '04

22 Mar '04

Well you can ignore my last message, from the source it's pretty obvious why it doesn't work. Linuxisms ! At the very least it should be possible to declare a scsi device in the config file and have it set up, IE one could probe each disk device declared for scsi capability. Possibly this should be the only behaviour since this would allow the user/administrator to limit wine to only particular scsi devices rather than give it open slather over everything. Comments ?

2 2

Re: version.dll patch
by Alexandre Julliard 21 Mar '04

21 Mar '04

Steven Edwards <steven_ed4153(a)yahoo.com> writes: > We found quite a few problems using version.dll on ReactOS and Windows > XP. According to Royce there was a issue regarding ANSI converion that > was causing applications (Winzip) to fail to load. Also we found that > Microsoft doesnt support reading of the Win16 resources from the Win32 > APIs. I don't think that's true. The MSDN doc explicitly says that 16-bit resources are supported, and they work just fine on XP here. Also the whole file has been reformatted, making it impossible to see what changed. Please don't do that. -- Alexandre Julliard julliard(a)winehq.org

5 5

Re: [PATCH] Fix attribute naked
by Filip Navara 21 Mar '04

21 Mar '04

Jeff Muizelaar wrote: > The attached patch changes declspec(naked) to __attribute__(cdecl) > from __attribute__(naked) > As seen in the gcc documentation > (http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function%20Attri…), > > __attribute__(naked) does not do the same thing as declspec(naked) > instead __attribute__(cdecl) does. Sure, it does the same. > http://www.cs.cornell.edu/courses/cs412/2001sp/resources/microsoft-calling-… > This page is wrong. From MSDN: "The naked storage-class attribute is a Microsoft-specific extension to the C language. The compiler generates code without prolog and epilog code for functions declared with the naked storage-class attribute. Naked functions are useful when you need to write your own prolog/epilog code sequences using inline assembler code. Naked functions are useful for writing virtual device drivers." > -Jeff - Filip

1 0

Re: wine/dlls/d3d8/device.c cleanup
by Duane Clark 21 Mar '04

21 Mar '04

Unknown wrote: > > Sorry, seems like I need to take great care of my words, I already been told > to drop the "hop e you like it" part before it got in... (spamers like this > word or sentence? I didn't know that....) > Not spammers, viruses ;) "Here is a new game I just wrote. Hope you like it." I tend to glance very fast at emails when moderating, and such phrases are red flags for me, requiring that I spend extra time to verify that the email is legitimate. It is not a big deal, but I try to discourage such phrases.

1 0

Re: 3/4 patches for compilation of ATL & MFC
by Boaz Harrosh 21 Mar '04

21 Mar '04

Alexandre Julliard wrote: > >The i64 suffix is not portable. > Boaz Harrosh wrote: >oops the wrong file. >I do need it with "LL" (real 64bit constant). >If you want it protected by an ifdef. Is there an long long ifdef done >by configure? .. OK I'll look for it and send a fix. include/config.h (done by configure?) has an "HAVE_LONG_LONG". Now what should I do in msvcrt/limits.h. should I: #include <config.h> ?? or the user should include it in files before limits.h both options look bad to me. Free life Boaz

1 0

XFree 4.4
by Jørn Villesen Christensen 21 Mar '04

21 Mar '04

Hi I downbloaded the 20040309 release and tried to compile. As other users have experienced, I got the error gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC_ _ -DBINDIR="\"/usr/local/bin\"" -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack -boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o keyboard.o keyboard.c keyboard.c: In function `X11DRV_KEYBOARD_DetectLayout': keyboard.c:1288: warning: comparison between signed and unsigned keyboard.c: In function `X11DRV_MapVirtualKeyEx': keyboard.c:1746: warning: comparison between signed and unsigned keyboard.c:1755: warning: comparison between signed and unsigned keyboard.c:1784: warning: comparison between signed and unsigned keyboard.c:1787: warning: comparison between signed and unsigned keyboard.c: In function `X11DRV_ToUnicodeEx': keyboard.c:2089: warning: comparison between signed and unsigned keyboard.c:2092: warning: comparison between signed and unsigned keyboard.c:2128: error: `XK_EuroSign' undeclared (first use in this function) keyboard.c:2128: error: (Each undeclared identifier is reported only once keyboard.c:2128: error: for each function it appears in.) make[2]: *** [keyboard.o] Error 1 make[2]: Leaving directory `/home/jvc/Downloads/wine-20040213/dlls/x11drv' make[1]: *** [x11drv] Error 2 make[1]: Leaving directory `/home/jvc/Downloads/wine-20040213/dlls' make: *** [dlls] Error 2 Searched around and found http://www.winehq.org/hypermail/wine-users/2004/02/0130.html which stated that the error was in the kernel. But after searching for the NLS in the kernel, not finding it, I gave up and wanted to recompile the release I previously had installed (which was 20040213. I had to uninstall while trying some rpms of wine). The thing is, that this version could not compile either - it produced the same error. My guess is that the error is not related to the kernel (because I have not recompiled that since my last wine install that worked) but to my upgrading to XFree 4.4. Is my guess correct. And will it be fixed? Best regards Jørn Christensen Denmark PS: Note that the error dump above is from my compiling of 20040213 - not 20040309. I had removed the source code of 20040309, but the error is (as far as I remember it) identical. I can of course - if its nescesarry - download and try to comiled 20040309 again...

1 0

print 16-bit WCHAR
by Gibtsnich Gibtsauchnich 21 Mar '04

21 Mar '04

Hello! I was wondering if there is any way to use a 16-bit-unicode-string with wine's TRACE, ERR or FIXME. I was thinking about something like: WCHAR text={'b','l','a',0}; TRACE("%?s", text); However, I found that these functions are a quite complicated wrapper around vfprintf, wich only accepts ANSI or 32-bit-unicode-strings. So could you tell me if wine has some WCHAR2char_t function or will i haveto use WideCharToMultiByte? Thank you Fabian -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

2 1

Cdrom
by Robert Lunnon 20 Mar '04

20 Mar '04

I am working on a Solaris CDROM plugin, but can't seem to get past the configuration stage. I get ASPI_GetNumControllers Could not open HKEY_DYN_DATA\WineScsi How do I get wine to setup this key ? Thanks Bob

1 0

Re: [D3D] Improve D3D7 compatibility
by Lionel Ulmer 20 Mar '04

20 Mar '04

> This makes Summoner recognize our D3D7 driver. How did you find out ? Some R.E.ing of the game ? I ask this because I find it strange that a game would not be 'future proof' and that it would refuse to run on future hardware that supports HW transform and light. You sure it's not just the addition of the 'DRAWPRIMITIVE2EX' flag which is needed ? Could anyone having a Windows box and a card having HW T&L report what the caps give (there is a nice tool for that in the DX SDK) ? My Windows laptop 1) is at work right now and 2) has a crappy 3D card so I can't test. Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

Re: Win32 packages released on sourceforge
by Ivan Leo Murray-Smith 20 Mar '04

20 Mar '04

> Bug in binutils. A fix by Dimitry is in latest binutils. OK, I'm rebuilding mingw with gcc-3.2.3-20030504-1, binutils-2.15.90-20040222-1-src, mingw-runtime-3.2 and w32api-2.5, it should all be up to date. > MinGW folks split up the headers as well, (in their w32api package), > and I think they are useful in and of themselves. Ivan? So what we want is wine-hdrs-<version>.zip (headers) wine-dlls-<version>[-mingw].zip (2 packages with stripped and unstripped dlls) wine-prgs-<version>[-mingw].zip (2 packages with stripped and unstripped progs) wine-w32api-<version>[-mingw].zip (2 packages with stripped and unstripped libs) right?

3 2

wine hangs in ddraw/d3dtexture.c (d3dtexture_create)
by Michael Schlüter 20 Mar '04

20 Mar '04

Hi, the whole yesterday I was hunting a problem when staring a program with wine. Now I'm at a point I don't know what to do next. May be somebody can give me an hint? Here are the last lines of the trace+ddraw output: trace:ddraw:Main_DirectDrawSurface_Lock (0x40405b50)->Lock((nil),0x408bf960,00000001,00000000) trace:ddraw:Main_DirectDrawSurface_Lock - locking flags : DDLOCK_WAIT trace:ddraw:d3ddevice_lock_update copying back buffer to main memory with rectangle (0x0) - (800x600). trace:ddraw:Main_DirectDrawSurface_Lock locked surface returning description : - DDSD_CAPS : DDSCAPS_BACKBUFFER DDSCAPS_COMPLEX DDSCAPS_FLIP DDSCAPS_3DDEVICE DDSCAPS_VIDEOMEMORY DDSCAPS_LOCALVIDMEM - DDSD_HEIGHT : 600 - DDSD_WIDTH : 800 - DDSD_PITCH : 1600 - DDSD_LPSURFACE : 0x5f0d0000 - DDSD_PIXELFORMAT : ( DDPF_RGB , RGB bits: 16, R f800 G 07e0 B 001f) trace:ddraw:Main_DirectDrawSurface_Unlock (0x40405b50)->Unlock((nil)) trace:ddraw:DIB_DirectDrawSurface_Blt (0x403f5768)->(0x61885c,0x40405b50,0x61886c,01000000,(nil)) trace:ddraw:DIB_DirectDrawSurface_Blt destrect :0x0-800x600 trace:ddraw:DIB_DirectDrawSurface_Blt srcrect :0x0-800x600 trace:ddraw:DIB_DirectDrawSurface_Blt flags: DDBLT_WAIT trace:ddraw:d3ddevice_blt using direct buffer to buffer copy. trace:ddraw:upload_surface_to_tex_memory_init initialized texture upload for level 0 with conversion 0. trace:ddraw:Main_DirectDraw_CreateSurface (0x403f5418)->(0x61741ba0,0x60d0aedc,(nil)) trace:ddraw:Main_DirectDraw_CreateSurface Requesting surface desc : - DDSD_CAPS : DDSCAPS_TEXTURE DDSCAPS2_TEXTUREMANAGE - DDSD_HEIGHT : 128 - DDSD_WIDTH : 256 - DDSD_PIXELFORMAT : ( DDPF_ALPHAPIXELS DDPF_RGB , RGB bits: 16, R 7c00 G 03e0 B 001f A 8000) trace:ddraw:HAL_DirectDrawSurface_Construct (0x60f501b8,0x403f5418,0x61741ac0) trace:ddraw:DIB_DirectDrawSurface_Construct (0x60f501b8)->(0x403f5418,0x60f503b4) trace:ddraw:Main_DirectDrawSurface_Construct (0x60f501b8)->(0x403f5418,0x60f503b4) trace:ddraw:DIB_DirectDrawSurface_Construct (256x128, pitch=512) trace:ddraw:create_dib DIBSection at : 0x62100000 trace:ddraw:d3dtexture_create GL texture created for surface 0x60f501b8 (private data at 0x60f50058) The appropriate source code: ENTER_GL(); if (surf->mipmap_level == 0) { glGenTextures(1, &(private->tex_name)); if (private->tex_name == 0) ERR("Error at creation of OpenGL texture ID !\n"); TRACE(" GL texture id is : %d.\n", private->tex_name); private->__global_dirty_flag = (at_creation == FALSE ? SURFACE_MEMORY_DIRTY : SURFACE_MEMORY); private->global_dirty_flag = &(private->__global_dirty_flag); } else { private->tex_name = ((IDirect3DTextureGLImpl *) (main->tex_private))->tex_name; TRACE(" GL texture id reusing id %d from surface %p (private at %p)).\n", private->tex_name, main, main->tex_private); private->global_dirty_flag = &(((IDirect3DTextureGLImpl *) (main->tex_private))->__global_dirty_flag); } LEAVE_GL(); A printf showed me, that the call of glGenTextures didn't come back. That's strage because d3dtexture_create and glGenTextures are called a lot of times before without problems? If I delete glGenTextures it works but... Bye, Michael

3 8

Re: Win32 packages released on sourceforge
by Ivan Leo Murray-Smith 19 Mar '04

19 Mar '04

> Can you please post the list of errors to wine-devel, so people are aware of the > problems (and hopefully send patches to fix them :))? Complete compile error log is attached. > Now that we have this build, can we get rid of: > Wine programs for Windows > from the "Support Files" package? Done. Ivan.

5 5

Re: urlmon: Implement FindMimeFromData
by Juan Lang 19 Mar '04

19 Mar '04

Kevin, you said: IMHO we should really keep the list that is checked to a minimum (being the list Windows checks) as this code is basically doing "If a web server reports a MIME type in this list, ignore it and make our own guess" which is totally wrong standards-wise and a major cause of many problems under IE on Windows.. (Apologies for the lack of quoting.) According to that appendix, IE should only be overriding MIME types that are text/plain, application/octet-stream, or empty. It does so because it considers these "ambiguous". I think your patch may be useful for the small set of types you suggest, but shouldn't you only override in these cases too? --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com

3 2

wine.inf
by Ivan Leo Murray-Smith 18 Mar '04

18 Mar '04

Hi list, I've installed wine.inf, but the system.reg file is very short, it only contains font information and computer name, this isn't exactly what I got with winedefault.reg I need this because I'm going to release a new version of winesetuptk that doesn't add the "Filesystem" parameter to the drive config, as AJ has removed it, and the winesetuptk build tree wants system.reg, user.reg and userdef.reg. But system.reg, well, I've described it, userdef.reg is empty and user.reg only contains the Control Panel\\Colors and Control Panel\\International entries. Am I doing something wrong? Ivan.

1 0

urlmon: Implement FindMimeFromData
by Kevin Koltzau 18 Mar '04

18 Mar '04

Here is an implementation of FindMimeFromData, based off of MSDN http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.a… There is lots of debate on the 'net regarding this "feature" in IE, most of it suggesting this is a bad idea.. One possible change that would work more "standards compliant" rather then "Windows like" would be to return the proposed MIME type unchanged if one is given, otherwise go through the detection methods..let me know if that would be a preferred solution Changelog Implement FindMimeFromData

2 2

Re: [RESENT] TIME_GetBias
by Alexandre Julliard 18 Mar '04

18 Mar '04

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > wine/dlls/ntdll/time.c: TIME_GetBias > Calculate the Bias before calling gmtime This cannot be right, the bias is supposed to be the difference between local time and GMT, so you have to use gmtime() not localtime(). -- Alexandre Julliard julliard(a)winehq.org

5 15

Re: Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec)
by Christian Costa 18 Mar '04

18 Mar '04

> Message du 18/03/04 00:51 > De : Marcus Meissner > A : Christian Costa > Copie à : wined > Objet : Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec) > On Wed, Mar 17, 2004 at 10:37:01PM +0000, Christian Costa wrote: > > Hi, > > > > When executing the DllMain of the native IR32_32.DLL (VFW), Wine crashes. > > After some investigations, I found that a part of the code uses the EBX > > register at one point without saving > > and restore it afterwards. Since this register contains the PLT pointer > > for standard unix functions like libc ones, this > > does not take a long time for Wine to crashing. > > I tested with the ugly hack attached that saves and restores the EBX > > register between the call to DllMain and that fixed the problem and > > the DLL works fine then. > > This might happen. That ebx can be scrapped? > > Your fix is not really ok, you must not modify the stackpointer in asm statements. > > Try using: > __asm__ __volatile__ ("":::"ebx"); > > after entry(), which tells the compiler that ebx has been scrapped. Thanks for this! :-) Christian

2 1

Re: Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec)
by Christian Costa 18 Mar '04

18 Mar '04

> Message du 18/03/04 00:50 > De : Mike Hearn > A : wine-devel(a)winehq.com > Copie à : > Objet : Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec) > On Wed, 17 Mar 2004 22:37:01 +0000, Christian Costa wrote: > > When executing the DllMain of the native IR32_32.DLL (VFW), Wine crashes. > > After some investigations, I found that a part of the code uses the EBX > > register at one point without saving and restore it afterwards. > > What calling convention is the entrypoint declared with? How can I retreive this info from the dll? I guess it is stdcall like it should be. > I thought EBX was > a register that had to be saved/restored according to the ABI and the > windows compilers would always do that? > I don't know but that would explain what is happening altough if it was the case I wonder why noone has encountered this problem yet. Bye, Christian

2 1

Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec)
by Christian Costa 18 Mar '04

18 Mar '04

> Message du 18/03/04 01:02 > De : Alexandre Julliard > A : Christian Costa > Copie à : wined > Objet : Re: PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec) > Christian Costa writes: > > > When executing the DllMain of the native IR32_32.DLL (VFW), Wine crashes. > > After some investigations, I found that a part of the code uses the > > EBX register at one point without saving > > and restore it afterwards. Since this register contains the PLT > > pointer for standard unix functions like libc ones, this > > does not take a long time for Wine to crashing. > > Is the dll really modifying ebx explicitly? Isn't it rather a > consequence of a stack overflow or some similar bug? Yes, ebx is modified explicity and not poped from the stack. There is no save/restore statements. Bye, Christian

1 0

wineinstall hangs
by Fabian Cenedese 18 Mar '04

18 Mar '04

Hi I just tried on a new computer to checkout wine from cvs and do a install. Compilation worked fine, but there was again a problem with the regedit: --- snip --- Preparing to install default Wine registry entries... Installing default Wine registry entries... Warning: Language 'us' was not recognized, defaulting to English. Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Xlib: extension "GLX" missing on display ":1.0". fixme:urlmon:URLMON_DllRegisterServer (void): stub wine: Unhandled exception (thread 0009), starting debugger... Warning: Language 'us' was not recognized, defaulting to English. Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: (hang, CTRL-C) Registry entries successfully installed. err:seh:setup_exception nested exception on signal stack in thread 0009 eip 40108aa6 esp 40031c28 stack 0x405a0000-0x406a0000 Installation complete for now. Good luck (this is still alpha software). If you have problems with WINE, please read the documentation first, as many kinds of potential problems are explained there. --- snip --- But after that I could start wine regedit and the keys seem to have been generated. So I don't know what really failed. bye Fabi

3 4

Re: Avoid a possible deadlock when stopping playback
by Christian Costa 18 Mar '04

18 Mar '04

Hi Dmitry, Are you sure this is usefull. How can SetEvent cause a deadlock? Bye, Christian > Message du 16/03/04 14:54 > De : Dmitry Timoshkov > A : wine-patches(a)winehq.com > Copie à : > Objet : Avoid a possible deadlock when stopping playback > Hello, > > looks like it's a good idea to do the same when signalling hStopEvent. > > Changelog: > Dmitry Timoshkov > Avoid a possible deadlock when stopping playback. > > --- cvs/hq/wine/dlls/winmm/mciavi/mciavi.c 2004-03-16 18:37:03.000000000 +0800 > +++ wine/dlls/winmm/mciavi/mciavi.c 2004-03-16 19:38:42.000000000 +0800 > @@ -606,7 +606,9 @@ static DWORD MCIAVI_mciStop(UINT wDevID, > switch (wma->dwStatus) { > case MCI_MODE_PLAY: > case MCI_MODE_RECORD: > + LeaveCriticalSection(&wma->cs); > SetEvent(wma->hStopEvent); > + EnterCriticalSection(&wma->cs); > /* fall through */ > case MCI_MODE_PAUSE: > /* Since our wave notification callback takes the lock, > > > > >

2 3

Rundll32 needs X
by Vincent Béron 18 Mar '04

18 Mar '04

Hi folks, Since wine.inf is now used as the source for the default values for the registry (via rundll32), importing it absolutely needs X (whereas the older regedit method didn't when importing a .reg file). This can be a problem for people running wineinstall via ssh from a Windows box. Is there a reason rundll32 needs user32 and cannot delayimport it? Vincent

3 3

PLT pointer destroyed problem when loading IR32_32.DLL (Indeo codec)
by Christian Costa 17 Mar '04

17 Mar '04

Hi, When executing the DllMain of the native IR32_32.DLL (VFW), Wine crashes. After some investigations, I found that a part of the code uses the EBX register at one point without saving and restore it afterwards. Since this register contains the PLT pointer for standard unix functions like libc ones, this does not take a long time for Wine to crashing. I tested with the ugly hack attached that saves and restores the EBX register between the call to DllMain and that fixed the problem and the DLL works fine then. Can someone tell me what happens? Thanks in advance, Christian Index: loader.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/loader.c,v retrieving revision 1.66 diff -u -r1.66 loader.c --- loader.c 16 Mar 2004 03:10:07 -0000 1.66 +++ loader.c 17 Mar 2004 21:19:39 -0000 @@ -690,7 +690,9 @@ else TRACE("(%p %s,%s,%p) - CALL\n", module, debugstr_w(wm->ldr.BaseDllName.Buffer), reason_names[reason], lpReserved ); + __asm("push %ebx"); retv = entry( module, reason, lpReserved ); + __asm("pop %ebx"); /* The state of the module list may have changed due to the call to the dll. We cannot assume that this module has not been

4 3

Re: [AppDB] - Script the table creation, help users to setup local appdb
by Paul van Schayck 17 Mar '04

17 Mar '04

Chris, On Wednesday 17 March 2004 19:16, Chris Morgan wrote: > README now has some instructions on how to setup a local > appdb. You should also note that magic_quotes_gpc should be off. Otherwise you would end up inside your database with \ everywhere. And for development display_errors is very handy. And great work on those tables. I was already wondered wy I couldn't login. Regards, Paul

1 0

Win32 packages released on sourceforge
by Ivan Leo Murray-Smith 17 Mar '04

17 Mar '04

The win32 packages of wine are on sourceforge, you can get them from http://sourceforge.net/project/showfiles.php?group_id=6241 or to view the win32 packages only http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=112520 Ivan.

2 1

Re: Stubs needed by some Windows Update Installs
by Dmitry Timoshkov 17 Mar '04

17 Mar '04

"Aric Stewart" <aric(a)codeweavers.com> wrote: > @@ -297,7 +297,7 @@ > @ stub SetupSetSourceListA > @ stub SetupSetSourceListW > @ stdcall SetupTermDefaultQueueCallback(ptr) > -@ stub SetupTerminateFileLog > +@ stdcall SetupTerminateFileLog(ptr) The argument here should be 'long'. -- Dmitry.

2 3

Current CVS msi build failure
by Ferenc Wagner 17 Mar '04

17 Mar '04

Hi, with current CVS I get: [...] bison -p SQL_ -d ../../../src/dlls/msi/sql.y -o sql.tab.c ../../../src/dlls/msi/sql.y contains 4 shift/reduce conflicts and 10 reduce/reduce conflicts. bison -p SQL_ -d ../../../src/dlls/msi/sql.y -o sql.tab.c ../../../src/dlls/msi/sql.y contains 4 shift/reduce conflicts and 10 reduce/reduce conflicts. gcc -c -I../../../src/dlls/msi -I. -I../../../src/include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o tokenize.o ../../../src/dlls/msi/tokenize.c ../../../src/dlls/msi/tokenize.c:58: `TK_CHAR' undeclared here (not in a function) ../../../src/dlls/msi/tokenize.c:58: initializer element is not constant ../../../src/dlls/msi/tokenize.c:58: (near initialization for `aKeywordTable[12].tokenType') ../../../src/dlls/msi/tokenize.c:59: `TK_CHAR' undeclared here (not in a function) ../../../src/dlls/msi/tokenize.c:59: initializer element is not constant ../../../src/dlls/msi/tokenize.c:59: (near initialization for `aKeywordTable[13].tokenType') ../../../src/dlls/msi/tokenize.c:90: `TK_HOLD' undeclared here (not in a function) ../../../src/dlls/msi/tokenize.c:90: initializer element is not constant [etc., similar ones for TK_INT, TK_LONG, TK_LONGCHAR, TK_OBJECT and TK_SHORT] These IDs are really missing from my sql.tab.h. Any clues? -- Feri.

2 2

Re: Stub for SignalObjectAndWait
by Mike Hearn 17 Mar '04

17 Mar '04

On Wed, 17 Mar 2004 01:50:40 +0100, Raphael wrote: > PS: i'm trying to get MSN Messenger working, how we can register some com dlls > into registry ? The app installer should do that for you (last time I tried MSN Messenger I didn't have any problems with missing registrations) but you can run regsvr32 on a DLL to reregister it if you want to. thanks -mike

1 0

Re: REBAR: prevent recursions with WM_SIZE reason
by Mike McCormack 17 Mar '04

17 Mar '04

Alexandre, please don't apply this patch... it doesn't work the right way. Juan Lang pointed out that I have a = instead of a |= ... and after fixing it, it doesn't do what it mean to do. thanks, Mike Mike McCormack wrote: > > ChangeLog: > * prevent recursions with WM_SIZE reason

1 0

Re: tools/winetest winetest.cron
by Ferenc Wagner 16 Mar '04

16 Mar '04

Jeremy Newman <jnewman(a)winehq.org> writes: > ChangeSet ID: 11483 > > Log message: > set the lang Did you check if it was needed? I thought my patch took care of this in a language/locale neutral way by opening the report file in :raw mode. I'd like to not if it's not the case. -- Feri.

2 1

Browsing the wine source
by Blake Leverett 16 Mar '04

16 Mar '04

Hello, I have been getting wine from CVS for a while now, and have been looking through the source. How do people who work with the wine code browse around in the source tree? I found that 'ctags -e -R' can be used with emacs, which works OK, but I was wondering if there is a better method. Thanks, Blake Leverett

2 1

Re: cards.dll improvements
by Tom 16 Mar '04

16 Mar '04

Sam wrote: > Improvements to cards.dll based on documentation at > http://www.microsoft.com/mind/0396/games.asp. > I'm not sure if you have read this post or not but here it is. http://www.winehq.com/hypermail/wine-devel/2003/07/0691.html Tom

1 0

how to call setupapi / wine.inf
by Marcus Meissner 16 Mar '04

16 Mar '04

Hi, I am trying to setup wine with wine.inf, with the following call: /usr/bin/rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 /usr/share/wine/wine.inf However, the /usr/share/wine/wine.inf path does not seem to be translated correctly. 0009:Call kernel32.GetFullPathNameW(406efb6e L"/usr/share/wine/wine.inf",00000000,00000000,00 000000) ret=40c8333c 0009:Ret kernel32.GetFullPathNameW() retval=0000001b ret=40c8333c 0009:Call ntdll.RtlAllocateHeap(40360000,00000000,00000036) ret=40c83542 0009:Ret ntdll.RtlAllocateHeap() retval=4039a0e0 ret=40c83542 0009:Call kernel32.GetFullPathNameW(406efb6e L"/usr/share/wine/wine.inf",0000001b,4039a0e0,00 000000) ret=40c83571 0009:Ret kernel32.GetFullPathNameW() retval=0000001a ret=40c83571 0009:Call kernel32.CreateFileW(4039a0e0 L"Y:\\usr\\share\\wine\\wine.inf",80000000,00000001,0 0000000,00000003,00000000,00000000) ret=40c835af 0009:Ret kernel32.CreateFileW() retval=ffffffff ret=40c835af The config script has: [Drive Y] "Type" = "network" "Path" = "%HOME%" [Drive Z] "Type" = "network" "Path" = "/" So it should have been using Z:\\ Is this a problem in GetFullPathName or should I better use: /usr/bin/rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 z:\\usr\\share\\wine\\wine.inf ? Ciao, Marcus

4 4

dlls/ntdll/directory.c portability breakage
by Gerald Pfeifer 16 Mar '04

16 Mar '04

The new file dlls/ntdll/directory.c added by date: 2004/03/16 01:32:02; author: julliard; state: Exp; Implemented NtQueryDirectoryFile (partly based on a patch by Eric Pouech). broke non-Linux platforms (like FreeBSD): /usr/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o directory.o directory.c directory.c: In function `NtQueryDirectoryFile': directory.c:446: error: `O_DIRECTORY' undeclared (first use in this function) directory.c:446: error: (Each undeclared identifier is reported only once directory.c:446: error: for each function it appears in.) There *is* code to #define O_DIRECTORY /* To avoid blocking on non-directories in DOSFS_OpenDir_VFAT*/ #ifndef O_DIRECTORY # define O_DIRECTORY 0200000 /* must be directory */ #endif but it's in #ifdef linux only! Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 0

Re: cards.dll
by Joerg Mayer 16 Mar '04

16 Mar '04

On Tue, Mar 16, 2004 at 12:09:24AM +0200, Shachar Shemesh wrote: > Can someone remind me again why we can't have GPL DLLs in the tree? > Doesn't the "call through documented interface blah blah blah not > derived work" argument cause the license for each two DLLs in Wine to be > independant? Basically it goes like this: LGPLed code can be run as a library, i.e. a function of an LGPLed dll can be called as a function call. GPLed code must be run as a (Unix) process if you want to use it from non-GPL-compatible code. See the GPL and especially the GPL FAQ for details. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

2 1

Re: shell32 patch 23 d [correction]
by Alexandre Julliard 15 Mar '04

15 Mar '04

"Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > Alexandre - is there any thing wrong with this patch? Yes there has to be something wrong, you create a sei_tmp structure but you never actually use it. I'm not sure what your intent was. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [resend] rebar.c: RBBS_HIDETITLE support
by Alexandre Julliard 15 Mar '04

15 Mar '04

Filip Navara <xnavara(a)volny.cz> writes: > I'm sending this patch second time. Is there any reason why it wasn't > commited previously or it just got lost? It will get in faster if you send a non wrapped version ;-) -- Alexandre Julliard julliard(a)winehq.org

1 0

dlls/glu32 compile error
by Peter Hyman 15 Mar '04

15 Mar '04

Kernel 2.6.4 gcc = 3.2.3 The following compile time error occurs: make[2]: Entering directory `/mnt/src/src/wine/dlls/glu32' gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o glu32.spec.o glu32.spec.c {standard input}: Assembler messages: {standard input}:274: Error: no such instruction: `yes "glu32.dll"' {standard input}:275: Error: no such instruction: `yes "gluBeginCurve"' {standard input}:276: Error: no such instruction: `yes "gluBeginPolygon"' {standard input}:277: Error: no such instruction: `yes "gluBeginSurface"' {standard input}:278: Error: no such instruction: `yes "gluBeginTrim"' {standard input}:279: Error: no such instruction: `yes "gluBuild1DMipmaps"' {standard input}:280: Error: no such instruction: `yes "gluBuild2DMipmaps"' {standard input}:281: Error: no such instruction: `yes "gluCheckExtension"' etc... The source file at this location is: "__wine_spec_exp_names:\n" "\tyes \"glu32.dll\"\n" "\tyes \"gluBeginCurve\"\n" "\tyes \"gluBeginPolygon\"\n" "\tyes \"gluBeginSurface\"\n" "\tyes \"gluBeginTrim\"\n" Seems like the \" is being taken as a literal ". Did you mean for a \ to occur? or a \glu... to occur? Regards -- Peter Hyman

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel