- Wine-Devel - list.winehq.org

Re: some ntdll functions [Virus checked]
by Dmitry Timoshkov Jan. 29, 2003

Jan. 29, 2003

<thomas.mertes(a)t-mobile.at> wrote: > --- old_wine-20030115/dlls/ntdll/rtlstr.c Tue Nov 12 03:17:34 2002 > +++ new_wine-20030115/dlls/ntdll/rtlstr.c Sun Jan 26 00:03:56 2003 > @@ -516,6 +516,15 @@ > */ > > > /************************************************************************** > + * RtlUpperChar (NTDLL.@) > + */ > +CHAR WINAPI RtlUpperChar( CHAR ch ) > +{ > + return toupper(ch); > +} It's better to avoid using locale dependent functions from an underlying system because Wine internal code page almost always is different from OS locale. The way to go is convert to unicode, do desired things, and convert the result back to ansi. -- Dmitry.

1 0

Re: some ntdll functions [Virus checked]
by Dimitrie O. Paun Jan. 29, 2003

Jan. 29, 2003

On January 28, 2003 04:11 am, thomas.mertes(a)t-mobile.at wrote: > +NTSTATUS WINAPI RtlIntegerToUnicodeString(ULONG value, ULONG base,const > UNICODE_STRING *str); Thomas, It seems the patch got wrapped. Turn off automatic wrapping in your mail client before resending it. -- Dimi.

1 0

Re: [dx8 patch 12]: huge cleanup + split
by Andrew John Hughes Jan. 28, 2003

Jan. 28, 2003

On Sat, 25 Jan 2003 01:14:15 +0100 Raphaël Junqueira <fenix(a)club-internet.fr> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > it seems a big patch, but it's only simple cleanups/splits ;) > > it's the first and bigger patch for splitting d3d8 from the future d3d7/d3d8/d3d9 comon code > > Changelog: > - some needed cleanups for future dx9 and d3d common layer support: > - stateblocks to IDirect3DStateBlockImpl interface and moving into a new file (stateblock.c) > - shaders to IDirect3D*ShaderImpl interfaces > - splitting vshader and vshader declaration as in dx9 into 2 interfaces (for future common layer use) > - vshader declaration code to a new file (vsaderdeclaration.c) > - device calls to new interfaces (redirect stubs) > - simple texture fix for a little regression after last jason patches > - some caps code using the GL/glext.h defines (GL_VERSION_*) > > Todo: > - renaming IDirec3DDevice8Impl::StateBlock to IDirec3DDevice8Impl::startupStateBlock > - moving IDirec3DDevice8Impl d3d generic code to a "common layer" interface (maybe IDirec3DDeviceImpl) > - merging new DrawPrimitive prototype (using ddraw code) with current code > - splitting d3d8_private.h into 2 headers (d3d8 specific header, and common layer header) > - merging the hal base prototype > > Raphael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iD8DBQE+MdbYp7NA3AmQTU4RAg3DAJ94zf6kzopk2WH95+Nvq/BcH26dogCdEhf2 > UASOhtqMDLoJocMODUtZZv8= > =5SNm > -----END PGP SIGNATURE----- > Including glext.h appears to break the DLL for me. NVidia's GL headers (gl.h) already define some of the types specified in glext.h. I presume X installs glext.h, but I've not had a conflict between the two headers before. In file included from d3d8_private.h:30, from device.c:35: /usr/local/include/GL/glext.h:3142: conflicting types for `glCopyTexSubImage3DEXT' /usr/local/include/GL/gl.h:2486: previous declaration of `glCopyTexSubImage3DEXT' /usr/local/include/GL/glext.h:3566: conflicting types for `glColorSubTableEXT' /usr/local/include/GL/gl.h:2446: previous declaration of `glColorSubTableEXT' /usr/local/include/GL/glext.h:4372: conflicting types for `glTbufferMask3DFX' /usr/local/include/GL/gl.h:2984: previous declaration of `glTbufferMask3DFX' /usr/local/include/GL/glext.h:4406: conflicting types for `glTextureColorMaskSGIS' /usr/local/include/GL/gl.h:3050: previous declaration of `glTextureColorMaskSGIS' -- Andrew :-) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html "Windows is the one true OS. MS invented the GUI. MS invented the 32 bit OS. MS is open and standard. MS loves you. We have always been at war with Oceania."

3 4

Re: Bug #540: DLL Separation of user32 from x11drv (clipboard)
by Vincent Béron Jan. 28, 2003

Jan. 28, 2003

Andrew John Hughes a écrit: > License: LGPL > > Changelog: > Removes calls to CLIPBOARD_IsPresent, CLIPBOARD_EmptyCache and CLIPBOARD_GetFormatName. > Something's missing... Vincent

1 0

Guess who's back, back again... :)
by Dimitrie O. Paun Jan. 28, 2003

Jan. 28, 2003

Hi folks, My ski vacation was a blast, good snow, good skiing, good people... You guys have been busy this past week judging by the number of messages I had to go through :) It's good to be back! -- Dimi.

3 2

Re: PATCH: glibc 2.3.x and errno
by Dan Kegel Jan. 28, 2003

Jan. 28, 2003

