wine-devel August 2005

wine-devel@winehq.org

132 participants
254 discussions

Re: secur32: Getting real functionality into the NTLM provider
by Alexandre Julliard 24 Aug '05

24 Aug '05

Kai Blin <blin(a)gmx.net> writes: > + unsigned char buffer[SECUR32_MAX_BUF_LEN+6000]; > + BYTE bin[SECUR32_MAX_BUF_LEN]; You shouldn't allocate fixed size buffers on the stack, especially not huge ones like that. You should compute the necessary size and allocate a properly sized buffer from the heap. > + SEC_CHAR client_user_arg[512]; > + SEC_CHAR client_domain_arg[512]; > + SEC_CHAR passwd[512] = {0}; Same here, there's nothing that guarantees the buffers are the right size; using snprintf may avoid overflows but it doesn't make the code behave correctly. > +SECURITY_STATUS fork_helperA(PNegoHelperA *new_helper, const char *prog, > + char * const argv[], char* passwd) > +{ You should have a single fork helper that takes Unicode, you can't pass ASCII chars to the Unix app anyway, you have to use CP_UNIXCP. And more generally, you should do everything in Unicode. > + if( ( pipe(pipe_in) < 0 ) || ( pipe(pipe_out) < 0 ) ) > + { > + return SEC_E_INTERNAL_ERROR; > + } > + > + helper->helper_pid = fork(); > + > + helper->password = passwd; > + > + if(helper->helper_pid == -1) > + { > + return SEC_E_INTERNAL_ERROR; > + } You are leaking file descriptors in the error cases. > + if(helper->helper_pid == 0) > + { > + /* We're in the child now */ > + close(0); > + close(1); > + > + dup2(pipe_out[0], 0); > + close(pipe_out[0]); > + close(pipe_out[1]); > + > + dup2(pipe_in[1], 1); > + close(pipe_in[0]); > + close(pipe_in[1]); > + > + execvp(prog, argv); > + > + /* Whoops, we shouldn't get here. Big badaboom.*/ > + return SEC_E_INTERNAL_ERROR; You shouldn't return from the child, you should pass the error back to the parent and then exit(). > + { > + helper->pipe_in = fdopen(pipe_in[0], "r"); > + close(pipe_in[1]); > + helper->pipe_out = fdopen(pipe_out[1], "w"); > + close(pipe_out[0]); > + } You should avoid using stdio. -- Alexandre Julliard julliard(a)winehq.org

2 2

wglMakeCurrent doesn't pick up HDC region
by Russ 24 Aug '05

24 Aug '05

Trying to get my commercial 3-D app to run under WINE using the same binary with the odd workaround or two. It uses OpenGL in various subwindows of the main window as needed. Under WINE, the subwindow graphics all get drawn in the lower left corner of the overall X11 window. In Win32, when you call wglMakeCurrent, the opengl context is configured to match the size/position of the HWND for the HDC, so drawing openGL goes just into the desired subwindow. However, the WINE implementation of wglMakeCurrent just calls glXMakeCurrent (and glXCreateContext), which produces the entire size of the X11 window, resulting in the incorrect behavior observed. In my Mac OS X port, I have a similar issue, resolved by calling aglSetInteger(glContext, AGL_BUFFER_RECT,... I'm not sure what a glX equivalent would be to try, I don't see one offhand. As is, emulating the wglMakeCurrent accurately appears impossible, such that apps that use this Windows behavior can not be run. Suggestions welcome. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

x11drv: use of uninitialized rect
by James Hawkins 24 Aug '05

24 Aug '05

Hey, While compiling x11drv, gcc gives the following error: 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 text.o text.c text.c: In function 'X11DRV_ExtTextOut': text.c:85: warning: 'rect.bottom' is used uninitialized in this function text.c:85: warning: 'rect.top' is used uninitialized in this function text.c:85: warning: 'rect.right' is used uninitialized in this function text.c:85: warning: 'rect.left' is used uninitialized in this function Looking through the CVS log for text.c, I saw that before the latest patch, rect would be initialized if lprect == NULL; otherwise, rect = *lprect. My guess is that we want to use lprect instead of rect, but I'm not familiar enough with that code to make the change. Can you take a look at this Huw? Thanks, James Hawkins

1 0

WineHQ will be offline tomorrow
by Jeremy Newman 23 Aug '05

23 Aug '05

I will be taking the website offline tomorrow starting at 09:00 CDT (04:00 GMT). I will be moving it to a new ISP. Expect downtime to last for up to 8 hours as I will also be doing a complete reinstall of the OS. This will also affect the mailing lists and the CVS. -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

3 6

Re: winecfg: theming
by Kevin Koltzau 23 Aug '05

23 Aug '05

On Tuesday 23 August 2005 2:39 pm, Frank Richter wrote: > + static const WCHAR themesSubdir[] = > + { > '\\','R','e','s','o','u','r','c','e','s','\\','T','h','e','m','e','s',0 }; > + WCHAR themesPath[MAX_PATH]; > + > + free_theme_files(); > + themeFiles = DSA_Create (sizeof (ThemeFile), 1); > + > + GetWindowsDirectoryW (themesPath, MAX_PATH); This should be based on SHGetFolderPath(CSIDL_RESOURCES)

1 0

Re: shell32: Some tests for FolderShortcut class (3rd try)
by Michael Jung 23 Aug '05

23 Aug '05

Hi Alexandre, On Monday 22 August 2005 17:04, Michael Jung wrote: > Changelog: > Added some tests for CLSID_FolderShortcut objects Are there any further problems with this patch? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Automatic ANSI<>Unicode message translation
by Phil Krylov 23 Aug '05

23 Aug '05

Hi, I am having a problem with an app of mine. It posts WM_CHAR messages to a ANSI window with Unicode value in LOWORD(wParam). Wine automatically translates the character code to ANSI (producing a "?" when there is no such code in CP_ACP). Windows does not do it (contrary to documentation). Here is attached (source and binary) a quick and dirty sample application which shows the problem. I could remove map_wparam_AtoW() and map_wparam_WtoA() from dlls/user/message.c, but probably somebody needs that translation. Does anybody have an idea of a better fix for that bug? -- Ph.

5 29

Re: Remove unnecessary #pragma code_page(xxxx) statements from winefile .rc files
by Martin Fuchs 23 Aug '05

23 Aug '05

> This is because 'LANGUAGE LANG_xxxx' statements don't actually change > code page specified by a previous '#pragma code_page(xxxx)', therefore > russian resources get translated to unicode using wrong code page. > I don't know whether it's an rc bug or a feature. We either need > to remove '#pragma code_page' statements altogether, or add them > to all included .rc files. I took the 1st approach. > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Remove unnecessary #pragma code_page(xxxx) statements from > winefile .rc files, they confuse the resource compiler. Please be carefull to remove the code page pragmas. IMHO this is not the correct way. When there is no other code page given, the resource compiler uses the current code page of the operating system. And I don't think, all of those language specific resource scripts will compile correct on all possible OS code pages. The reliable way would be to include the correct code page at the begin of all resource scripts. Please take in mind: Wine is compiled on many different environments: LANG_C, de_DE.ISO-8859-1, en_EN.UTF-8, swedish, or whatever... Removing the code page pragmas would require to test the correctness of the compilation results of all different languages on all possible platforms. Regards, Martin

2 1

Safedisc1 CD checks work, it tries to start the game but fails to do so
by Ivan Leo Puoti 23 Aug '05

23 Aug '05

Hello list, here's a little update Safedisc1 now successfully passes all anti debugger check, and recognises the CD correctly. It then attempts to start the game, but this doesn't work yet because of the nested exception on signal stack bug. Hopefully we aren't too far from getting it to run. Ivan.

4 3

Re: [winedbg] Don't ever pass a NONCONTINUABLE exception
by Alexandre Julliard 22 Aug '05

22 Aug '05

Glenn Wurster <gwurster(a)scs.carleton.ca> writes: > Changelog: > Don't pass on non-continuable exceptions. Why do you want to do that? -- Alexandre Julliard julliard(a)winehq.org

3 6

← Newer
1
...
7
8
9
10
11
12
13
...
26
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 August 2005