On Dec 15, 2007 11:27 PM, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
> James Hawkins wrote:
> > On Dec 15, 2007 11:02 PM, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
> >> Dmitry Timoshkov wrote:
> >>> Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl ->
> >>> opengl32,
> >>> wine-use
"Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
>> If the component exists it should be named properly, i.e. represent the DLL
>> it belongs to in order to avoid a possible confusion.
>>
> That's the part I'd like to avoid. Unless we want to list most of the
> subsystems in keywords, that span sma
Dmitry Timoshkov wrote:
> "Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
>
>>> Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl ->
>>> opengl32,
>>> wine-user -> user32
>>>
>> Why do you want "32" at the end? Also note that opengl32 is a thunk
>> dll. Most of it's code somewhere els
James Hawkins wrote:
> On Dec 15, 2007 11:02 PM, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
>> Dmitry Timoshkov wrote:
>>> Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32,
>>> wine-user -> user32
>>>
>> Why do you want "32" at the end? Also note that opengl32 is a thunk
"Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
>> Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32,
>> wine-user -> user32
>>
> Why do you want "32" at the end? Also note that opengl32 is a thunk dll.
> Most of it's code somewhere else.
If the component exists it should
On Dec 15, 2007 11:02 PM, Vitaliy Margolen <[EMAIL PROTECTED]> wrote:
> Dmitry Timoshkov wrote:
> > Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32,
> > wine-user -> user32
> >
> Why do you want "32" at the end? Also note that opengl32 is a thunk dll.
> Most of it's code
Dmitry Timoshkov wrote:
> Rename wine-kernel -> kernel32, wine-ole -> ole32, wine-opengl -> opengl32,
> wine-user -> user32
>
Why do you want "32" at the end? Also note that opengl32 is a thunk dll.
Most of it's code somewhere else.
> Add gdi32, ntdll, oleaut32, rpcrt4 and any other missing DLL
On Dec 15, 2007 10:45 PM, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> "James Hawkins" <[EMAIL PROTECTED]> wrote:
>
> > Yes, can someone with sufficient privileges enact what was agreed upon
> > by the majority in this thread:
> >
> > http://www.winehq.org/pipermail/wine-devel/2007-October/059715.
"James Hawkins" <[EMAIL PROTECTED]> wrote:
> Yes, can someone with sufficient privileges enact what was agreed upon
> by the majority in this thread:
>
> http://www.winehq.org/pipermail/wine-devel/2007-October/059715.html
>
> To summarize:
>
> * Change all wine-X components to just X.
> * Remov
On Dec 15, 2007 10:19 PM, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
>
> "Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
>
> > Please add these new components:
> >
> > wine-vdm - Wine 16-bit compatibility layer
> > wine-comdlg - Common dialogs such as open/save/print/font
>
> (it either should be wi
"Robert Shearman" <[EMAIL PROTECTED]> wrote:
> This isn't done in MIDL, but I think it's desirable both for silencing
> Valgrind warnings and for security purposes (fixes potential for leaking
> information to remote computers or other processes).
> +print_file(file, indent, "memset(_StubMs
Dmitry Timoshkov wrote:
> "Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
>
>> Please add these new components:
>>
>> wine-vdm - Wine 16-bit compatibility layer
>> wine-comdlg - Common dialogs such as open/save/print/font
>
> (it either should be wine-commdlg, or wine-comdlg32 IMO)
Doesn't matter t
"F Capela" <[EMAIL PROTECTED]> wrote:
> A small fix to those who play games using keyboard layouts with
> deadkeys. Patch generated against 0.9.51 release.
> Wine currently don't pass keypress events to the windows executable
> when the keypress is either a deadkey or follows a deadkey. This makes
"Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
> Please add these new components:
>
> wine-vdm - Wine 16-bit compatibility layer
> wine-comdlg - Common dialogs such as open/save/print/font
(it either should be wine-commdlg, or wine-comdlg32 IMO)
What's happened to the proposal to remove the wine
Sorry for answering a little late.
Lionel Tricon wrote:
> In fact, we overload a lot of common system call from the standard libc. We
> have slightly modified the fackechroot library and we need to trap almost all
> system calls linked to the filesystem.
I have just (a couple of weeks ago) sta
Here's my second attempt at this, this time merging FBO draw buffer
selection into ActivateContext. Could you please review it?
Hopefully I'm going in the right direction. The first patch moves the
call to ActivateContext before the GL calls that setup the blit. This
is needed so the second patc
Please add these new components:
wine-vdm - Wine 16-bit compatibility layer
wine-comdlg - Common dialogs such as open/save/print/font
Vitaliy.
Am Samstag, 15. Dezember 2007 12:19:36 schrieb Alexander Dorofeyev:
> This seems to be specific to front buffer. Maybe
> glFlush really should be called in BltOverride (or clearing subroutine) if
> the target is front buffer?
Yes, glFlush() has to be called when writing to the front buffer. SwapBuf
On Sat, 15 Dec 2007, Stefan Dösinger wrote:
> Am Samstag, 15. Dezember 2007 01:19:05 schrieb Francois Gouget:
> > On Wed, 12 Dec 2007, Stefan Dösinger wrote:
> > [...]
> >
> > > It is the intention of this patch, and coming ones, to clean up the 24/32
> > > bpp mess, also with regard to 15/16 bpp
On Saturday 15 December 2007 10:01:44 Adam Rimon wrote:
> Yeah, I read it. Can you explain to me the logic behind this decision
> (In general, not about this specific code)?
You mess up the output of e.g. git blame without ever changing the
functionality of the code.
> I think formatting a code
Yeah, I read it. Can you explain to me the logic behind this decision
(In general, not about this specific code)?
I think formatting a code is an important thing to do.
It makes the code easier to understand for programmers who have never
seen the code before,
and makes it also more maintain
21 matches
Mail list logo
