wine-devel

wine-devel@winehq.org

4 participants
84472 discussions

How is Win/Dos syscalls implemented in Wine?
by Peter Andersson 27 Oct '02

27 Oct '02

Hello! Perhaps someone can give me a good answer to this question. Please give me a direct answer, I have allready been trouh the wine FAQ:s , docs, code, etc. I know DOS syscalls is made using interupts (int instruction) but, is Windows/NT syscalls made the same way. How does wine stop these instructions from reaching the unix kernel?

5 22

License query
by Matthew Bloch 27 Oct '02

27 Oct '02

I'm porting a closed-source game to Linux, and as a stop-gap I'd like to get a version out using WINE until I can rewrite the Direct(Sound|Draw|3D) backends with SDL. After reading this post: http://lists.debian.org/debian-devel/2002/debian-devel-200205/msg02823.html and then downloading the source from the winehq.com cvs, I'm confused as to my options. The LICENSE file implies that the ddraw DLL is transgaming's IP but the files themselves have LGPL declarations at the top. In short, am I within my rights to release a statically linked binary which uses the core WINE source code, providing I comply with the other terms of the LGPL? I notice some files have Transgaming's name on them, but appear to be LGPL. I think I'm within my rights, but not sure: the post above gives me most of the information that explains this state of affairs, but not everything. Any further pointers on WINE licensing history would be appreciated. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

2 2

Re: Segmentation Fault
by Kye Lewis 27 Oct '02

27 Oct '02

I don't know if this will help my Segmentation Fault at all, but when runing winedbg c:\\windows\\pbrush.exe, the Debugger actually waits for a command from me. If i take a step, it says: Single Stepping until exit from function, which has no line number information Stopped on breakpoint 1 at 0x0040100c (pbrush.exe.Entrypoint in c:\windows\pbrush.exe If i then step again Invalid address for breakpoint 0, disabling it ..... breakpoint 1 ..... ..... breakpoint 2 ..... Process of pid=0a24dbf0 has terminated a very odd thing happens if i run, and then step: another window pops up (gdb) and I get wine_dbg_cmd: Exception c00000005 in the Wine Debugger the gdb window says 0x402e2b41 in nanosleep () from /lib/i686/libc.so.6 and stepping in that window steps me through function nanosleep (?!?!?!) it would seem that it starts to debug wine itself! unfortunately, this window doesn't allow copy and paste, so i'll have to type it out for you (it may be a little incorrect): __errno_location () at errno.c:48 48 return wine_errno_location(); (gdb) step thread_errno_location () at ../../include/winnt.h:1717 1717 __asm__(".byte 0x64\n\tmov1 (0x18),%0" : "=r" (teb)); (gdb) step Program recieved signal SIGSEGV, Segmentation fault thread_errno_location () at ../../include/winnt.h:1717 1717 __asm__(".byte 0x64\n\tmov1 (0x18),%0" : "=r" (teb)); (gdb) step Program recieved signal SIGCONT, Continued 0x40305134 in read () from /lib/i686/lib.so.6 etc... etc... etc... and it goes through a whole heck of code... The only thing that comes up in the console is Can't attach process 8072d90: error 5 Thanks, Kye Lewis kyethespy(a)liquid2k.com

1 0

Re: dlls/user: w[v]snprintf[A|W] fixes
by David Laight 27 Oct '02

27 Oct '02

> > > Changelog: > > * dlls/user/wsprintf.c Jaco Greeff <jaco(a)puxedo.org> > > - Changed the wsprintf[A|W] and wvsprintf[A|W] functions to > > determine the size of the destination buffer before writing > > to it. Previously the size was hardcoded to 1024 bytes. > > The size is supposed to be hardcoded to 1024, that's how wsprintf > works. You can't make it dynamic since the buffer is allocated by the > application. Seems to me (from info in a later post) that M$ wsprintf uses an internal temporary buffer that has a size of 1024 - thus resticting the user to a buffer size of 1024, The actual size of the user buffer cannot be determined - hence the common 'buffer overflow' issues with sprintf. The C standard now includes snprintf() where the application passes in the length of the target buffer. I guess M$ might follow :-) Some systems also have an asprintf() routine which will malloc() a buffer that the caller must free(). David -- David Laight: david(a)l8s.co.uk

