wine-devel April 2001

wine-devel@winehq.org

51 participants
93 discussions

Regedit from Win2k
by Dominik Strasser 19 Apr '01

19 Apr '01

Hi, trying to run regedit from Win2k I encounter the following problems: err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufA) imported from shell32.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufW) imported from shell32.dll, setting to 0xdeadbeef Hmm, but those are implemented. When I try to add a loadorder for shlwapi to get the builtin one, this doesn't work. "shlwapi" = "builtin, native" Still the native version is used. If I change the overall DefaultLoadOrder, to "builtin, native" it works. After this, the tree items in the Treeview vanished but I don't care. I assume this is the cause: fixme:listview:LISTVIEW_Create ANSI notify format is NOT used Trying to save the registry I get a crash wich I tracked down to this line in filedlg95.c: 453: AllocInArgWtoA(ofn->lpTemplateName, lpTemplateName); But ofn->lpTemplateName is not a pointer but seems to be a handle: 0x00000064. If I wrap the call into a if(!IsBadReadPtr(ofn->lpTemplateName, 4)), the filedialog comes up. Any clues anybody ? Regards Dominik -- Dominik Strasser | Phone: +49 89 636-43691 SIEMENS AG | Fax: +49 89 636-42284 CT SE 4 | E-Mail:Dominik.Strasser@mchp.siemens.de Otto-Hahn-Ring 6 | D-81739 Muenchen | Room: 53-263

1 0

Re: Store each glyph name only once in PS driver
by Alexandre Julliard 18 Apr '01

18 Apr '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > Separating the string data from their indices will allow them to be > declared as const, so that should get them into the ".rodata" section of > the resulting assembly; the Adobe Glyph List vector is already there. > Is this what you mean by "read only memory"? Yes, exactly that; separating the strings and the indices seems the right thing to do. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Store each glyph name only once in PS driver
by Alexandre Julliard 18 Apr '01

18 Apr '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > typedef struct { > + INT index; > + CHAR sz[0]; > +} GLYPHNAME; > + > +typedef struct { > + LONG UV; > + GLYPHNAME *name; > +} UNICODEGLYPH; > + > +typedef struct { > + INT size; > + UNICODEGLYPH glyphs[0]; > +} UNICODEVECTOR; Zero-size arrays are not portable, and the standard method of using a size of 1 doesn't work well with initialized data (lots of warnings). So you probably need to change your data structures a bit; also it would be nice to store all the preinitialized stuff, or at least the strings, in read-only memory to save a bit of swap space. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: SEH logging
by Alexandre Julliard 17 Apr '01

17 Apr '01

Francois Gouget <fgouget(a)free.fr> writes: > In this implementation exception.c reuses format_exception_msg() > which is normally used to display the dialog box asking whether to debug > the exception or not. Since this is all in ntdll it works. Actually win32/except.c is part of kernel, it's only linked in ntdll now because separation is not finished. So you cannot call format_exception_msg from ntdll. And anyway this would print "unhandled xxx" for all exceptions, which is misleading since they might be handled later on. Also I don't think the core exception routines should know about specific exception codes like EXCEPTION_WINE_STUB. If you want a message on stubs, it should be done in the .spec.c file before the call to RtlRaiseException. -- Alexandre Julliard julliard(a)winehq.com

2 1

IStorage file format.
by Psyon 17 Apr '01

17 Apr '01

I am interested in making an HTMLHelp (.CHM) viewer for Linux. I am told the files are actually IStorage files. I have been scouring the internet looking for information about this format with no avail. I have also been looking over the WINE implementation, to see if that would shed some light on the format, but the code dives into a bunch of cryptic functions that I cant seem to follow. Is there any documents describing the format of these files? even just a brief description would be nice at this moment. If you have any information please replay directly to me at x-odus(a)iname.com Thanks in advance --Don Becker

4 3

RH 7.1 gcc fixes compiler bug
by James Juran 17 Apr '01

17 Apr '01

As discovered about two weeks ago by Francois Jacques and Ulrich Weigand, Red Hat's gcc-2.96-69 package has a bug which shows up in the HOOK_CallHook function in windows/hook.c (and possibly other places). Red Hat 7.1 contains gcc-2.96-81, which fixes this bug. Users of Red Hat 7.0 should install the gcc and cpp packages from Red Hat 7.1 to fix this problem. -- James Juran jamesjuran(a)alumni.psu.edu

