- Wine-Devel - list.winehq.org

About WineLib : there is a lack of API in wine
by Kevin Dec. 20, 2002

Dec. 20, 2002

hi ::) I have an appliction of Windows. In the appliction i call createRemoteThread 、SetDCPenColor and setDCBrushcolor，but wine don't support those API functions ,if there has the related function in wine?? Thanks kevin wine-devel(a)winehq.com ----- Original Message ----- From: <wine-devel-request(a)winehq.com> To: <wine-devel(a)winehq.com> Sent: Friday, December 20, 2002 2:00 AM Subject: wine-devel digest, Vol 1 #1519 - 5 msgs > Send wine-devel mailing list submissions to > wine-devel(a)winehq.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.com/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.com > > You can reach the person managing the list at > wine-devel-admin(a)winehq.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Today's Topics: > > 1. Re: [D3D8 PATCH] d3d8 shaders update - VS2 (David Laight) > 2. Re: [D3D8 PATCH] d3d8 shaders update - VS2 (Zsolt Rizsanyi) > 3. RE: Win2000 Conformance Test Results... (Kye Lewis) > 4. Re: strcasecmp (Dimitrie O. Paun) > 5. Re: Update to patches sgml (Tony Lambregts) > > --__--__-- > > Message: 1 > Date: Thu, 19 Dec 2002 14:54:21 +0000 > From: David Laight <david(a)l8s.co.uk> > To: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Cc: Fabian Cenedese <Cenedese(a)indel.ch>, wine-devel(a)winehq.com > Subject: Re: [D3D8 PATCH] d3d8 shaders update - VS2 > > On Thu, Dec 19, 2002 at 07:08:40AM -0500, Dimitrie O. Paun wrote: > > On December 19, 2002 05:29 am, David Laight wrote: > > > No, and I would use it if I did :-) > ^^^ > not > > Finger trouble... > > > http://www.vim.org > > Probably... > > > David > > -- > David Laight: david(a)l8s.co.uk > > --__--__-- > > Message: 2 > From: Zsolt Rizsanyi <rizsanyi(a)myrealbox.com> > To: Fabian Cenedese <Cenedese(a)indel.ch>, wine-devel(a)winehq.com > Subject: Re: [D3D8 PATCH] d3d8 shaders update - VS2 > Date: Thu, 19 Dec 2002 16:06:51 +0100 > > On Thursday 19 December 2002 14:27, Fabian Cenedese wrote: > > Considering the age of these two it's maybe understandable why they > > don't have this feature. Tell me an editor in Windows and I may switch. > > There is windows version of Vim. Try that :) > > > --__--__-- > > Message: 3 > From: "Kye Lewis" <kyethespy(a)softhome.net> > To: "'Francois Gouget'" <fgouget(a)free.fr> > Cc: wine-devel(a)winehq.org > Subject: RE: Win2000 Conformance Test Results... > Date: Thu, 19 Dec 2002 16:30:59 +1100 > > XP Results Round 2: > > ** If a test is not listed here, then it has passed ** > > advapi32_test registry: No Change > > Note: Test now always has 3 failures, > No cases of more failures are apparent. > > kernel32_test process: No Change > > netapi32_test access: No Change > > shell32_test shfileop: No Change > > user32_test sysparams: No Change > > Thanks, > Kye Lewis > LinksOS Project Administrator > LinksOS Web Team Leader > kyethespy(a)softhome.net > (New email address! kyethespy(a)liquid2k.com will still work, but please > send all emails now to new email) > > "640k ought to be enough for anyone!" > - Bill Gates > > ================================= > LinksOS: Linking you to the world > http://linksos.cjb.net > http://linksos.sourceforge.net/ > http://linksos.oxygen-x.net/ > Now with Bugzilla and phpBB installed :) > ================================= > > > -----Original Message----- > From: wine-devel-admin(a)winehq.com [mailto:wine-devel-admin(a)winehq.com] > On Behalf Of Francois Gouget > Sent: Friday, December 13, 2002 8:58 AM > To: David Fraser > Cc: Kye Lewis; wine-devel(a)winehq.org > Subject: Re: Win2000 Conformance Test Results... > > > Hmmm, I meant to send this two days ago... > > > On Tue, 10 Dec 2002, David Fraser wrote: > [...] > > for kernel32_test path, I got this additional error (before all the > others) > > I have made tons of fixes to the kernel/path test and it should now work > much better. I just uploaded the new version of the tests compiled from > my sources. One can download them from the usual URL: > > http://fgouget.free.fr/wine/winetests.zip > > > [...] > > >process: 116 tests executed, 0 marked as todo, 4 failures. > > > > > Exactly the same except I have 10 messages interspersed with these, > saying: > > tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. > > Why these extra messages? > > Because this executable invokes itself to test CreateProcess. And each > time it exits it prints statistics about how many tests passed and > failed, although the child processes are not actually performing any > test. So these messages can be ignored. > > > > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:218: Test failed: (6) > > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:219: Test failed: (6,43) > > >h:\wine\wine\dlls\shlwapi\tests\shreg.c:220: Test failed: > (3435973836) > [...] > > Same but I get 0 for all your 3435973836 which is 0xcccccccc. Must be > a > > debug/release build thing - variable not being initialized. > > Should not be the case. The code does: > dwType = -1; > dwRet = SHQueryValueExA( hKey, "Test3", NULL, &dwType, NULL, > &dwSize); > ok( dwType == REG_SZ, "(%lu)" , dwType); > > So we should either get -1 or something that makes sense, not > 0xcccccccc. This needs to be investigated more. > > > > Should we print out some of these results in hex as well to make life > > easier? > > We should print them in just one format, decimal or hex, whichever makes > more sense. > > > > >I will now be concentrating on working out what is wrong with these > > >tests :) > > Yep, I think this is priority number one now. Running the tests on more > platforms would only return pretty much the same list of bugs again and > again. > > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > Any sufficiently advanced bug is indistinguishable from a feature. > -- from some indian guy > > > > > > > --__--__-- > > Message: 4 > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Reply-To: dpaun(a)rogers.com > Organization: DSSD Software Inc. > To: Waldek Hebisch <hebisch(a)math.uni.wroc.pl>, wine-devel(a)winehq.com > Subject: Re: strcasecmp > Date: Thu, 19 Dec 2002 11:48:23 -0500 > > On December 19, 2002 09:26 am, Waldek Hebisch wrote: > > If we are going to seriously support mingw then we need "mingw headers". > > I am not sure if true mingw headres are different enuugh from normal > > wine and msvcrt headers to warrant extra subdirectory, but logically > > they form a separate set. I suggest to put conditionls (if needed) in > > msvcrt headers corresponding to mingw headers, and make a separate > > subdirectory for mingw headers which emulate Unix headers. > > Right. I haven't looked at the mingw headers, but I assume they are > rather similar to the ones in glibc. If that's the case, we can > reuse those (if you have gcc which you have to anyway if you want to > use the mingwrap stuff): > > [dimi(a)dimi wine.src]$ sed -n 290,296p /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/stddef.h > #ifndef __WCHAR_TYPE__ > #define __WCHAR_TYPE__ int > #endif > #ifndef __cplusplus > typedef __WCHAR_TYPE__ wchar_t; > #endif > #endif > > Which means we can simply -D__WCHAR_TYPE__=unsigned\ short > > But we still can not link. For that, we need to reimplement all wchar_t > using functions, and link those in before the glibc ones. Linking tricks > are not my strenght, anyone know how we can do that? Does it work to > just place a lib with those symbols first in the -l list? > > -- > Dimi. > > > --__--__-- > > Message: 5 > Date: Thu, 19 Dec 2002 10:36:14 -0700 > From: Tony Lambregts <tony_lambregts(a)telusplanet.net> > To: Joerg Mayer <jmayer(a)loplof.de> > CC: "Dimitrie O. Paun" <dpaun(a)rogers.com>, wine-devel(a)winehq.com > Subject: Re: Update to patches sgml > > Joerg Mayer wrote: > > >On Thu, Dec 19, 2002 at 01:10:52AM -0500, Dimitrie O. Paun wrote: > > > > > >>This should read "Patches should be inlined (if you can configure your email > >>client to not wrap lines), or attached as text/plain attachements...." > >> > >> > > > >Maybe you should include a step by step instruction for outlook users > >how to do that. It seems that outlook is the leading misattachment generator, > >so instead of just telling people what NOT to do, maybe you can tell > >people how to do it right. > > > > > > > Well I suppose I could if I had those instructions. However it seems out > of scope for a style section. AFAIK just giving the patch a .txt > extention and attaching will solve the problem for most mailers > including outlook. > > -- > > Tony Lambregts > > > > > > --__--__-- > > _______________________________________________ > wine-devel mailing list - wine-devel(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-devel > > > End of wine-devel Digest > >

1 0

HELP: DEVMODE def
by Dimitrie O. Paun Dec. 19, 2002

Dec. 19, 2002

Thanks for the help guys, Here is another one: the DEVMODE structure. Ours: typedef struct { BYTE dmDeviceName[CCHDEVICENAME]; WORD dmSpecVersion; WORD dmDriverVersion; WORD dmSize; WORD dmDriverExtra; DWORD dmFields; union { struct { SHORT dmOrientation; SHORT dmPaperSize; SHORT dmPaperLength; SHORT dmPaperWidth; } DUMMYSTRUCTNAME1; POINTL dmPosition; } DUMMYUNIONNAME1; SHORT dmScale; SHORT dmCopies; SHORT dmDefaultSource; SHORT dmPrintQuality; SHORT dmColor; SHORT dmDuplex; SHORT dmYResolution; SHORT dmTTOption; SHORT dmCollate; BYTE dmFormName[CCHFORMNAME]; WORD dmLogPixels; DWORD dmBitsPerPel; DWORD dmPelsWidth; DWORD dmPelsHeight; DWORD dmDisplayFlags; DWORD dmDisplayFrequency; DWORD dmICMMethod; DWORD dmICMIntent; DWORD dmMediaType; DWORD dmDitherType; DWORD dmReserved1; DWORD dmReserved2; DWORD dmPanningWidth; DWORD dmPanningHeight; } DEVMODEA, *PDEVMODEA, *LPDEVMODEA; MinGW: typedef struct _devicemodeA { BYTE dmDeviceName[CCHDEVICENAME]; WORD dmSpecVersion; WORD dmDriverVersion; WORD dmSize; WORD dmDriverExtra; DWORD dmFields; short dmOrientation; short dmPaperSize; short dmPaperLength; short dmPaperWidth; short dmScale; short dmCopies; short dmDefaultSource; short dmPrintQuality; short dmColor; short dmDuplex; short dmYResolution; short dmTTOption; short dmCollate; BYTE dmFormName[CCHFORMNAME]; WORD dmLogPixels; DWORD dmBitsPerPel; DWORD dmPelsWidth; DWORD dmPelsHeight; DWORD dmDisplayFlags; DWORD dmDisplayFrequency; DWORD dmICMMethod; DWORD dmICMIntent; DWORD dmMediaType; DWORD dmDitherType; DWORD dmICCManufacturer; DWORD dmICCModel; } DEVMODEA,*LPDEVMODEA,*PDEVMODEA; -- Dimi.

