Hi,
I'm rather new to wine developement, and Xlib coding, and this is my first
post to the list so bare with me please ;-)
dlls/x11drv/event.c seems to freeze at XFilterEvent and brings the app to
seizure ever since all the TSX functions have been gotten rid off...
This is what happens:
Joshua Walker wrote:
I know this all may seem bit anal,
The more anal the merrier if you ask me...
what with about a
few thousand spec'ed APIs that need to be documented
and all.
I think this is a grand idea!
I would just like to fill in the blankes as
much as possable the first time
Boaz Harrosh wrote:
And while we are at it. What is the wine policy about Built-in DLLs
versions. I have encountered problems where setups where complaining
about versions been 0.0.0.0 and also some other not high enough
versions. Should we make a quick study about Windows versions and serve
Thanks
OK lets start with an oldy Just to see if I get the tools right:
patch
see attachment
/patch
should I embed or attach?
some explanations:
The original Idea was proposed by Ove Kaaven (see
__declspec(selectany) thread in wine-devel)
The original Idea did not go so well because in
Vik wrote:
Hi,
I'm more than willing to try and fix this, as XIM support is critical for
people from my part of the world (Japan, and most likely for Korea China).
We've been coming up with rather crude patches to have XIM work till now(upto
20031118), but can't get it to work because of this
Dmitry Timoshkov wrote:
Dimitrie O. Paun [EMAIL PROTECTED] wrote:
An explicit list of MCI_ commands/MCIWNDM_ messages/MCIWNDF_ flags
would be much appreciated (if it's under 30ish items). This would
give a much better indication of the amount of work left to do.
You are right, but it's too
Tom [EMAIL PROTECTED] wrote:
Okay, its tommorow a list please
The list is in the source, have a look. Moreover it's 31 Dec
evening here, and everything suggests to get a rest and do some
preparations for the celebration...
With coming Happy New Year everyone!
--
Dmitry.
Hi!
Does anybody have a C algorithm to rename a registry section using the
Win32 API?
I need such a thing for winecfg, but Win32 doesn't seem to have a
RegKeyRename api-call...
Grtz,
Robert
On Sat, 27 Dec 2003, Shachar Shemesh wrote:
Dmitry Timoshkov wrote:
Shachar Shemesh [EMAIL PROTECTED] wrote:
This is a request to understand, not a suggestion (yet?).
Why not use a general purpose DB system? (postgresql, mysql, whatever)
After all, the registry is just a tree shaped
2 Questions
1) if I do make depend than edit unknwn.idl (or any other idl) than do
make should a new unknwn.h be compiled?
Well it does not. If I cd include and make than nothing is done
either. only if I do make unknwn.h it will compile.
2) In order for ATL to compile I need below code in my
Hi,
I made the regedit program able to add new registry key (however, the
key does not appear until next run of regedit in the browser tree - as I
consulted it with Dimitrie, it will be handled later).
The diff is made against todays cvs tree (as 2003 december 31).
Attila
PS: Dimitrie: what
On Tue, 30 Dec 2003, Alexandre Julliard wrote:
I'm not sure whether you want to make this change in general, for all
platforms, so for now I have embedded it in an #if(n)def.
I think we should do that on all platforms, yes. And you probably want
to fix OSS_WaveInInit too.
Good catch! As
On December 31, 2003 04:38 am, Boaz Harrosh wrote:
they were/are protected, but I think it should be removed from winegcc
because they don't do the Job.
Maybe, I'm not sure. I'll let Alexandre comment on the ms-extensions.h
idea. In general, he does not like non-standard headers...
Please
Dimitrie O. Paun [EMAIL PROTECTED] writes:
On December 31, 2003 04:38 am, Boaz Harrosh wrote:
they were/are protected, but I think it should be removed from winegcc
because they don't do the Job.
Maybe, I'm not sure. I'll let Alexandre comment on the ms-extensions.h
idea. In general, he
On December 31, 2003 11:18 am, Zimler Attila wrote:
Cool, here are a few comments on the patch:
+ /* Modified by Attila ZIMLER [EMAIL PROTECTED] on 28th of dec 2003.
+ - New key adding is now supported.
+ */
Please don't add such stuff in the headers, this goes automatically in
the CVS
n Wed, 2003-12-31 at 17:36, Dimitrie O. Paun wrote:
Maybe because crashing is the right thing to do in many cases,
Why? I'd have thought failing the API call would be more sensible, or
doing what GTK does and printing assertion failures. But hey. Crashing
is what Win32 does, so it's what we do.
On December 31, 2003 03:29 pm, Mike Hearn wrote:
Maybe because crashing is the right thing to do in many cases,
Why? I'd have thought failing the API call would be more sensible, or
Because it's bad policy: it's better to fail early and as close as
possible to the error point, rather then let
Happy New Year from the Central European Time Zone!
Ivan.
Hi,
I wrote to the list a few weeks ago. I needed to support a USB device
without changing the Windows dll that I have to use. I was trying to
hack into wine to implement support for the USB device using
CreateFile() and DeviceIoControl(). That was not a clean solution.
The author of the
Robert Shearman [EMAIL PROTECTED] writes:
make idl will make all of the idl files. I'm not sure why it is done this
way, but those files are only updated once in a blue moon anyway.
Because building them automatically causes a lot of headaches when
generating dependencies. I'll get around to
Boaz Harrosh [EMAIL PROTECTED] writes:
Until recently 95% of the work was done on wine. WineLib was a side effect.
Look what happens, if I have a -wrap application (C++) I need to
place a link to it in WINEDLLPATH to even load. and also to all it's
supporting DLLs (I know I have 36 of them).
ons, 31.12.2003 kl. 17.48 skrev Robert Shearman:
No. You should use cpp_quote. It may be necessary to disable stuff in the .h
generated file which you can do with:
You can't use cpp_quote inside an interface definition. The quoted text
would end up before the generated type, not inside. For
22 matches
Mail list logo
