wine-devel April 2004

wine-devel@winehq.org

138 participants
323 discussions

RFH: RPC patch
by Filip Navara 25 Apr '04

25 Apr '04

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 25 Apr '04

25 Apr '04

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 25 Apr '04

25 Apr '04

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 25 Apr '04

25 Apr '04

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 25 Apr '04

25 Apr '04

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 25 Apr '04

25 Apr '04

> 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 25 Apr '04

25 Apr '04

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 24 Apr '04

24 Apr '04

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 24 Apr '04

24 Apr '04

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 24 Apr '04

24 Apr '04

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

← Newer
1
...
4
5
6
7
8
9
10
...
33
Older →

Jump to page:

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 April 2004