1 0

Segmentation Fault
by Kye Lewis 27 Oct '02

27 Oct '02

Hi, Not really sure if this is the right place to post this, but as i'm signed up to it; My version of wine has suddenly started Seg Faulting on startup. The last thing I tried with wine was netmeeting. This is with cvs version from 26th October at about 2:00 Australian Eastern Standard Time ( not sure what that is GMT - it was about 5 hours before posting this message ) Any help would be appreciated. Thanks, Kye Lewis kyethespy(a)liquid2k.com

3 5

Re: dlls/user: w[v]snprintf[A|W] fixes
by Jaco Greeff 27 Oct '02

27 Oct '02

On 26 Oct 2002 14:57:53 -0700, Alexandre Julliard <julliard(a)winehq.com> wrote : > The size is supposed to be hardcoded to 1024, that's how wsprintf > works. You can't make it dynamic since the buffer is allocated by the > application. >From MSDN: "Pointer to a buffer to receive the formatted output. The maximum size of the buffer is 1024 bytes." The question I need to ask myself now is what function reference did I compare this one to when I searched there?

1 0

[RFC] creating Wine's own 'assert' variant
by Lionel Ulmer 26 Oct '02

26 Oct '02

Hi all, Currently, Wine's code is full of 'asserts'. The problem I have with that if that when such an assert is reached, only the thread being asserted is aborted, but Wine is not 'shut down' properly. Moreover, if I want the debugger to be launched on assert, I would need first to start the application with the debugger and add a breakpoint on some libc internal function. So, don't you think it would be better to have our own 'wine_assert' macro / function that could be configurable (ie abort or start the debugger) and that would also shut-down Wine properly ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

4 5

Re: interrupts in when in NT version
by John K. Hohm 26 Oct '02

26 Oct '02

> Tough all safedisc programs depend on this, I have decided not to make an > official patch. The reason is that additional info is needed for a proper > fix. Safedisc depends on that EXCEPTION_ACCESS_VIOLATION is returned on an > int 0x01 call. But it should be checked what exceptions are raised on > different windows versions when int 0x01 is called. And maybe the same should > be done with other interrupts. > It would be good if somebody could make that test program. Else I will keep > the non proper fix. You may think me a rube, but I just made a test program that calls an arbitrary interrupt and prints the exception information. I don't set up any registers, so perhaps it generates an exception when it ought not in some cases, but anyone else is free to improve it. Source and a VC6-compiled MSVCRT-using version, along with results for all 255 interrupts on Windows XP Professional, is here: http://petra.trnty.edu/~jhohm/intexcep.zip

2 1

Re: dlls/user: w[v]snprintf[A|W] fixes
by Alexandre Julliard 26 Oct '02

26 Oct '02

"Jaco Greeff" <jaco(a)puxedo.org> writes: > Changelog: > * dlls/user/wsprintf.c Jaco Greeff <jaco(a)puxedo.org> > - Changed the wsprintf[A|W] and wvsprintf[A|W] functions to > determine the size of the destination buffer before writing > to it. Previously the size was hardcoded to 1024 bytes. The size is supposed to be hardcoded to 1024, that's how wsprintf works. You can't make it dynamic since the buffer is allocated by the application. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: msvcrt: printf family (Bug #321)
by Alexandre Julliard 26 Oct '02

26 Oct '02

"Jaco Greeff" <jaco(a)puxedo.org> writes: > * dlls/msvcrt/file.c Jaco Greeff <jaco(a)puxedo.org> > - Allow for the processing of %S and %C format specifiers as per > bug #321 > - Code duplicated/shared between dlls/user/wsprintf.c, > dlls/shlwapi/wsprintf.c and now dlls/msvcrt/file.c That's not correct. wsprintf is not a normal printf, it lacks a lot of features so it's not good enough for msvcrt. We either need a full printf implementation in msvcrt, or we need to patch the %S/%C in the format string and call the libc printf. -- Alexandre Julliard julliard(a)winehq.com

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel