About WineLib : there is a lack of API in wine

[Kevin]

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
[e-mail]
----- Original Message -----
From: 
To: 
Sent: Friday, December 20, 2002 2:00 AM
Subject: wine-devel digest, Vol 1 #1519 - 5 msgs
> Send wine-devel mailing list submissions to
> [e-mail]
>
> 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
> [e-mail]
>
> You can reach the person managing the list at
> [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wine-devel digest..."
>
> Today's Topics:
> - Re: [D3D8 PATCH] d3d8 shaders update - VS2 (David Laight)
> - Re: [D3D8 PATCH] d3d8 shaders update - VS2 (Zsolt Rizsanyi)
> - RE: Win2000 Conformance Test Results... (Kye Lewis)
> - Re: strcasecmp (Dimitrie O. Paun)
> - Re: Update to patches sgml (Tony Lambregts)
>
> --__--__--
>
> Message: 1
> Date: Thu, 19 Dec 2002 14:54:21 +0000
> From: David Laight 
> To: "Dimitrie O. Paun" 
> Cc: Fabian Cenedese , [e-mail]
> 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: [e-mail]
>
> --__--__--
>
> Message: 2
> From: Zsolt Rizsanyi 
> To: Fabian Cenedese , [e-mail]
> 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" 
> To: "'Francois Gouget'" 
> Cc: [e-mail]
> 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
> [e-mail]
> (New email address! [e-mail] 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: [e-mail] [mailto:[e-mail]]
> On Behalf Of Francois Gouget
> Sent: Friday, December 13, 2002 8:58 AM
> To: David Fraser
> Cc: Kye Lewis; [e-mail]
> 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         [e-mail]        http://fgouget.free.fr/
>       Any sufficiently advanced bug is indistinguishable from a feature.
>                             -- from some indian guy
>
> --__--__--
>
> Message: 4
> From: "Dimitrie O. Paun" 
> Reply-To: [e-mail]
> Organization: DSSD Software Inc.
> To: Waldek Hebisch , [e-mail]
> 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@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 
> To: Joerg Mayer 
> CC: "Dimitrie O. Paun" , [e-mail]
> 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  -  [e-mail]
> http://www.winehq.com/mailman/listinfo/wine-devel
>
> End of wine-devel Digest