Hi,
I'm trying to implement stubs for some missing ordinal functions in shlwapi.
Reading the NOTES comment in dlls/shlwapi/ordinal.c I don't know if it is a
good idea, but it allows explorer.exe (Win 98) to show its desktop and it is
what I'm testing (just for fun. I do not hope to be able to use it right now).
Anyway, it uses at a moment or another unimplemented ordinal functions. To
implement their stubs, I begins with a lot of args, reducing this number
until the function is passed. It seems to work but I wonder if I do not add
only problems with this strategy. If I left the stack in a corrupted state,
maybe the problem will become visible a lot later...
I was not able to find in docs, mails archives or google groups any useful
tip to find (simply) the right number of args. Particularly, the URL
http://www.ece.cmu.edu/afs/ece/usr/dacut/www/src is dead.
So, do I continue ? If yes, in this way or differently ?
Thanks for your advices.
Gael.
PS: I will not read my mail until monday 28.
Aric Stewart wrote:
>
> Working with QuickTime5 I found a situation where mouse messages could
> lockup wine. This leaving and entering the critical section resolves
> that bug.
>
> -aric
>
> ------------------------------------------------------------------------
> Index: windows/message.c
> ===================================================================
> RCS file: /home/wine/wine/windows/message.c,v
With this patch, Myst locks up solid as soon as the mouse is moved into
the Myst window. Without it, Myst works fine.
Duane
David Hammerton wrote:
>
> hi, seems you have done some updating on it.. but now it still doesnt compile,
> im not sure if your trying to include something that is defined elsewhere or
> you made a typo, but it seems to bawk on:
>
> gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -g -O2
> -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT
> -I/usr/X11R6/include -o truetype.o truetype.c
> truetype.c:13: `#include' expects "FILENAME" or <FILENAME>
> truetype.c:14: `#include' expects "FILENAME" or <FILENAME>
>
I give up.
You're getting the error because FreeType's macros are not being defined
by your include files. This is supposed to be the way to work around
the
fact that the FreeType guys rename their include files with every minor
release.
freetype/freetype.h should either define the macros or include another
file that does so. If you can figure out why that isn't happening, let
me know.
--
========================================================================
Ian Pilcher ian.pilcher(a)home.com
========================================================================
On Thu, May 31, 2001 at 01:12:14PM -0400, =?iso-8859-1?Q?G=E9rard_Patel_=3Cgerard.patel=40nerim.net=3E?=(a)tourian.nerim.net wrote:
> At 01:24 30/05/2001 +0200, you wrote:
> (yet another self followup)
>
> >Since the commits of last night, every app I have tried only says :
> >
> >wine client error:0x80675a8: set_thread_buffer failed with status c000000d
Hmm, can you do 'nm file/file.o|grep stat64' and see if we are including
stat64 there?
> >with apps that usually work fine.
> I have still the problem; I have downloaded a fresh tree from winehq
> to make sure it was not a random event.
>
> I don't have much time to debug until next weekend, but I have done
> a bit of searching : this does not happen on my newest computer, a
> Mandrake 8 with glibc 2.2. It happens with my other box, a Suse 6.1
> with a manually upgraded glibc 2.1.3 (I use it without this problem since
> months)
>
> The problem occurs in the mmap call in the server subroutine, the parameters
> being
> size=8192, fd=8,offset=0.
>
> Has anyone compiled cvs since 3 days with glibc 2.1.3 ?
I have build RPMs for OpenLinux eDesktop 2.4, which is kernel 2.2.14 and
glibc 2.1.3, and sol.exe still works.
You can try them from http://www.lst.de/~mm/wine.html if you want to.
Ciao, Marcus
Francois Gouget <fgouget(a)free.fr> writes:
> MSVCRT__set_errno should be able to set errno to 0. It's called at
> least once explicitly with 0 in dir.c, but many other times it is
> called with a GetLastError() that may return 0.
I don't think it is ever correct to set errno to 0. Code that does
that should be fixed to provide a valid error code instead.
--
Alexandre Julliard
julliard(a)winehq.com
Ian Pilcher wrote:
>
> Marcus Meissner wrote:
> >
> > Add here:
> >
> > CFLAGS="$CFLAGS -I$ft_incl_dir"
> >
>
> Works great. Thanks!
>
I spoke too soon. It's finding /usr/include/freetype/freetype.h (from
FreeType 1.x). The test is not paying any attention to the CFLAGS
variable.
So how does one get the autoconf tests to look in a non-standard
directory for header files?
--
========================================================================
Ian Pilcher ian.pilcher(a)home.com
========================================================================
David Howells <dhowells(a)redhat.com> writes:
> I'm having a little trouble deciding exactly how to emulate the "module
> registration" functionality in my kernel module. It occurs to me that this
> might be easier to accomplish with a change to the current wine server message
> set. My idea is:
>
> * Have the server only deal with NT Section objects and views of Sections.
>
> * Have no separate module table attached to a process.
>
> * Implement NtQuerySectionInformation/NtSetSectionInformation calls (or
> whatever they're called) as wineserver messages.
>
> * Add an extra Wine-specific information class for the purpose of recording
> the extra module information.
>
> * The wineserver process structure can then be changed so that rather than
> keeping a separate list of process_dlls, they can just keep a list of
> section views, some of which will be images/modules.
Maintaining a section list in the server is certainly something we
could do, but I don't really see why you want to get rid of the
modules list. What would you gain by doing that?>
--
Alexandre Julliard
julliard(a)winehq.com
I'm having a failure with a windows app. The application starts, and it
asks me to name my project and pick a directory to store it in. When I do
so, I get errors such as:
fixme:shell:PathGetCharTypeA d
fixme:shell:PathGetCharTypeA f
fixme:shell:PathGetCharTypeA d
fixme:shell:PathGetCharTypeA t
And apps reports "such such character isn't valid", and doesn't
continue (each time I try again, it generates another fixme message).
According to MSDN:
http://msdn.microsoft.com/library/psdk/shellcc/shell/SHLWAPI/Path/PathGetCh…
PathGetCharType/PathGetCharTypeA part of shlwapi.h returns one or more of
the following values that define the type of character:
GCT_INVALID
The character is not valid in a path.
GCT_LFNCHAR
The character is valid in a long file name.
GCT_SEPARATOR
The character is a path separator.
GCT_SHORTCHAR
The character is valid in a short (8.3) file name.
GCT_WILD
The character is a wildcard character.
This is the current Wine code:
/*************************************************************************
* PathGetCharTypeA [SHLWAPI.@]
*/
UINT WINAPI PathGetCharTypeA(UCHAR ch)
{
FIXME("%c\n", ch);
return 0;
}
I'm a perl guy, but I'm learning C. Maybe I'm naive, but fleshing out the
Wine version of this function shouldn't be too hard it seems. You'd have
to go track down the rules.
Can some point me in the right direction on fixing this up? Can someone
give me a quick hack to make my application work?
Many thanks,
Dax
Alexandre Julliard wrote:
>
> Basically do a
>
> AC_CHECK_HEADERS(freetype/freetype.h freetype/foo.h freetype/bar.h)
>
Unfortunately it's not that simple, because the FreeType include files
won't always be in /usr/include/freetype. On Red Hat 7.1, for example,
they're in /usr/include/freetype2/freetype, to distinguish them from
the FreeType 1.x headers.
The required compiler flag to include the proper directories is in the
FREETYPEINCL variable. For example, on my Red Hat system it is set to
'-I/usr/include/freetype2'. I tried the following:
ft_incl_dir=${FREETYPEINCL#-I}
AC_CHECK_HEADER("$ft_incl_dir/freetype/freetype.h",AC_DEFINE(HAVE_FREETYPE_H))
When I run autoconf, autoheader, and configure, I get the following:
checking for FT_Init_FreeType in -lfreetype... yes
checking for freetype-config... freetype-config
checking for /usr/include/freetype2/freetype/freetype.h... no
So the AC_CHECK_HEADER macro isn't finding the file, even though it is
right there.
Anyone have any idea why?
--
========================================================================
Ian Pilcher ian.pilcher(a)home.com
========================================================================
