e compiled with masm32 and including the pdb file on request.
Yes, please send me exe and pdb files ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
?
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
are then invalid?
Could you do a dump of the PE header, and compare the section
addresses with the values returned by FindResource and LoadResource
(corrected for the module base)?
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
;
Sparc64 is another issue completely (and
probably much more difficult) ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
Ove Kaaven [EMAIL PROTECTED] wrote:
Just thought I'd mention that there seems to be an x86emu (using some
X11-compatible license of course) included with XFree86 3.9.x... it's used
to softboot video BIOSes on machines with cards that aren't automatically
initialized (like with lots of
to the docs, that would even be correct; XGetImage
is only supposed to set the 'depth' member :-/
This means that you probably should replace the XGetImage calls
with XCreateImage followed by XGetSubImage (of the whole image) ...
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen
"Francois Boisvert" [EMAIL PROTECTED] wrote:
This works with 16 bpp or more bitmaps ... but the color masks are still not
right for 1,4,8 bpp bitmaps, they are all the same as 16bpp ((red)0xf800
(green)0x07e0 (blue)0x001f)
Well, that would be because with = 8 bpp, there are no color masks;
Andreas Mohr [EMAIL PROTECTED] wrote:
I seem to remember that it's possible to create combined EXE/ELF
libraries capable of execution on both Linux *and* Windows.
Well, considering that every Windows EXE must start with the 'MZ'
signature, while every ELF executable must start with 'ELF',
[EMAIL PROTECTED] wrote:
[ Sorry for the late reply, I was off-line for two weeks ... ]
Anybody have handy an op-code/postbyte map for x86? I wouldn't mind if
it included segment prefixes too :-). I had an illegal copy of the
original IBM PC spec at one time, and I could sort of
be moved out of USER into
KERNEL as well.
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
table and thus execute arbitrary code at ring-0.
Some games appear to use this as copy protection (or anti-debugger)
mechanism :-/ ]
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
assume to be most apps ...) under pthreads.
At least, I guess it's worth a try ...
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
can modify the Wine handler, the app-provided handlers must work
as well, so we'd have to find a way that allows signal handlers that don't
properly return ...
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
;-)
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
,
and ignores the hash table, we can just ignore the reference entries ... ]
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
should't
modify anything ...One option might be to map a dummy page at
some point near the top, say at 3GB - 1MB; this would serve as a
'stop' preventing further stack growth.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
could simply
use the intended interface and call setrlimit(RLIMIT_STACK, ...) to
limit the automatic stack growth to a reasonable size. ;-)
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
Alexandre Julliard wrote:
Ulrich Weigand [EMAIL PROTECTED] writes:
But instead of the hack of using a dummy page, I guess we could simply
use the intended interface and call setrlimit(RLIMIT_STACK, ...) to
limit the automatic stack growth to a reasonable size. ;-)
At least under
with the (reserved) stack area,
a workaround is to set 'ulimit -s 512' or so before running Wine ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
be
simple to fix, however. ]
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
= OFFSETOF(pTask-teb-cur_stack) + sizeof(STACK16FRAME);
pinstance-stackbottom = pinstance-stackmin;
(alternatively: SP_reg(context) + 4, but this should always be the
same value ... )
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
%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
*above* the arguments after the stack permutation you did above ;-)
What about this instead of the last three lines:
print "\taddl $" #argsize ", %esp\n";
print "\tret\n";
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
-trivial routine calls one of these stubs,
it will matter ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
rintf( outfile, "\tdecl CALL32_RecursionCount\n" );
-
-fprintf( outfile, "\tmovl %%ebp,%%esp\n" );
-fprintf( outfile, "\tpopl %%ebp\n" );
-fprintf( outfile, "\tret\n" );
-
-/* Data */
-
-fprintf( outfile, "\t.data\n" );
-fprintf( outfile, "CALL32_Original32_esp:\t.long 0\n" );
-fprintf( outfile, "CALL32_RecursionCount:\t.long 0\n" );
-fprintf( outfile, "\t.text\n" );
-}
-
/***
* BuildCallFrom32Regs
@@ -3268,10 +3173,6 @@
fprintf( outfile, "Code_Start:\n" );
}
#endif
-
-/* Build the 32-bit large stack callback */
-
-BuildCallTo32LargeStack( outfile );
/* Build the register callback function */
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
on the particular error.
This should work on the large stack as well as otherwise.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
this,
but this hasn't been integrated into the Wine built process yet ...)
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
;-)
I've submitted the patch to wine-patches now; that version does terminate
the process for now if any exception reaches the stack switch boundary.
If you really need a different behaviour, feel free to change it ... :-)
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
data fields. Unfortunately,
on Sparc .word will create a data field the size of a standard machine word,
i.e. 32 bits. If you use .short (or .half or .hword) you're guaranteed to
get 16 bits on all platforms (at least when using GNU as).
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
an example
of an app (including PDBs) that shows this problem, I'd like to have a look ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
the X11DRV_CritSection, you'll have to replace it
with appropriate mechanisms in these cases.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
on
performance ...
Another way might be to change the arg_size parameter from a
pure input parameter to in/out, and update this with the
actual argument size (as popped by the called routine).
I'll have to think about this ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
ndif
-fprintf( outfile, "\tmovw %%bx,%%ss\n" );
+fprintf( outfile, "\tmovw %%di,%%ss\n" );
fprintf( outfile, "\t.byte 0x64\n\tmovl (%d),%%esp\n", STACKOFFSET );
fprintf( outfile, "\t.byte 0x64\n\tpopl (%d)\n", STACKOFFSET );
diff -ur win
that Ulrich Weigand has gotten WineLib apps up and running on SPARC.
Indeed. The main Wine tree doesn't compile out of the box, however.
There's still a few problems, mostly related to alignment issues,
that I haven't yet fixed in a clean way.
On machines without alignment constraints (even if big-endian
doesn't change),
even though in fact the value of strlenW(lpBuffer) depends on the
*contents* of lpBuffer.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
into a shared heap; I can guess that Alexandre won't like
this however ;-)
For GDI, we'd have in addtion to:
- implement a proper DISPLAY driver to actually see any output
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
to take care that we don't
overlook system mappings in this case ...) There is also a not
quite trivial problem of how to avoid race conditions here ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
mappings at this address.
Yes. Except if we check ourselves in advance ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
the main problem here ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
there) or did it return
zero (in which case something is mapped there).
Ah, sorry. You're right, of course.
Using mincore should be somewhat more portable than digging around /proc.
Yes. The /proc format changed even across Solaris versions :-/
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL
to completely freeze all threads first, because you never
know if some libc function is not going to change mappings.
Yes, that's the problem. :-/
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
e possible to compile
Winelib ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
, but Bertho did convince me that
native-endian is better, after all ;-) ]
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
? It's a bit hard to see what you really
changed and what is whitespace diff only ... ]
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
to be cleaned up.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
diff -ur wine-cvs/tools/wrc/genres.c wine-uw/tools/wrc/genres.c
--- wine-cvs/tools/wrc/genres.c Sun Dec 10 15:45:54 2000
+++ wine-uw/tools/wrc/genres.c Sun Dec 17 18:11:32 2000
@@ -65,7 +65,7 @@
{
if(res
, but only
on Sparc; on Intel I only ran configure and was satisfied with the output
'yes'; unfortunately I didn't do a complete rebuild ...
The import bug appears to have resulted from a merge conflict between your
delayed import patch and my Sparc patch :-(
Bye,
Ulrich
--
Dr. Ulrich Weigand
er compile problems with
the current version of winsock.h ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
Alexandre Julliard wrote:
Ulrich Weigand [EMAIL PROTECTED] writes:
Well, the IMO most important configure checks are CPU architecture
and OS specific (e.g. location of system headers / libraries and the
like). While there are of course also compiler / toolchain dependent
checks, those
Francois Gouget wrote:
On Fri, 29 Dec 2000, Ulrich Weigand wrote:
[...]
It simply means that we will always have problems when we try to
use either OS-dependent or CPU specific features in Windows headers.
See e.g. my other mail on the winsock.h problems ...
It seems I missed your
Eric Pouech wrote:
Ulrich Weigand wrote:
I've also modified the i386 implementation a bit to make it
more easily portable; specifically, I've moved all references
to the delay_imports symbol into the C routine to avoid having
to implement PIC references in assembly ... (on i386 it just
ERNEL32_99.
No. Unfortunately, I don't know how the RunOnce check works ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
Bits bits)
-{
-continue;
-}
+LeaveCriticalSection( queue-cSection );
TRACE_(msg)("%04x) wakeMask is %04x, waiting\n", queue-self, queue-wakeMask);
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
Alexandre Julliard wrote:
Ulrich Weigand [EMAIL PROTECTED] writes:
But in this case, I think Ove is basically right: you have only one
race between QUEUE_SetWakeBit and QUEUE_WaitBits.
Well, yes of course, the race is between testing and setting the bits,
but the race not only
program for test purposes. It's completely outdated now,
and winedbg is standalone now anyway, so I guess it could be removed.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
. Ulrich Weigand
[EMAIL PROTECTED]
I had to patch these paths into the Makefiles "manually" (sed or Perl,
of course). "./configure" should do this in some way, or your
"Makefile.in"s.
Hmmm. Our build process is a bit non-standard.
I agree, this should probably be fixed ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
ate header ...
What do you think?
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
, and delete all directories removed
from the repository, respectively. ]
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
-specific patches.
[ B.t.w. I'm now working for IBM on the Linux for S/390 port.
That's why I am quite familiar with the architecture ... ;-) ]
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
understand GetFastQueue16 to fail
would be if the application doesn't load the USER subsystem, so that
the callout from KERNEL will not be present. Could you provide a
trace with +relay and +loaddll to show whether and when USER is loaded?
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
ye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
-specifc tools (and apparently even
there are version problems ...). :-(
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
, the gcc'ism will annoy Patrik ;-/)
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
2.9.5.0.24 and glibc 2.1.3
(all as modified for the SuSE distro).
Could you send me the libwinspool.drv.so file that objcopy
is choking on? I'd like to look whether there's something
strange with that.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
ub symbols */
objcopy -R .rel.stab $1
IMPLIST=`nm $1 | grep __wine_dllimport | sed -e 's/^.*__wine_dllimport_[^_]*_/-N /'`
if [ "$IMPLIST" != "" ]
then
echo $IMPLIST | xargs objcopy $1
fi
shift
done
exit 0
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
* by a 32-bit app,
the Get/PeekMessage call drops the message ...)
You get DebugOutput messages like
"PostMessage: ignoring posted message with pointer"
or
"GetMessage: ignoring retrieved message with pointer"
when this happens.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
which is nearly simple enough to be inlined in the Make.rules again :-/
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
). Currently, it 'restores' the keyboard config
to a random value (hmm, probably always zero, but anyway ...) ;-)
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
Josh DuBois wrote:
Well, on the ppc it seems that CRITICAL_SECTIONS which are initialized (they
get set to CRITICAL_SECTION_INIT a lot) fairly reliably get put on 2-byte
boundaries. I am not certain why this is the case.
But this is the real question ;-) As I said, the *default*
(processes in state D)
show *before* you press ^C or only afterwards?
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
ack[4*i
++ 3] );
+}
}
int main( int argc, char *argv[] )
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
only Wine would
trigger that bug ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
bug).
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
clobber(int *param)
{
(*param)++;
}
void compare(int orig_param, int param)
{
if (orig_param != param)
printf( "PASS\n" );
else
printf( "FAIL\n" );
}
void use(int data)
{
}
int main(void)
{
test(0, 0);
}
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
. Ulrich Weigand
[EMAIL PROTECTED]
run 'dump pid'. The result
is suitable for piping through 'ksymoops' for symbol lookup.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
gzip compressed data, deflated, last modified: Mon Mar 26 23:48:50 2001, os: Unix
, a workaround could look like this: first, try mapping
with MAP_FIXED; if this fails, repeat without.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
therefore also
sometimes change the size of a structure ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
XPASS numbers you might look at the cases in question
and decide whether you want to remove the 'expected to fail' flag.
This system works quite well in my experience with gcc, maybe something
like this could be implemented for Wine as well ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL
* the program does this nonsense).
So you'll fail immediately afterwards due to privilege
violations as the app does whatever it wants to do in ring 0 ...
Of course, you could add virtualization for all the ring 0 stuff,
but this is quite open-ended :-(
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL
, by this or any of a couple of other methods ...
Did anybody claim Win9x had kernel/user space separation? ;-)
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
are you
using? Did you build it yourself or is it the one that came
with your distro (which one?)? What is the output of
gcc -v
rpm -qf `which gcc`
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
Alexandre Julliard wrote:
That's most likely the usual gcc bug with local WINAPI function
pointers.
Doh, I'd completely forgotten that one :-/
Thanks,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
in the 16-bit user (32-bit user32 is just a wrapper
layer), so this is probably a show-stopper.
(Maybe it would be possible to run only a single task
with native user. But I haven't tried in a long time,
and it's probably broken for some reason or other ...)
Bye,
Ulrich
--
Dr. Ulrich Weigand
we *want* to be more
like Win NT for stability reasons ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
Alexandre removed
the Callout to user there ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
should count more than minor issues like whether
native user.exe runs (which might or might not run due to a whole
bunch of other issues, and is not representative of *any* other
workload ...).
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
books and websites)?
Not that I'm aware of; there of course the Pietrek books and others,
and there are various websites with bits and pieces of undocumented
Windows features. I don't think there's a comprehensive list, though.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
to post your presentation here?
Didn't you want to put those up on your website? It's probably
a bit large for the list ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
is called ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
) should sometimes
*increase* some alignment requirement -- but it never does.
Under what circumstances do you think it should?
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
have to use -mpreferred-stack-boundary=3 instead of
-mpreferred-stack-boundary=2 as well.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
Dimitry Timoshkov wrote:
On November 6, 2002 11:47 am, Andreas Mohr wrote:
If anyone needs that, I guess I could easily dig up the mail from Ulrich
Weigand that explained the miracles accomplished at that time in great
detail. (it was not much more other than pure luck that we were able
On November 6, 2002 04:58 pm, Ulrich Weigand wrote:
Dimitry Timoshkov wrote:
^
Where did you come up with this? I wrote it... :)
Argh. I should configure my mailer correctly so that
I don't need to hand-edit this :-/ Sorry ...
--
Dr. Ulrich Weigand
[EMAIL
guaranteed that every
access to errno calls it. Thus, if you overwrite the implementation
of __errno_location, you will only catch *some* errno accesses,
not all of them ...
Bye,
Ulrich (who has just implemented TLS for s390 ;-/)
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
one of the two TLS GDT
entries for its %fs selector, which means that Wine processes might not
actually need to allocate a LDT (for 32-bit programs only, of course) ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
with modify_ldt, and Wine would do the same, without any
coordination between the two. This is no longer a problem as the new
ntpl thread library does not use the LDT at all anymore.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
to one TID, just like the
old Linux kill would send a signal to a specific thread. I think using
those we could carry over our old Linux-specific hacks one to one, and
it still should work even if our threads are glibc 2.3.x pthreads.
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
1 - 100 of 105 matches
Mail list logo
