Den 17. juni 2011 16:38, skrev joerg-cyril.hoe...@t-systems.com:
> Hi,
>
> I vaguely remember reading about a quite low limit on the number of
> event objects that a thread can hold because each one is said
> to take up one bit in some 32 or 64 bit mask.
You should probably clarify what you mean,
Den 08. april 2011 13:15, skrev joerg-cyril.hoe...@t-systems.com:
> DispatchMessage is not always needed. Unfortunately, I don't grok
> yet when DispatchMessage is required.
>
> http://blogs.msdn.com/b/oldnewthing/archive/2004/06/08/150929.aspx
> "Everybody who has messed with window messaging kn
Steven Edwards skrev:
> On Mon, Feb 15, 2010 at 4:05 PM, Ove Kaaven wrote:
>> Sure it might be confusing, because that's not how the logic goes in the
>> Microsoft world. Over there, the big machine acting as Terminal Server
>> thing is the server, and the Remote Desk
Steve Brown skrev:
> On Mon, 15 Feb 2010, Ove Kaaven wrote:
>
>> James McKenzie skrev:
>>> I'll agree that this is duplication of the existing X11 code, but the
>>> effect is more pleasant to the eye and leads to less user confusion, not
>>> to speak
James McKenzie skrev:
> I'll agree that this is duplication of the existing X11 code, but the
> effect is more pleasant to the eye and leads to less user confusion, not
> to speak of a less expensive solution (I have yet to find a 'free' X11
> client that is worth anything on Windows.)
You mean X
Jacek Caban skrev:
> It does suffer from this bug, these tests are probably not enough to
> show it.
Hmm. I had hoped the debian version had patched it or something,
especially considering how often stdcall is going to be used by a win32
compiler...
>> I'm not sure what to do about this. Any idea
OK, I've almost got a wine-gecko package built 100% from source, but
there's a problem: the gcc version in Debian's mingw32, namely gcc
4.2.1-sjlj, apparently miscompiles the wine-gecko 1.0.0 sources, the
resulting Gecko just crashes. (The mingw32 version in oldstable, 3.4.5
something, compiles it
Scott Ritchie skrev:
> Ove Kaaven wrote:
>> Ben Klein skrev:
>>> Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net
>>> repository? It's just the pre-packaged cab file stored in
>>> /usr/share/wine/gecko.
>> That's the reason I&
Sir Gallantmon skrev:
> Sorry, I think of the word "toolchain" differently I guess. I always
> considered a toolchain to include both tools and common libraries, as
> Fedora did. I was aware of the MinGW compiler offered in the Debian
> package repository, but with no libraries, I considered it use
Sir Gallantmon skrev:
> I don't think I have seen any distribution include wine-gecko. Fedora
> seems to be in the best position to finally make a wine-gecko package,
> since it now provides a MinGW toolchain.
Why does *that* put Fedora in the best position? Debian has had a MinGW
toolchain for ye
Ben Klein skrev:
> Have you looked at my wine-gecko-1.0.0 package at the lamaresh.net
> repository? It's just the pre-packaged cab file stored in
> /usr/share/wine/gecko.
That's the reason I'm not looking at it.
Anssi Hannula wrote:
However, the instructions on that page ask for copying binaries directly
provided in wine-mozilla tarball, and for modifying mingw32 headers.
It's probably also possible to generate these at package build time by
invoking the appropriate commands. If it's the lib*.a files,
Stefan Dösinger wrote:
> A related topic: How do Joysticks connected to the gameport work(which is the
> same hardware connector as MIDI). I think that a joystick already takes an
> entirely different path in the
Linux kernel and it doesn't get anywhere near a sound system, so we
don't have to bo
Roderick Colenbrander skrev:
> This audio engine is quite similar to
> pulseaudio and it offers functionality like per stream volume which
> normal APIs like oss/alsa/openal don't offer,
What?
If configured appropriately, ALSA can do it, although with the current
API it's not straightforward, as
Vincent Povirk skrev:
> On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven wrote:
>> (It is actually for similar reasons that binaries must be buildable on a
>> clean system (say, a build daemon), without any special (non-free) tools
>> or sourceless libraries. Magic libshell32.a
Jacek Caban skrev:
> Ove Kaaven wrote:
>> Jacek Caban skrev:
>>
>>> Well, I hope that a side effect of installation during wineprefix
>>> creation is that it will force packagers to package gecko
>>>
>>
>> You can't *force* the
Jacek Caban skrev:
> Well, I hope that a side effect of installation during wineprefix
> creation is that it will force packagers to package gecko
You can't *force* the creation of packages which would likely fail to
meet the requirements for inclusion into Debian's main archive. Even if
I didn't
Roderick Colenbrander skrev:
> On Mon, Oct 19, 2009 at 1:08 PM, Ove Kaaven wrote:
>> Roderick Colenbrander skrev:
>>> On Mon, Oct 19, 2009 at 12:45 AM, Austin English
>>> wrote:
>>>> On Sun, Oct 18, 2009 at 1:50 PM, James McKenzie
>>>>
Roderick Colenbrander skrev:
> On Mon, Oct 19, 2009 at 12:45 AM, Austin English
> wrote:
>> On Sun, Oct 18, 2009 at 1:50 PM, James McKenzie
>> wrote:
>>> Ove Kaaven wrote:
>>>> This makes it possible to work around bug 10080 without having to patch
>&g
Chris Robinson skrev:
> On Tuesday 22 September 2009 12:32:35 am Mike Kaplinskiy wrote:
>> It actually does not dereference anything.
>
> Does the C standard specify that taking the address of a struct member being
> dereferenced doesn't actually cause a dereference, instead just offsetting?
It
Luke Benstead skrev:
> If it IS the case that this doesn't cause a crash and is perfectly
> valid, can someone explain to me how/why this works? Or point me (no
> pun intended) to the bit in the C spec that explains it? Coz the way I
> read it, it has to dereference dmW, otherwise how would the com
Stefan Kuhr wrote:
> This is something quite common in Win32, as far as I can tell.
Yes, like I said, MSVC has special compiler support. In MSVC, __try,
__except, etc, are compiler builtins (not macros as in Wine). But they
are Microsoft extensions, they can't be implemented using standard C.
>
Stefan Kuhr wrote:
> In include/wine/exception.h, a comment from AJ says that
> "__EXCEPT(filter_func,param)" is the proper way to do it but "param"
> is not explained at all
I think that comment must be very old, the macros don't implement any
"param".
> So, how do I do these things in WINE pro
Martin Szydlowski wrote:
> I know I can get the Windows-PIDs using winedbg->info process but there
> is no trace of Unix PIDs there. Also, I need a scriptable way to do
> this, best being a small app that gets a Unix PID and prints the
> matching Windows PID to console.
I don't think there's curre
James McKenzie skrev:
> Ove Kaaven wrote:
>> Alexandre Julliard skrev:
>>
>>> Objections? Does anybody feel a strong need for a Changelog file?
>>>
>>
>> I've used it a lot to look up when stuff might have been fixed (or
>> broken
Alexandre Julliard skrev:
> Objections? Does anybody feel a strong need for a Changelog file?
I've used it a lot to look up when stuff might have been fixed (or
broken), and in general Debian packages are expected to ship a changelog
if possible.
Dmitry Timoshkov skrev:
> "Dan Kegel" <[EMAIL PROTECTED]> wrote:
>
>> For a maximal dogfood experience, I was looking around
>> for a way to use a replacement Windows shell with
>> Wine as my desktop environment instead of gnome
>> or kde.
>
> Built-in Wine explorer does a lot of things which the
Package: wnpp
Severity: normal
Since my time may be limited in the future, I am seeking comaintainers
for the Wine package in Debian, at least to ensure that new Wine releases
may continue to be uploaded in a timely fashion, and to keep the package's
bug count down. (And given that pretty much hal
Maarten Lankhorst skrev:
> Wine checks ownership of the socket and directory, so race conditions
> aren't really a problem. This means that despite being put in a public
> directory there is no chance of a race condition. I don't see a
> security risk here, if someone is evil they could create that
Maarten Lankhorst skrev:
> The latter won't work, they could create the directory and then delete
> it after wineserver started. I don't think it is really a problem, by
> the time someone else can put that directory in /tmp chances are that
> they can do a lot more malicious things then just makin
Erik de Castro Lopo skrev:
> Ove Kaaven wrote:
>
>> Erik de Castro Lopo skrev:
>>> Anybody understand why?
>> You could look up the definition of RTL_CRITICAL_SECTION_DEBUG in
>> include/winnt.h. Then realize that __WINESRC__ is only defined for stuff
>&
Erik de Castro Lopo skrev:
> Anybody understand why?
You could look up the definition of RTL_CRITICAL_SECTION_DEBUG in
include/winnt.h. Then realize that __WINESRC__ is only defined for stuff
in dlls/, not for stuff in programs/, which should make the type
mismatch clear.
Stephan Hermann skrev:
> When there are people interested in going a hard way of fixing todays
> situation in debian/ubuntu and other distris, please let's do it
> , sane and with a plan.
There's already work going on to try to get a better solution into
Debian lenny. There's a new "ia32-libs-too
Scott Ritchie skrev:
> Agreed. The one tricky thing here is making a proper "source" package.
> There is some precedent for source packages that don't actually build
> on the architecture they're for. The ia32-libs package, for instance,
> contains both binary and source versions of the 32 bit l
Benjamin M. Schwartz skrev:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ove Kaaven wrote:
> | Benjamin M. Schwartz skrev:
> |> I'm particularly surprised because I cannot imagine any reasonable
> |> scenario in which allowing non-root users to run in .win
Benjamin M. Schwartz skrev:
> I'm particularly surprised because I cannot imagine any reasonable
> scenario in which allowing non-root users to run in .wine/ directories
> that they do not own is a security risk. There is no privilege escalation
> here; the non-root user is still required by the k
Alexandre Julliard skrev:
> Ove Kaaven <[EMAIL PROTECTED]> writes:
>
>> Alexandre Julliard skrev:
>>> It depends if MSVC respects that ABI constraint or not.
>> Only if you want to make Wine depend on the compiler used to compile
>> Windows applications. No
Alexandre Julliard skrev:
> Ove Kaaven <[EMAIL PROTECTED]> writes:
>
>> But that's a bit of a different issue, unrelated to the kernel flaw. I
>> was only talking about that flaw. I kind of tried to clarify that in
>> my next followup... oh well.
>
> S
Alexandre Julliard skrev:
> Ove Kaaven <[EMAIL PROTECTED]> writes:
>
>> Francois Gouget skrev:
>>> Does anyone know if MSVC does a cld in the right places?
>> Maybe. But it hardly matters. Only GCC-generated code is affected. The
>> problem might then sh
Ove Kaaven skrev:
>> Does anyone know if MSVC does a cld in the right places?
>
> Maybe. But it hardly matters. Only GCC-generated code is affected.
In order to avoid confusion about my answer, I should probably clarify.
I was answering this question only:
"Could this kerne
Francois Gouget skrev:
>The problem revolves around the x86 direction flag (DF), which
>governs whether block memory operations operate forward through
>memory or backwards. GCC [...] 4.3.0, assumes that the direction flag
>has been cleared [...] at the entry of each function, as
James Hawkins skrev:
> On Wed, Mar 5, 2008 at 9:15 PM, Ove Kaaven <[EMAIL PROTECTED]> wrote:
>> James Hawkins skrev:
>>
>>> The tests that now pass with native cabinet dll are test_continuouscab
>> > (which is similar to what you're trying to test
James Hawkins skrev:
The tests that now pass with native cabinet dll are test_continuouscab
(which is similar to what you're trying to test). The point of
maxsize is so that it creates continuous cabs...there's no other way
to do it, and builtin doesn't create continuous cabs at all.
No? Then
James Hawkins skrev:
> A lot of time has been spent fixing cab/media related bugs in
> installers, as the behavior is very fickle (and easily breakable), so
> can you please add a test case first? See the multicab tests that are
> already in install.c. They will fail in wine because our cabinet.d
Stefan Dösinger skrev:
> A few proposed topics:
>
> * Relative mouse movements
> * A few new GL extensions. Only partially concerns Xorg, but I think it is
> reasonable to present them there in the hope that ATI, Nvidia and Mesa people
> are there.
> -> Flat shading vertex colors
> -> sRGB wri
Dan Kegel skrev:
> On Jan 2, 2008 2:57 PM, Reece Dunn <[EMAIL PROTECTED]> wrote:
>> Are there any plans to use cairo in the Wine gdiplus implementation
>> like mono does?
>
> Not that I know of. But I don't think that's a problem.
>
> I think a more interesting question is, when are we going to
Daniel Nylander skrev:
> On ons, 2008-01-02 at 18:29 +0800, Dmitry Timoshkov wrote:
>> "Daniel Nylander" <[EMAIL PROTECTED]> wrote:
>>
>>> I noticed that the Norwegian (bokmål) locale files are using the locale
>>> "no". Correct locale for Norwegian Bokmål is "nb" (Nynorsk is "nn").
>> I don't see
Scott Ritchie skrev:
> If I wanted a Wine package to include mono and gecko, what would the
> best way to do this be?
>
> I know we support having gecko installed somewhere on the filesystem so
> it doesn't have to be downloaded (where?), but would I need to make any
> further changes other than a
ons, 29,.06.2005 kl. 20.11 -0400, skrev Anderson Lizardo:
> Changelog: Check for common broken nVidia+Mesa OpenGL library setups.
> http://cvs.winehq.org/cvsweb/wine/Attic/configure.in.diff?r1=1.247&r2=1.248&f=h
>
> The current "test" check definitely does not ensure the system doesn't
> have this
søn, 19,.06.2005 kl. 16.07 +0100, skrev Mike Hearn:
> On Sat, 2005-06-18 at 05:12 -0400, Ove Kaaven wrote:
> > That OpenGL hotfix is for 1.5.0 (improved ARB_pixel_format, something
> > Wine already have). The VM issue this thread is about is in 1.5.1. This
> > is not the f
fre, 17,.06.2005 kl. 15.12 +0100, skrev Mike Hearn:
> Well, I don't think Alexandre has a WoW account or copy and there isn't
> enough information here to see what's going on. It's odd that seems VM
> layout related though. The issue looks like it's in OpenGL though, their
> "1.5 patch hotfix" is a
søn, 12,.06.2005 kl. 14.17 -0700, skrev Scott Ritchie:
> This sounds like a good summer project for me to tackle while I'm
> redoing the rest of the documentation. Phasing out c2man has been a
> long time coming.
As far as this bug is concerned, though, Wine already have, and now use
its own c2ma
tir, 07,.06.2005 kl. 23.00 -0700, skrev David Albrecht:
> VOID CreateLcdBitmap(VOID)
> {
> // create LCD bitmap
> _ASSERT(nLcdDoubled == 1 || nLcdDoubled == 2 || nLcdDoubled == 4);
> bmiLcd.Lcd_bmih.biWidth = LCD1_ROW * nLcdDoubled;
> bmiLcd.Lcd_bmih.biHeight = -64 * nLcdDou
fre, 20,.05.2005 kl. 00.35 -0600, skrev Brian Vincent:
> Also, anyone happen to know if Wine can be used in conjunction with
> binfmt alongside Mono? Are there any unique C# identifiers in the
> first 128 bits of a .Net executable that could identify it? It
> appears the Mono guys recommend looki
man, 28,.02.2005 kl. 11.23 -0600, skrev Jeremy White:
> In other words, afaict, the current code computes the difference
> between the number of bytes that have been played from the input
> source stream (buf_writepos) and the end of the data the app has
> written (probably_valid_to). It then clip
tor, 24,.02.2005 kl. 22.56 -0600, skrev Jeremy White:
> Case 1: In the first case, in DSOUND_MixOne, we compute
> a 'probably_valid_to' based on the 'write_pos', which seems quite
> wrong; I believe the logic should be testing whether or not
> there is sufficient data in the mixing buffer, not whe
fre, 14,.01.2005 kl. 13.06 +1100, skrev Con Kolivas:
> Well the scheduler is not going to be rewritten any time soon (trust me,
> I've tried :P). Tell me what remaining requirements your threads have
> that you are unable to achieve at the moment and I'll see if I can help
> with my understandin
ons, 12,.01.2005 kl. 12.01 -0600, skrev Jeremy White:
> Second, we did not synchronize Wine message times with X11
> message times properly. Fixing that resolved some issues
> with Photoshop (and given that Ove reworked that patch into
> WineX the same day I submitted it, I'd guess it fixed some
>
tor, 16.09.2004 kl. 01.47 skrev Francois Gouget:
> On Tue, 14 Sep 2004, Robert Reif wrote:
> [...]
> > OK. Here is the beginnings of a joystick test. I want to use
> > c_dfDIJoystick2 which is defined as extern in dinput.h and exists in
> > dinput.dll.so but is not exported. It's also not export
tir, 31.08.2004 kl. 05.23 skrev [EMAIL PROTECTED]:
> On Mon, Aug 30, 2004 at 08:52:04AM +0200, Ove Kaaven wrote:
> > It's not. Linux only allows non-root processes to reduce its priority,
> > not increase it, even for non-real-time priorities. Windows, however,
> > a
man, 30.08.2004 kl. 02.50 skrev [EMAIL PROTECTED]:
> As I recall, most apps fall under two catagories (basically): a) those
> who don't bother with priority (they use the default one, mostly toward
> lesser end users and general audiences) and b) those who allow the user
> to change this via a menu
søn, 29.08.2004 kl. 13.31 skrev Mike Hearn:
> On Sun, 29 Aug 2004 09:51:30 +0200, Ove Kaaven wrote:
> > A book I have described how it works...
>
> Hi Ove,
>
> I remember TransGaming had some problems with kernel 2.6 scheduling: did
> you guys ever get to the bottom o
søn, 29.08.2004 kl. 11.43 skrev Robert Shearman:
> Ove Kaaven wrote:
>
> >søn, 29.08.2004 kl. 04.13 skrev Michael Chang:
> >
> >
> >Also note that Windows allows a Win32 process to boost its own priority
> >all the way to what they call "real time".
søn, 29.08.2004 kl. 04.13 skrev Michael Chang:
> > I argued with myself about the logic in this for ages. The best I could
> > come up with is - I don't know :| I'd need to know about windows
> > scheduling (which I don't)
>
> Obviously, if Win apps have been written to expect this, there's
> do
fre, 06.08.2004 kl. 23.58 skrev Lionel Ulmer:
> > Couldn't find proc address for: wglSwapIntervalEXT
>
> I do not know any equivalent GLX extension for this.
GLX_SGI_swap_control is almost equivalent, it just doesn't have a query
function. It's probably not critical functionality though.
> > Cou
man, 26.07.2004 kl. 13.03 skrev Robert Shearman:
> I can't work out how IUnknown marshalling is getting delegated to the
> IClassFactory marshaller,
It shouldn't, as far as I know. Or, what exactly are you asking?
ons, 14.07.2004 kl. 18.07 skrev Mike Hearn:
> You might be wondering about putting threads next to processes and
> machines in that last paragraph. You can access thread safe objects from
> multiple threads without DCOM normally, right? Why would you need RPC
> magic to do that?
The answer is of c
man, 19.04.2004 kl. 17.03 skrev Robert Shearman:
> > Doesn't the "version" rule already handle this?
>
> It would appear not. The 'version' type is declared as a number further up
It's declared that the rule *returns* a number, you mean. The actual
rule is defined as
version:
aNUM
lør, 17.04.2004 kl. 18.53 skrev Robert Shearman:
> Hi,
>
> This patch adds support for several features I found lacking whilst
> attempting to generate headers for RPC interfaces.
Is this needed?
@@ -350,6 +354,7 @@
| tSWITCHTYPE '(' type ')' { $$ = make_attrp(ATTR_SWITCHTYP
lør, 27.03.2004 kl. 20.40 skrev Mike Hearn:
> On Sat, 27 Mar 2004 14:36:31 -0500, Robert Reif wrote:
> > Another problem is that drivers support different formats in different modes.
> > Because of software emulation in alsa, a driver may appear to support any
> > format but then fail when you try
tir, 16.03.2004 kl. 03.20 skrev Vincent Béron:
> Hi folks,
>
> Since wine.inf is now used as the source for the default values for the
> registry (via rundll32), importing it absolutely needs X (whereas the
> older regedit method didn't when importing a .reg file). This can be a
> problem for peop
søn, 29.02.2004 kl. 03.35 skrev Michael Pyne:
> I was wondering if there is a way I can help figure out what the problem is so
> that we can get this bug fixed.
You could always start with
http://www.winehq.org/hypermail/wine-devel/2002/07/0102.html
man, 23.02.2004 kl. 15.26 skrev Boaz Harrosh:
> If I may summarize what I understood. There are 2 options:
> 1) It would be best to take Samba-project implementation of RPC and
> implement wine's RPCRT4 over that. This way we are both wire-compatible
> with DCE RPC and also we can use a ready mad
man, 23.02.2004 kl. 09.26 skrev Boaz Harrosh:
> Ove Kaaven wrote:
>
> >I still think it would be better to use the Samba RPC client libraries
> >to interact with Wine's RPC implementation (rpcrt4). You wouldn't need
> >to implement a custom server to achiev
søn, 22.02.2004 kl. 22.49 skrev Robert van Herk:
> maman yonatan wrote:
>
> >so if I understand you properly, you say that there is
> >no way doing from _outside_ of wine (no matter what
> >kind of com object I have), is that correct?
> >
> Of course there is a way: you could make your own remote
søn, 22.02.2004 kl. 14.43 skrev maman yonatan:
> my question is there any way to write a client on the
> native (Linux) using g++ and activation the com
> object?
Perhaps it'd be possible to hack the Samba RPC client into doing that
with a little work... of course the Wine RPC server would also ha
lør, 14.02.2004 kl. 18.11 skrev Dimitrie O. Paun:
> On February 13, 2004 12:35 pm, Mike McCormack wrote:
> > OK, this time I've done it the right way, and it at least works for one
> > or two apps, with a screen shot to prove it.
>
> Very cool indeed Mike! One thing that I've noticed is that the c
tor, 12.02.2004 kl. 01.51 skrev Alexandre Julliard:
> Ove Kaaven <[EMAIL PROTECTED]> writes:
>
> > Incidentally, that means I also reversed his indentation suppression of
> > the arguments of these function pointers, but I don't see the "old"
> > in
fre, 06.02.2004 kl. 15.46 skrev Dimitrie O. Paun:
> On Fri, 6 Feb 2004, Ove Kaaven wrote:
>
> > Try win95. Wine currently only emulates the DOS long file name API on
> > win9x, since it did not exist on nt4.
>
> That makes no sense: we get short names on a system (nt4)
fre, 06.02.2004 kl. 13.16 skrev Fabian Cenedese:
> Hi
>
> I'm trying to find a file copy tool which works on windows as well as wine.
> I tried several and this looked promising:
>
> ftp://ftp.simtel.net/pub/simtelnet/msdos/fileutil/cc108dos.zip
>
> On Windows it copied all files without problem
ons, 04.02.2004 kl. 23.31 skrev Lionel Ulmer:
> > Then I would be drawing rectangles which are not ready for a redraw yet. Does
> > UnLock release only last lock or all locks on these old DX versions?
>
> Well, you need to store the rectangle at Lock time but only draw it at
> Unlock time. And I
tor, 05.02.2004 kl. 05.29 skrev Kevin Koltzau:
> On Wednesday 04 February 2004 10:32 pm, Kevin Koltzau wrote:
> > I am loading a 32bpp bitmap from resources of a dll, but under wine its
> > being reported as 24 bit..for example
>
> I think I actually found the answer to my own question..I'm always
-Videresendt melding-
From: Emmanuel Charpentier <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Bug#224498: A recipe of potential use to MS Office 97 aspiring users on Debian
Date: Mon, 12 Jan 2004 23:16:44 +0100
Dear Ove, dear Wine users and w(h)iners,
First, a
tor, 08.01.2004 kl. 12.52 skrev Mike Hearn:
> On Wed, 2004-01-07 at 23:39, Ove Kaaven wrote:
> > Well, I've done about as much as I dared do without knowing exactly what
> > plans you have. After all, widl can *not* link to oleaut32 since widl is
> > not a Winelib app (an
man, 05.01.2004 kl. 14.34 skrev Mike Hearn:
> On Mon, 05 Jan 2004 14:17:28 +0100, Ove Kaaven wrote:
> > Nobody has yet added typelib stuff to widl, eh... I guess I could whip
> > up a framework or something to help with that, since nobody else has yet
> > done it...
>
&
tir, 06.01.2004 kl. 23.16 skrev Alexandre Julliard:
> Ove Kaaven <[EMAIL PROTECTED]> writes:
>
> > Log:
> > Added rules to parse library, coclass, dispinterface, and module
> > definitions, and a number of attributes, and cleaned up a few things.
> > Start
man, 05.01.2004 kl. 02.07 skrev Robert Shearman:
> > I note that Win98 is about to be finally obsoleted. After this, it's
> > possible Microsoft will do the same as they did with IE and other stuff
> > for Win95 and pull downloads from their website. This is a problem,
> > because we currently need
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 in
ons, 31.12.2003 kl. 15.55 skrev Boaz Harrosh:
> 2) In order for ATL to compile I need below code in my unknwn.h file. I
> could not fined a way to do it with WIDL.
> I have looked in Microsoft (vc6) header/idl and it looks they had the
> same problem. And below code was added by hand.
If Microso
ons, 10.12.2003 kl. 08.24 skrev Shachar Shemesh:
> Alexandre Julliard wrote:
>
> >"Subhobroto Sinha" <[EMAIL PROTECTED]> writes:
> >
> >>However, soon many of his elves found out that technologies like
> >>MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too
> >>complex to be imple
tir, 30.09.2003 kl. 17.16 skrev Dimitrie O. Paun:
> On September 30, 2003 09:16 am, Ove Kaaven wrote:
> > Now the LGPL-ness of Wine
> > actually makes it an advantage to hold code back from Wine in some
> > circumstances, whether you and I like it or not.
>
> Your
tir, 30.09.2003 kl. 09.39 skrev Jonathan Wilson:
> > Everything that's LGPL should be listed on the above page. Additionally,
> > code in ReWind is X11. Anything else in WineX may be assumed AFPL, but
> > may also be released as X11 at TransGaming's discretion. I think most
> > non-DirectX code (an
tir, 30.09.2003 kl. 02.24 skrev Jonathan Wilson:
> From what I understand, if you download the WineX source tree, you get
> code under LGPL, code under X11 and code under APL (which is basicly a
> licence chosen to make sure that others cant just grab those bits and use them)
>
> Does anyone kn
man, 29.09.2003 kl. 16.33 skrev Dimitrie O. Paun:
> On September 29, 2003 04:57 am, Dmitry Timoshkov wrote:
> > I'm attaching a diff between your output and an output of
> > the test run under win2k (line numbers were stripped before
> > the diff).
>
> So it seems that InSendMessage() always retur
tir, 23.09.2003 kl. 13.11 skrev Mike Hearn:
> On Mon, 2003-09-22 at 19:11, Alexandre Julliard wrote:
> > Mike Hearn <[EMAIL PROTECTED]> writes:
> >
> > > Ensure the header files work with upcoming DCOM patches
> >
> > We finally have correct header dependencies now, please don't start
> > breakin
søn, 21.09.2003 kl. 10.30 skrev Dmitry Timoshkov:
> "Eric Pouech" <[EMAIL PROTECTED]> wrote:
>
> > S8: ReWind is not for TG. TG is not based on ReWind. ReWind serves as a
> > X11-cross platform between Wine and WineX.
>
> I do not want to start a flame war, but you just repeat what TG wants
> Re
søn, 21.09.2003 kl. 16.07 skrev Andreas Mohr:
> Wine DOES have to implement a DOS extender.
I think you're wrong. Wine doesn't have to implement a DOS extender,
it's much simpler and more useful to have Wine be able to run them
rather then implement them all. After all, DOS extenders don't have
st
søn, 21.09.2003 kl. 08.46 skrev Eric Pouech:
> > MZ are the first two bytes of the file, identifying it as an executable.
> > I'm not aware that they mean anything at all.
> IIRC, they were the initial of the author(s) of the file format
Mark Zbikowski. But that's just a theory, I haven't heard a
On Wed, 2003-09-10 at 22:10, Alexandre Julliard wrote:
> Ove Kaaven <[EMAIL PROTECTED]> writes:
>
> > See the problem?
> >
> > Hmm, now should I complain to Debian's glibc maintainers, or is this
> > Wine's problem?
>
> In a sense it's a W
On Thu, 2003-09-11 at 00:29, Kevin Atkinson wrote:
> I will repeat what I just said:
>
> Since it normal interface is VC++ RECOMPILING it under
> Winelib is NOT really an option as that will mean that existing plugins
> for Avisynth will no longer work without a recompile.
But that's also
1 - 100 of 106 matches
Mail list logo