3 2

Re: Import or ntdll
by Alexandre Julliard Dec. 19, 2002

Dec. 19, 2002

"Jeff Smith" <whydoubt(a)hotmail.com> writes: > Realized that ntdll was not needed in the IMPORTS list. I have tested > this in Linux and have not encountered any problems. It is needed. You don't see a problem on Linux because winebuild adds that import automatically in most cases, but it will break Reactos etc. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: HELP: DEVMODE def
by Jeff Smith Dec. 19, 2002

Dec. 19, 2002

At a glance, for wine's to conform with VC6's: 1.) "SHORT" -> "short" 2.) dmICMMethod and below only if WINVER >= 0x0400 3.) dmPanningWidth and below only if WINVER >= 0x0500 or _WIN32_WINN >= 0x0400 4.) Windows has no DUMMY*NAME*'s -- Jeff S >From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > >Thanks for the help guys, > >Here is another one: the DEVMODE structure. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

Re: another wtypes addition
by Dimitrie O. Paun Dec. 19, 2002

Dec. 19, 2002

On December 19, 2002 02:32 pm, Ove Kaaven wrote: > This is the last of the definition shuffling I had to do before my > (rewind) build tree compiled with a replaced objidl.h. So we should be able to get rid of the include/wine/obj_*.h soon? -- Dimi.

2 1

HELP: RECT definition
by Dimitrie O. Paun Dec. 19, 2002

Dec. 19, 2002