Ulrich Weigand wrote: > On the other hand, maybe it would now be possible to implement Wine > threads on top of regular pthreads; at least some of the inhibitors > should be gone now, e.g. you can have thread stacks at arbitrary locations > and sizes, and there is no master thread any more ... Unfortunately I > don't quite remember the full list of problems we had with pthreads ;-/ It occurs to me that implementing Wine threads on top of pthreads would probably get rid of a few of the problems keeping us from running Wine under Valgrind. Short of getting the Stanford Checker guys interested in the Wine source tree, I can't think of an cooler way to look for stupid memory bugs in Wine... - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 2

mkdir, copy, etc.
by Jon Bright Jan. 28, 2003

Jan. 28, 2003

Hi, I'm trying to build OpenSSL using Borland Builder 5 within wine. Installation of Builder has gone fine, ActiveState Perl went on after a bit of fiddling, but I've now hit a small problem. The makefile for OpenSSL attempts to run mkdir, copy, etc. - this results in Borland's make attempting to run (after trying to find copy.exe/com/bat/cmd), the command interpreter found in COMSPEC. But wcmd is only a unix command - there is no windows\system\wcmd.exe Is there already a workaround for this, or can someone point me in the right direction to look at fixing it? -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com/

3 2

pshpack8.h:47:6: warning: #warning "8 as alignment
by Gerald Pfeifer Jan. 28, 2003

Jan. 28, 2003

On all platforms I have access to (GNU/Linux, FreeBSD) I have been seeing the following for quite some time now: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" Is this really useful, resp. couldn't we avoid that somehow? Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

1 0

Re: Windows API database
by Dave Miller Jan. 28, 2003

Jan. 28, 2003

So for starters, we want something like this? It doesn't look very impressive. :) http://home.ptd.net/~compsol/imported_dll.txt However, my system is by no means a clean install of WinXP home so most of thos DLLs probably don't belong to windows. -----Original Message----- From: Dan Kegel [mailto:dank(a)kegel.com] Sent: Thursday, January 23, 2003 5:20 PM To: Dave Miller Cc: wine-devel(a)winehq.com Subject: Re: Windows API database Oh, ok. Cross-referencing DLL imports and exports. Yeah, that sounds like a job for a simple perl script. All you need to output is DLL name and what DLLs it imports from. Just generate a flat text file for starters, then later postprocess that into an ascii tree or graph. It's going to be a messy little graph, I bet. - Dan Dave Miller wrote: > The project I am considering is mentioned on the contributing page here: > http://fgouget.free.fr/wine/contributing-en.shtml. (Build a database of > Windows APIs and dependencies) It sounds like less work to simply create > text files containing the imports and exports, although I think the point is > partially for the results to be easily cross referenced by developers. > Hence the suggestion of a database of some kind. I've considered scanning > applications as well. If I have any success with the Windows APIs I may try > tackling that at some point as well. > > ----- Original Message ----- > From: "Dan Kegel" <dank(a)kegel.com> > To: "David Miller" <compsol(a)ptd.net> > Cc: <wine-devel(a)winehq.com> > Sent: Thursday, January 23, 2003 3:38 PM > Subject: Re: Windows API database > > > >>David Miller wrote: >> >>>I would be interested in knowing more about the goals of this project. >>>Don't consider me officially working on such a thing just yet. I have >>>no real perl experience, but would like to learn. First I'd like to >>>know more about what I'm up against. >> >>I'm not sure what project you're talking about, but I can make a few >>wild guesses... >> >> >>>1. Is there a specific set of dll's and exe's we want included in the >>>database or does it need to scan and gather a list of all dll and exe >>>files? That would suggest a clean OS install is necessary. >> >>Sure, a clean OS install is probably good. Many of the >>APIs exposed by even the clean OS install may not be >>needed if no application calls them, but it's hard to know >>that in advance. >> >>We might want to also scan applications to see what APIs >>they actually use, but that's real hard. >> >> >>>2. What information should be in the database? (OS ver, name of dll or >>>exe, name of imported dll, APIs and whether they are imported or >>>exported, etc.) >> >>Maybe use the same format as we use in the souce tree? e.g. >>scanning advapi32.dll should produce something that looks very >>much like > > http://cvs.winehq.com/cvsweb/wine/dlls/advapi32/advapi32.spec?rev=1.32 > >>>3. Will a single MySQL table do or does it need to be a relational >>>database with multiple tables? >> >>IMHO no SQL is needed. The database should be plain text >>files checked into CVS. >> >> >>>4. Anything else you can tell me about this task? >> >>Compare with other standards which provide lists of API's, for example: >>http://www.linuxbase.org/spec/ >>http://www.unix.org/ >>http://www.ecma.ch/ecma1/STAND/ECMA-234.HTM >>to get some ideas. Of course, these are formatted all fancily, >>and cover different operating systems, but the goal is similar: >>to provide an authoritative list of APIs. >>Ideally, the result could be part of a submission to a >>standards body. >>(See also http://www.kegel.com/remedy/remedy2.html#fix.info ) >>- Dan >> >>-- >>Dan Kegel >>http://www.kegel.com >>http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 >> >> >> > > > > -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 1

Re: PATCH: dlls/ole32/storage.c
by Dan Kegel Jan. 28, 2003

Jan. 28, 2003

Gerald Pfeifer wrote: > - int lastblocknr; > + int lastblocknr=-1; FWIW, some compilers will complain on that line (though only us K&R vets remember why). Safer to use whitespace between the = and the -, e.g. > - int lastblocknr; > + int lastblocknr = -1; - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0