B. Obtain commitments for work
I would like to start having people indicate
whether or not they are working or will be working on a
task.
For our part, CodeWeavers is going to volunteer to do the
jobs no
one else wants (like QA and
Hello,
Over the past few months I have been working with wine and winelib in my spare
time. Eventually I hope to port a Win32 app to linux using winelib. The next
major hurdle in the port is MFC. I see two paths and I am seeking advice and
help.
1. Compile MFC. Several years ago we (Lumin
[snip]
+print '"\tpopl %ecx\n"' . " \\\n";=0A=
+print '"\tsubl $" #argsize ", %esp\n"' . " \\\n";=0A=
+print '"\tjmp *%ecx\n"' . " \\\n";=0A=
This appears to be broken; you need to *add* the argsize instead
of subtracting it, and furthermore the return address lies now
Patrik Stridvall [EMAIL PROTECTED] writes:
Well there are two cases here
(1) The application really behaves this way and this
works on Windows.
(2) A previous API that failed cause directly or
indirectly a NULL value being passed.
The (1) case should obviously be fixed, case (2)
Just adds a useful error message when we have to rebuild the cached
metrics. It attempts to print out the name of teh last successfully read
font.
--- /devel/corelwineVirgin/corelwine/graphics/x11drv/xfont.cMon May 15
10:48:04 2000
+++ xfont.c Tue May 16 16:43:23 2000
@@
So it is an issue between teoretical correctness
vs practical easy of debugging. Since the debugging
problem can be solved by other means, it doesn't weight
very much compared to correctness IMHO.
I disagree. We should try to catch problems as soon as possible, not
hide them and hope
Patrik Stridvall [EMAIL PROTECTED] writes:
NULL values are not garbage IHMO, there are legitime uses for depending
on NULL values returning failure because
1. Checking for NULL is a waste of time since the API already does it.
2. An explict check "pollutes" the code and is potentially less
On Fri, May 19, 2000 at 03:55:33PM -0700, Alexandre Julliard wrote:
So yes, we may want to have more checks in 1.0; but we must not start
adding them before the rest of the code has been debugged properly.
--
Alexandre Julliard
[EMAIL PROTECTED]
This is exactly my opinion expressed in a
Patrik Stridvall psÉleissner.se writes:
NULL values are not garbage IHMO, there are legitime uses
for depending
on NULL values returning failure because
1. Checking for NULL is a waste of time since the API
already does it.
2. An explict check "pollutes" the code and is
What about this instead of the last three lines:
print "\taddl $" #argsize ", %esp\n";
print "\tret\n";
I did that and it does not solve the problem : it crashes at the same
GL call (glGetString) but this time at address 0x and not
0x1F00 as before.
How can I help
"Wilbur N. Dale" wrote:
[snip]
1. Compile MFC. Several years ago we (Lumin Software) tried to compile MFC.
The attempt failed and we found another way to do what we wanted. MS
documentation states that compiling MFC was deliberately made difficult.
Considering my experience with stuff they
11 matches
Mail list logo