Can someone please check the MS headers for the RECT definition? In our definition, we use INT, while the MinGW people use LONG. Which one is correct? Ours: typedef struct tagRECT { INT left; INT top; INT right; INT bottom; } RECT, *PRECT, *LPRECT; MinGW: typedef struct tagRECT { LONG left; LONG top; LONG right; LONG bottom; } RECT,*PRECT,*LPRECT; -- Dimi.

2 1

Re: Update to patches sgml
by Jeff Smith Dec. 19, 2002

Dec. 19, 2002

Hotmail better get their act together or I will have to go elsewhere. Leading spaces are getting dropped when I inline and even when I attach as a TXT file. The only way it will let all my patches through unharmed is by leaving the extension as DIFF. I have several patches in my queue, but have been reluctant to send them out until I get this resolved. -- Jeff S >From: Tony Lambregts <tony_lambregts(a)telusplanet.net> > >Joerg Mayer wrote: > >>On Thu, Dec 19, 2002 at 01:10:52AM -0500, Dimitrie O. Paun wrote: >> >> >>>This should read "Patches should be inlined (if you can configure your >>>email >>>client to not wrap lines), or attached as text/plain attachements...." >>> >>> >> >>Maybe you should include a step by step instruction for outlook users >>how to do that. It seems that outlook is the leading misattachment >>generator, >>so instead of just telling people what NOT to do, maybe you can tell >>people how to do it right. >> >> >> >Well I suppose I could if I had those instructions. However it seems out of >scope for a style section. AFAIK just giving the patch a .txt extention and >attaching will solve the problem for most mailers including outlook. > >-- > >Tony Lambregts _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

2 1

Re: Update to patches sgml
by Dimitrie O. Paun Dec. 19, 2002

Dec. 19, 2002

On December 18, 2002 07:10 pm, Tony Lambregts wrote: > In an effort to start a flame war <g> I decided to add a few notes about > style to patches.sgml and while I was at it I added a note about being > able to submit non cvs patches. + Patches should be attached so that they can be read inline. This + may mean some more work for you. However it allows others to review + your patch easily and increase the chances of it not being + overlooked or forgotten. This should read "Patches should be inlined (if you can configure your email client to not wrap lines), or attached as text/plain attachements...." -- Dimi.

3 3

Re: Update to patches sgml
by Dimitrie O. Paun Dec. 19, 2002

Dec. 19, 2002

On December 19, 2002 01:56 am, Tony Lambregts wrote: > Not a bad idea. how's this then. Better. Did you look at this: http://www.winehq.com/hypermail/wine-devel/2002/09/0127.html The rules detailed in there are still valid: -- unified diff only (required) -- have a decent subject (recommended) -- a long description (optional, if the change warrants it) -- a meaningful ChangeLog entry (required) -- new files, if any, included in patch, diffed against /dev/null (required) -- patch inlined at the end of the message (recommended) -- one changeset per message What about including them in point-form for clarity, with some rationale (as you did) for things like patch inlining, etc. Idea being that one shouldn't have read the entire story if he/she only wants to see the rules. The story is good for first timers that want to understand why we have these rules/recommendations, so we can easily point them to them instead of having to answer it in long email every time... :) -- Dimi.

2 1

Re: [D3D8 PATCH] d3d8 shaders update - VS2
by Jeff Smith Dec. 19, 2002

Dec. 19, 2002

Yes, the version of vim that came with (I believe) Red Hat 6.0 has the definitions in its syntax file for proper "#if 0" highlighting. As common a practice as this has become, any syntax-highlighting editor with some degree of maturity that did *not* have this in its default rulesets for C/C++ would surprise me. What language-independent, syntax-highlighting text editor are you using? -- Jeff S >From: Fabian Cenedese <Cenedese(a)indel.ch> > >> > >/* note about reason for commenting block */ >> > >#if 0 >> > >code >> > >code /* comments */ >> > >code >> > >#endif >> > >> > Whereas this is the solution with the least work it's also hard to >>spot. If >> > using >> > a text editor with syntax coloring it all looks the same. But if a code >>isn't >> > effective I'd like to see that. >> >>Actually it could be considered as an editor fault if it changes color for >>commented out code but doesn't recognize the #if 0/#endif construct. > >I wouldn't say so. A comment is easily recognized by the chars /* */ or //. >But to get a #if 0 or #if _ANYTHING you really need a language dependant >preprocessor which goes beyond a normal text editor, even one with >syntax coloring. >Do you have such a text editor that finds #if's? > >bye Fabi _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

3 2