Dimitrie O. Paun wrote:
On August 30, 2003 12:52 pm, Jukka Heinonen wrote:
The reason why I'm posting lots of small patches is that I'm currently
working on a big RMCB fix which seems to still have some minor problems
What is this RMCB? Google wasn't all that helpful...
IIRC, this
Hi,
What about adding the comment in the code? :-)
Bye,
Christian
Message du 18/08/03 12:05 De : Dmitry Timoshkov <[EMAIL PROTECTED]>A : Dominik Strasser <[EMAIL PROTECTED]>Copie à : [EMAIL PROTECTED] Objet : Re: winevdm: can't exec Hello, Changelog: Windows ignores values of e_cparhdr and
Hi,
I recently configured Wine to use new fake Windows directories and
I forgot to copy the font files from Windows.
Nothing was reported and some apps displayed unreadable characters.
Is there a way to report an error when an app tries to used missing fonts ?
That would help users I think. :-)
Message du 08/07/03 12:45
De : Mike Hearn
A : [EMAIL PROTECTED]
Copie à :
Objet : MS OLE questions
Hi all,
Hi,
Thirdly, why does MSOLE use hidden windows for communication? I've come
across lots of gnashing of teeth in OLE/DCOM forums about this, people
wondering why their app (and
Hi,
This is about one month or so I'm experiencing problems with mailing lists.
Indeed, mail delivery is disabled randomly for some of them.
I have to turned on again the delivery by editing options of my account.
This is really annoying.
Is anyone experiencing the same kind of problems?
What's
Raphaël Junqueira wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi rok ;)
As I've mentioned, we'll need a function for loading chunks from dmusic
files. I tried to write one, and here's result; it's not very nice, but
it works (sort of).
At the time being, it only loads
Message du 17/06/03 02:30
De : Raphaël Junqueira [EMAIL PROTECTED]
A : [EMAIL PROTECTED]
Copie à : Christian Costa [EMAIL PROTECTED], Rok Mandeljc [EMAIL PROTECTED]
Objet : [DMUSIC07] more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Changelog:
- add IDirectMusicContainer
Raphaël Junqueira wrote:
Sorry for the delay Raphael, I was offline...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le Lundi 09 Juin 2003 21:32, Lionel Ulmer a écrit :
As your patch is a little malformed and conflicts with mine (a big one)
i send my patch merged with yours, can you look if all
Raphaël Junqueira wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Your're right, a blank line has been removed by mistake.Sorry for that.
Well, alexandre have already commited your patch without errors
so don't worry ;)
Well, as I write these lines, Alexandre has already applied my
A bit late, as usual ;-)
Because the world transformation introduced the W coordinate which
cannot be passed
to drawing functions. But well, this coordinate should be always be 1
after the world transformation so we can ommit it.
Well, you can pass the W coordinates using the 1/W trick, no ?
Hi,
Sorry, for a unknown reason my wine-devel delivery had been disabled.
I enabled it but I've just seen your posts in the archives...
Some comments on 'small' parts... I will have to commit the patch on
my tree
to try to understand the resulting code to understand it better [:-)]
+if (
Raphaël Junqueira wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le Samedi 25 Janvier 2003 15:07, Raphaël Junqueira a écrit :
Hi,
i'm trying to get warcraft3 displaying something and looking at log i
didn't understand why i can see anything (all rendering traces are ok).
But when i
Well, I think the easiest would be for you to send a cumulative patch over
mine as I think it's easier to track for Alexandre (and as I will do for
your Light 'merging' patch that I did not have time to comment before
committing due to vacations :-) ).
OK.
Hi all!
I've tried the Sacrifice demo and it complains about sound.dll.
Indeed it uses its own 32-bit sound.dll which lies in its directory.
Apparently the dll seems to conflict with our 16-bit windows sound.dll
I've joined a small log.
I tried to add a sound entry in the [DllOverrides] section
Dan Kegel wrote:
Christian Costa wrote:
All the static CRITICAL_SECTIONs in Wine DLLs have names.
The only unnamed ones are those that are initialized at runtime.
It is what I said! No? :-)
I guess I missed part of what you said, sorry.
To give these a name, we'd either have to convert
Dan Kegel wrote:
Christian Costa wrote:
Hmm. Seems to be the Wine DLL sources should try
to avoid stuff that doesn't compile under Windows.
That said, we could provide a header file that
defined SET_CRITICAL_SECTION_NAME in Windows, and
made it do nothing.
If CRITICAL_SECTION_INIT compiles
Dan Kegel wrote:
Christian Costa wrote:
In that case our InitializeCriticalSection macro would have one
more parameter (the name) than the real function.
Nope. It wouldn't. We would construct the name from __FILE__ and
__LINE__.
So you suggest to not set a name ?
What happened
Francois Gouget wrote:
On Wed, 22 Jan 2003, Christian Costa wrote:
[...]
err:ntdll:RtlpWaitForCriticalSection section 0x70460350 ? wait timed
out, retrying (60 sec) tid=08436988
[...]
I think, It would be cool to have all locks named and thus make
debugging and bug report easier.
It's
Dan Kegel wrote:
Christian Costa wrote:
I think, It would be cool to have all locks named and thus make
debugging and bug report easier.
It's not a hard task but names must be meaningfull. :-)
I guess you mean all Wine locks should be named
Yes! :-)
...
Naming the Wine locks would
Rein Klazes wrote:
Hi,
Girotel Offline creates 78 palette objects using 1044 bytes each. That
doesn't fit on the 16bit gdi heap. It is not a leak: each object is
freed when the program closes. Using NtObjects (www.smidgeonsoft.com)
shows that under NT2K the program creates the same number of
When I get no graphics, it seems that GDI heap
overflows aswell.
hmmm, where ? maybe in palettes things no ?
Yes the overflow entries are palette ones, but
it also says something about missing WM_PAINT.
Like you, I got no graphics in SS2 when GDI problems occured.
The Rein's
Jukka Heinonen wrote:
Christian Costa wrote:
Andreas Mohr wrote:
So until there is further information about how to do it properly,
I'll just remove the vga_refresh reset in the VGA_IsTimerRunning() case,
and of course this makes Turbo Pascal 6 usable (although screen update is
a bit slower
Andreas Mohr wrote:
Hi all,
please disregard my previous patch.
I discovered that
case 0x3da:
/*
* Read from this register resets register 0x3c0 address flip-flop.
*/
vga_address_3c0 = TRUE;
/* since we don't (yet?) serve DOS VM
Lionel Ulmer wrote:
Hi all,
In 'old' D3D games, a lot of textures are created paletted... And each
of these texture has its own DDraw palette object. And thus each has
some GDI memory allocated.
This means that after some time, we run out of GDI Heap space due to
all these palettes created
Lionel Ulmer wrote:
Hi all,
This patch should not be dependant of any others... But to prevent line
number errors, better to commit it after the 5 - 9 series (yeah, the
attachements are numbered to ease tracking :-) ).
Changelog:
- start of support for device locking / unlocking via
Lionel Ulmer wrote:
This patch breaks the TWIST demo that was working fine.
I think the changes in d3ddevice_create are responsible of that.
Strange, it works fine here.. A bit slow when statistics are displayed (due
to the locking of the D3DEVICE surface and thus needing a slow GL call like
Ove Kaaven wrote:
On Thu, 28 Nov 2002, Christian Costa wrote:
Does ICOM_USE_INTERFACE_ATTRIBUTE prevent g++ to add the 8 bytes offset?
Yeah.
From which g++ version this can be used?
Not sure, but I'm pretty sure it's been supported in Debian's 2.95.4 stuff
(which grabbed lots of stuff
Ove Kaaven wrote:
On Sat, 2 Nov 2002, Matthew Bloch wrote:
So with the ICOM_MSVTABLE_COMPAT flag set I get the off-by-two calling error
from within Winelib when it's trying to invoke a COM function. When it's not
set I get the same bug occurring in my program when it tries to do the same.
Lionel Ulmer wrote:
Well, the problem seems to come from an incompatibility between g++ and the
way Wine defines COM objects. From my experiences, the g++ vtable starts at
offset 8 whereas Wine defines COM object vtables as starting at offset 0 (ie
vtable[0] == first method whereas for g++
John K. Hohm wrote:
Well, I was hoping some of the COM experts would comment on that. If
I understand it right you are avoiding writing some thunking routines
for older interfaces, at the cost of an extra pointer access in every
function. I'm not convinced it's a good trade-off, but I'd like to
Hi all,
I've sent a patch for ddraw COM management, I did not have any comments
and the patch has been rejected.
Could someone tell me if something is wrong or lacking?
Christian.
PS: I've joined a small doc that explains how to use objects with
multiple interfaces. This docs is based on what
Christian Costa wrote:
So :
1) it is a bug in the game (and it works fine in Windows because,
miraculously, the three others words of the 'fake' DDSCAPS2
structure
are set to '0' or because Windows only checks with 'dwCaps' and not
with all 'dwCaps' fields).
2) somehow
So :
1) it is a bug in the game (and it works fine in Windows because,
miraculously, the three others words of the 'fake' DDSCAPS2 structure
are set to '0' or because Windows only checks with 'dwCaps' and not
with all 'dwCaps' fields).
2) somehow the docs are wrong and it should
Ann and Jason Edmeades wrote:
Changelog:
o Various fixes, typos corrected and clarifying trace points
Note I am quickly reaching the end of my ability in this area - This brings
the wine tree up to date with all my changes, so some help from anyone would
be appreciated. There are some 'simple'
admiral coeyman wrote:
Uwe Bonnes,
Alexandre submitted something with regard to 16 bit yesterday
(wine/dlls/version info.c). Remove this and if that doesn't help remove all
other yesterdays patches step by step.
This problem, 'invalid exe file,' is not that new. I've been having it for
Hi winers!
The command line -winver option has been removed.
I found that this option was quite convenient because :
1) it can be used easily in shortcut (in KDE for example)
2) when you don't know the windows version an app
runs on, it is easier to test until you match the right one.
Is there
I don't know it if is possible, but if that is true,
why not just emulate int21h calls when DOS3CALL is
called when we are running a win16 app, and the rest
of the time, leave everything be?
IIRC, int21h is based upon DOS3CALL except for some few parts which are
only implemented in int 21h.
It seems that the app's windows procedure does not expect a
WM_QUERYNEWPALETTE message.
Damn, I faintly remember that I've also had a problem with the
WM_QUERYNEWPALETTE ages ago (about two years ago).
Commenting it out made it go away.
Sounds like we might want to investigate
Hi,
Many DOS apps needs a lot of base memory even if EMS or XMS memory are used.
The first 64K of memory being lock to catch null pointer, the DOS memory
must start
at 0x1 as you can see in the code below (msdos/dosmem.c) :
Andreas Mohr a écrit :
On Sat, May 11, 2002 at 01:51:05PM -0700, Dustin Navea wrote:
which sound cards is this meant for? i have a live
platinum 5.1, is it to be used by people who _do_ or
who _dont_ have sb cards? i must be missing the
point, but what is the need for sb emulation?
Eric Pouech a écrit :
Christian COSTA a écrit :
Changelog :
dlls/winedos/vga.c : VGA_ioport_in
Fake the occurence of the vertical refresh when no graphic mode
has been set
Christian COSTA [EMAIL PROTECTED]
avec le patch ca serait mieux ;-)
A+
Ah ben
allows module handle equal to 0 which refer to the current module
Christian COSTA [EMAIL PROTECTED]
Index: tooltips.c
===
RCS file: /home/wine/wine/dlls/comctl32/tooltips.c,v
retrieving revision 1.42
diff -u -r1.42 tooltips.c
42 matches
Mail list logo
