April 2004 - Wine-Devel - list.winehq.org

RFH: RPC patch
by Filip Navara April 25, 2004

April 25, 2004

Hi, for about week and half I was working on a patch that makes Wine RPC runtime communicating with the Windows one. Now I'm almost done with the work and I need help from someone who can test the patch under Wine. (I was doing all my testing under regular Windows.) If someone will be willing to help me testing it, the patch is at www.volny.cz/xnavara/rpc/ along with a test programs. Regards, Filip

1 0

Wine bug with MFC/C++?
by greensh＠knology.net April 25, 2004

April 25, 2004

It appears that Wine cannot use tmpfs... so far my testing only works using swap :o( which I do have enabled at home and it crashes. At work I have a 500MB swap space and the same exact program does not crash there. It's not convenient for me to run swap at home, so does anyone know a fix for this? The code seems to require approx 500MB free memory. Since I only have 500MB RAM, I setup tmpfs on /tmp. But wine doesn't seem to use any of it. Shaun

1 0

winetest.exe output from Windows 95
by Jakob Eriksson April 25, 2004

April 25, 2004

By killing processes left and right, I managed to get a 50 - megabyte log. Maybe in the future we should link in bzip2 in winetest.exe to compress logs before submitting? regards, Jakob

2 2

Re: Remove debugmsg from guides
by Dimitrie O. Paun April 25, 2004

April 25, 2004

On Sun, 25 Apr 2004, Ivan Leo Murray-Smith wrote: > Please let me know if something isn't OK. A few points: -- I find the change confusing. There's no WINEDEBUG channel. I think most should just change from debugmsg -> debug -- Please provide only one .diff file. Multiple diffs are not necessary, and makes reviewing and applying so much more difficult. -- It would be nice if the diff would be either inlined or attached as text/plain. Inlining is prefered, this way people can quote easily when replying. -- Dimi.

1 0

Re: Remove debugmsg from guides
by Eric Pouech April 25, 2004

April 25, 2004

Ivan Leo Murray-Smith a écrit : > With this all unneeded references to debugmsg should be gone. Just one note, in > debugger.sgml I found this > [MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 957636538 > "Auto"=dword:00000001 > "Debugger"="winedbg --debugmsg -all %ld %ld" > As I don't know what it's meant to be now, I've left it, if it should change, > let me know. > Please let me know if something isn't OK. > > Ivan. this should be changed into "Debugger"="winedbg %ld %ld" (the issue is that the debugger will be inheriting the parent's debug channel, while this setting was turning off all debugging channels from debugger itself). A+

1 0

Re: PATCH: silence strict aliasing in dlls/opengl32
by Lionel Ulmer April 25, 2004

April 25, 2004

> Not sure how to regenerate the opemngl_ext.c file. You need the extension registry CVS (you can find it here http://oss.sgi.com/projects/ogl-sample/ - no idea where the exact CVS informations are). After, do 'make_opengl PATH_TO_EXTENSION_DIR 1.2' where PATH_TO_EXTENSION_DIR points to the '<OGL-SAMPLE-ROOT>/main/doc/registry/specs/' directory). Anyway, if it can wait, it will be updated the next time I generate the file. Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

dlls/d3d8/shader.c
by Marcus Meissner April 25, 2004

April 25, 2004

Hi, I was just fixing this code, but I wonder why floorf(s0->w) is overwritten right next with tmp_f = powf(2.0f, s0->w); What is the right version? Ciao, Marcus void vshader_expp(D3DSHADERVECTOR* d, D3DSHADERVECTOR* s0) { float tmp_f = floorf(s0->w); DWORD tmp_d = 0; tmp_f = powf(2.0f, s0->w); tmp_d = *((DWORD*) &tmp_f) & 0xFFFFFF00;

2 1

Bad string handling in PRINTDLG_UpdatePrintDlg?
by Francois Gouget April 24, 2004

April 24, 2004

In PRINTDLG_UpdatePrintDlgA() in dlls/commdlg/printdlg.c we do: ... LPPRINTER_INFO_2A pi = PrintStructures->lpPrinterInfo; ... pi->pPortName = "FILE:"; And in PRINTDLG_UpdatePrintDlgW() we do: ... LPPRINTER_INFO_2W pi = PrintStructures->lpPrinterInfo; ... static WCHAR file[] = {'F','I','L','E',':',0}; pi->pPortName = file; ... Now in gcc all string literals are read-only, even if you declare them as char* foo="bar", *foo='\0' will cause a segfault. So in the Ansi version we point pPortName to a read-only string. But if the application gets hold of that pointer we have no garantee that it won't expect to be able to modify that string: pPortName is an LPSTR. (this is a case where -Wwrite-strings will complain) And in the Unicode case we point pPortName to a static writable buffer. But in this case if the application writes in our buffer its contents is going to be messed up forever. However I don't know this code at all. So I'm asking, shoudln't we make a copy of these strings? Which also raises the ugly issue of later freeing the corresponding memory buffer... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

1 0

Idea to fight spam
by Ivan Leo Murray-Smith April 24, 2004

April 24, 2004

What about having a link to this page somewhere on winehq? Maybe on the mailing lists page? http://www.hostedscripts.com/scripts/antispam.html Ivan.

2 1

Re: Docu: mention piping for debugmsgs
by Ferenc Wagner April 24, 2004

April 24, 2004

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > Make people know how to reduce log size, using pipes. Hi Andi! Two notes: 1. The --debugmsg option is deprecated, people should use the WINEDEBUG environmental variable instead. 2. Won't the pipe block until you read from it, then give you all the data ever written? -- Feri.

1 0