- Wine-Devel - list.winehq.org

Appdb bug
by Ivan Leo Murray-Smith March 24, 2004

March 24, 2004

The search from the admin pages returns a 404 error: The requested URL /admin/search.php was not found on this server. Can someone please fix this? Ivan.

2 1

Re: CURSORICON_SimulateLoadingFromResourceW param check. VFP6 EXEs now work.
by Uwe Bonnes March 24, 2004

March 24, 2004

>>>>> "C" == C Daniel Mojoli B <cdmojoli(a)idea.com.py> writes: C> Add minimal parameter validation to function C> CURSORICON_SimulateLoadingFromResourceW(...). We check that the icon Providing a test case for such special behaviour is a good idea... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 4

Re: CURSORICON_SimulateLoadingFromResourceW param check. VFP6 EXEs now work.
by Stefan Leichter March 24, 2004

March 24, 2004

Hello Uwe, i fear your test will only test what you like to test if it is executed in the source directory. For "out of tree builds" your test case tests how LoadImageA behaves when the specified file does not exist. Bye Stefan Am Dienstag, 23. März 2004 21:29 schrieb Uwe Bonnes: > >>>>> "C" == C Daniel Mojoli B <cdmojoli(a)idea.com.py> writes: > > C> Uwe Bonnes wrote: > >>>>>>> "C" == C Daniel Mojoli B <cdmojoli(a)idea.com.py> writes: > > C> Add minimal parameter validation to function > C> CURSORICON_SimulateLoadingFromResourceW(...). We check that the icon > > >> Providing a test case for such special behaviour is a good idea... > > C> I created this patch as a result of consulting I performed at a > C> customer's site. I no longer have access to the winedbg info I had > > It this what you meant? > > The test succeeds on NT and crashes on wine

2 2

Re: Problem with code in WWN 214
by Brian Vincent (C) March 24, 2004

March 24, 2004

> WWN 214 contains some sample code and in my browser I see: > There are two things that are wrong: > * The #include statements are incomplete. That's because the HTML looks > like this: Yeah, that's just a problem with the server side stuff. Newman - do you happen to know why? Seems like an XML parser thing. > ' ' results in two line feeds eventhough that may be a bug in There should not be a ... the real tag is which is both XML and HTML compliant. <pre> is an evil tag if you use CSS, it should never be used on WineHQ. This does bring up a good point, <code> displays weird on WineHQ, compare it to how Zack does it: http://www.kerneltraffic.org/wine/wn20040312_214.html I think the problem is for two reasons: 1) There's no CSS definition for BR. There should be and maybe it should look something like: { margin-bottom: 3px; margin-top: 3px } Likewise, I tend to use <ul> for doing indenting and it needs to have less whitespace above and below. Or, maybe <dl> could be changed and I can abuse that instead. 2) That particular instance has some markup problems, I put in a couple of extra tags in a few places. Corollary to Linus' feelings on backups: Proofreading is for wimps. Real men publish their writing to a news site and have everyone else spellcheck it. (Although, you'll notice since Newman set me up with CVS acces I do tend to do a quick once over after committing it and then fix obvious mistakes. If you have any scripts that automate this I should be able to easily automate it into the existing publishing system I have. XML doesn't lend itself to spellchecking too easily, so I've never pursued it.) --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

2 1

Re: Cards.dll improvements
by Filip Navara March 24, 2004

March 24, 2004

Sam wrote: >This patch implements card drawing mode flag >for rounding card corners. > >Sami Nopanen, xasmx(a)optonline.net > > I know it was propably suggested earlier, but why don't you use (or adapt) my cards.dll implementation for ReactOS? http://cvs.reactos.com/cgi-bin/cvsweb.cgi/reactos/lib/cards/ Regards, Filip

1 0

Re: Win32 packages released on sourceforge
by Ivan Leo Murray-Smith March 24, 2004

March 24, 2004

> I am kind of holding my breath for a regular build of winetest.exe - any > chance for that soon? :-) It depends on how you define regular. If you mean daily/weekly builds, I have no idea. But I can build winetest.exe when I build the win32 packages, when A.J. releases wine. Ivan.

9 30

Q: Linux environment for loading Windows drivers?
by Heiko Nardmann March 24, 2004

March 24, 2004

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Is there a Linux environment available somewhere to load Windows drivers and run the hardware this way? Thanks in advance! - -- Heiko Nardmann (Dipl.-Ing. Technische Informatik) secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de) Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iEYEARECAAYFAkBhk2QACgkQpm53PRScYyiwWACfQ08ax3dD2tIcyheyujpp1kmu Ge4An1JB72l6gZN4RJvTMeUlBhsAgZEQ =Jzoc -----END PGP SIGNATURE-----

2 1

Re: winpos.c & module.c - minor ms-windows compatibility
by Dimitrie O. Paun March 24, 2004

March 24, 2004

On Mon, 22 Mar 2004, Boaz Harrosh wrote: > module.c > GetProcAdress will not "Fly" on a NULL module. It will Just return > with Error set to ERROR_PROC_NOT_FOUND (127). > Actually, I did a little check, On ms-windows any garbage HMODULE will > Just Return an error. Is there a ValidPointer/magic_number check we can > do before we "fly" here. A small test in dlls/kernel/tests/*.c for this would be perfect. In general, it's better to submit such a test, rather than write a throw-away one on your box only. -- Dimi.

4 7

linux build broken
by Ivan Leo Murray-Smith March 24, 2004

March 24, 2004

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(a)localhost wine]$ Ivan.

1 0

Problem with code in WWN 214
by Francois Gouget March 24, 2004

March 24, 2004

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