1 0

Re: strange msvcrt crash
by gerard patel 17 Apr '01

17 Apr '01

At 02:47 PM 16/04/2001 -0700, you wrote: > > Also I had lost of trouble running mspaint when using the builtin >msvcrt. None of the following works: >$ wine /mnt/win98/Program\ Files/Accessories/mspaint.exe >$ wine "/mnt/win98/Program Files/Accessories/mspaint.exe" >$ wine "c:/Program Files/Accessories/mspaint.exe" >$ wine "c:\\Program Files\\Accessories\\mspaint.exe" > > They all tell me that 'H:\wine\Files\Accessories\mspaint.exe was not >found.'. If I use native msvcrt they all work (and wine is the real >thing, not a script). Msvcrt includes command line parsing to give apps argc and argv - the current builtin handling in dlls/msvcrt/data.c is probably the cause of your problem : while (1) { if ((cmdline[end]==' ') || (cmdline[end]=='\0')) { if (cmdline[end]=='\0') last_arg=1; else cmdline[end]='\0'; Gerard

1 0

Re: strange msvcrt crash
by Alexandre Julliard 16 Apr '01

16 Apr '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > Err, which debugger ?? > > I get "Segmentation fault", and that's it... The automatic debugger startup cannot work in this case, because it only triggers for exception that are not handled by the application. But if you run the application under the debugger from the start, it should break at the first exception. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: strange msvcrt crash
by Alexandre Julliard 16 Apr '01

16 Apr '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > Call msvcrt.mktime(405b614c) ret=5f40e3b3 tid=08066638 > Ret msvcrt.mktime() retval=3adae6b2 ret=5f40e3b3 tid=08066638 > trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 > trace:seh:EXC_CallHandler calling handler at 0x5f493fcb code=c0000005 flags=0 > Call ntdll.RtlRaiseException(404a4aa8) ret=405e1056 tid=08066638 > trace:seh:EXC_RtlRaiseException code=80000100 flags=1 > trace:seh:EXC_CallHandler calling handler at 0x4005ca10 code=80000100 flags=1 80000100 is EXCEPTION_WINE_STUB; the app probably called a stub from the exception handler of the first seg fault (and then called the same stub from the handler of the stub exception, etc.) The debugger should be able to tell you more about it. -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: OpenGL Visual Management
by lawson_whitney＠juno.com 16 Apr '01

16 Apr '01

On Mon, 26 Mar 2001, Gavriel State wrote: > This patch fixes several issues with the way OpenGL manages visuals: > > - It always uses a double-buffered visual if one is available, even when > not running Wine in --desktop mode. Previously, we just hoped that the > default visual was double buffered, which is isn't in some DRI GL drivers. > > - It ensures that all colormaps created use the double-buffered visual if > it exists. This prevents problems where DRI GL implementations fail > to work unless the colormap visual matches the window visual matches the > glX visual. > > - It gets around similar visual issue with the default GL context created for > apps that don't create their own contexts before trying to use GL functions. > > Note that we are not able to support the wgl ChoosePixelFormat/DescribePixelFormat > APIs properly. Some of the infrastructure for this exists in graphics/x11drv/opengl.c > so that it can be done when the time comes. This patch explicitly removes the wgl > code that tries to match the OpenGL visual to a requested pixel format, because > that won't work until we can dynamically remap HWNDs to new X11 Windows with > a new visual. > > -Gav > Something is not right, I think. Ordinary apps (Dmitry's About.exe, say) look as if they were using a vga16 server - unless the pointer is over the desktop: then the entire X display is black and white. Without a desktop with managed moving the pointer over the app's window radically changes the palette for the whole screen, but not to black and white. With neither managed nor desktop, the pointer has no effect on the palette. No doubt I am not well set up for DGA: grep -i dga config.cache ac_cv_header_X11_extensions_xf86dga_h=${ac_cv_header_X11_extensions_xf86dga_h=yes} ac_cv_lib_Xxf86dga_XDGAQueryExtension=${ac_cv_lib_Xxf86dga_XDGAQueryExtension=no} ac_cv_lib_Xxf86dga_XF86DGAQueryExtension=${ac_cv_lib_Xxf86dga_XF86DGAQueryExtension=yes} but I don't see why DGA support should disturb things so. I haven't really looked into it much yet...maybe you will see right off what you or I have done wrong? Regards, Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

2 11

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 2001