Re: [RFC] pthread emulation on FreeBSD (and Linux)

[Ove Kaaven]

On Sun, 24 Nov 2002, Patrik Stridvall wrote:

> Anyway, to answer the first obvious question:
> Why didn't you just put it in scheduler/pthread.c?
> 
> Well, the thing is it didn't work. It still generates the
> same link errors. However that is not very suprising since
> the pthread_ implementation is in ntdll.dll which is
> not linked with during the "-Bsymbolic -z defs" step.

scheduler/pthread.c should be linked into libwine, which is linked into
everything, at least this is the idea and was the case last time I
checked.

> This begs the question:
> Does the Linux implementation of pthread really work anyway?

Works in WineX (though we needed some more hacks in it to make it interact
well with the nvidia opengl drivers), and it'd surprise me if it doesn't
still work in Wine, as the OpenGL deployed by most linux distros wouldn't
work *at all* under Wine if it didn't, and people currently seem to be
working on Wine as if it did work.

> The thing is Linux (or rather the GNU C library) always links
> in pthread suppport. However since some of the symbols are
> on purpose defined as weak they can be overriden. This is
> what scheduler/pthread.c does on Linux. Or rather tryies to
> do. I'm not really sure if works any longer.

It's not the weak symbols that allow overrides, weak symbols only allow
the pthreads library to *not* be linked in (so your statement about always
linking it in is untrue). Weak symbols work such that until the library is
linked in, they are just null pointers, and glibc only calls them if they
aren't null. Overriding symbols can only be done by linking things in the
right order (link the wine overrides before the real pthread lib), and
since libwine is loaded before opengl-linked-against-pthreads, the libwine
pthread implementation is used instead of the pthreads linked in later,
and this don't need a special kind of symbol to work.

> Note that if I apply the attach patch and compiles on
> Linux it seems to work with "make test" as well.
> 
> Anyway be pthreads on Linux working properly as it may, the big
> question is how do we support pthreads on both Linux and FreeBSD.

I'd say link -lwine in before -lc_r, but then I don't know much about
FreeBSD.

> FreeBSD since it AFAICS have no default overridable implementation
> seems to require that we have some sort of wine_pthread library to
> implement pthreads from scratch like outlined in the attached patch.

The scheduler/pthread.c is basically the same thing, since it needs to
override every single pthread symbol used by apps, otherwise the override
fails (or if it would be successful, it would still be incomplete).

Stupid question: the reason for the missing symbols on FreeBSD isn't
because of the #ifdef __GLIBC__ in scheduler/pthread.c, is it?

Re: Screwed up textures in OpenGL apps

[Chris Thielen]

On Sun, 2002-11-24 at 19:08, David D. Hagood wrote:
> Dan Kegel wrote:
> > Please verify that booting with just one CPU active
> > doesn't fix the problem. e.g. at lilo prompt, do something like
> >   linux nosmp
> > It could be that Wine doesn't support SMP yet.
> > 
> > - Dan
> > 
> > 
> 
> First thing I tried, and with no change, so I don't think it's a SMP 
> issue. Furthermore, my other apps under Wine work fine, only the OpenGL 
> ones die.

I do believe there are OpenGL regressions. I have a single processor
system with a working OpenGL, yet OGL games under Wine have texture
issues they did not have previously. I'm not entirely sure it's wine, as
I've updated my Mesa/X/modules many times.

-- 
Chris Thielen <[EMAIL PROTECTED]>

Off Topic: Off-list help needed with SGML Tools please

[Dustin Navea]

For some reason I cant get SGMLTools to compile properly, everything but
jade compiles but when it goes to compile that, I get a bunch of
errors.  I could leave out jade but thats what Im needing to compile to
build sgml docs...  I have tested this with Slackware 8.1 default GCC
and the prepackaged GCC 3.2.1 Source from Slackware-current and neither
would compile it.  I also tested that its not just Slackware's GCC... 
Redhat 8.0 would not compile it either with GCC 3.2.1...  So if anyone
can help me it would be most appreciated..  I still have a couple of
other things to try (installing the latest slackware binutils, and
trying out CVS sgmltools, if i can ever connect to the cvs server) :/


-Dustin

An opengl regression

[Duane Clark]

The patch for dynamic loading of opengl,
http://www.winehq.com/hypermail/wine-cvs/2002/11/0151.html

has caused a (apparently minor) regression in the program earthquake
http://www.navagent.com/products/earthquake/

That is a small app (250K download) with a spinning globe that shows 
current earthquakes; actually a pretty cool little app. The regression 
is that now when the oceans are turned on (via the settings dialog), the 
land gets flooded.

Re: Screwed up textures in OpenGL apps

[David D. Hagood]

Dan Kegel wrote:

Please verify that booting with just one CPU active
doesn't fix the problem. e.g. at lilo prompt, do something like
  linux nosmp
It could be that Wine doesn't support SMP yet.

- Dan




First thing I tried, and with no change, so I don't think it's a SMP 
issue. Furthermore, my other apps under Wine work fine, only the OpenGL 
ones die.

Re: _ fstati64

[Stefan Leichter]

Am Sonntag 24 November 2002 11:11 schrieben Sie:
> ChangeLog
> -
>   converted implementation of _fstat to _fstati64
>   implemented _fstat by calling _fstati64
>

Hello Alexandre,

this patch is relative to my patch _stati64 please apply the _stati64 patch 
before this one. The _stati64 patch went to the worng list by accident.

Thanks Stefan

Exe, Com and PATH

[Sylvain Petreolle]

Wanting to run msdos debugger, I ran from c:\ : wine debug.
the 2 debug that exists on my fake windows are
c:\debug.com
c:\windows\command\debug.exe

My PATH variable is set as
"Path" = "c:\\program\
files\\java\\j2re1.4.0_01\\bin;c:\\windows;c:\\windows\\command;c:\\windows\\system32;c:\\windows\\system;e:\\"

Currently running wine debug from c:\ runs
c:\windows\command\debug.exe,ignoring debug.com in the current
directory. This is not the behaviour expected in real windows.

These are 2 problems here : 
- Normally dos looks first in current directory => would load
c:\debug.com.
There is a problem with PATH here.

- Putting 2 files with a .exe and .com with the same name in the same
directory loads the .exe first, which shouldn't happen.


___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Fwd: Problem with network functions

[Sylvain Petreolle]

Does someone has a clue for this / has same issues ? I cant figure how
to find what is causing the network errors I have.

___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
--- Begin Message ---
Doing a cvs update made some programs unable to access the network.

Cygwin installer and Yahoo Messenger 5.5 say both they can't initialize
the network

If usefull, I pasted a log of the cygwin installer with --debugmsg
+wininet.


trace:wininet:DllMain 0x41e4,1,(nil)
fixme:wininet:InternetAttemptConnect Stub
trace:wininet:InternetOpenA
trace:wininet:InternetCrackUrlA
trace:wininet:GetInternetScheme
trace:wininet:SetUrlComponentValue
http://sources.redhat.com/cygwin/mirrors.lst (4)
trace:wininet:SetUrlComponentValue (null) (0)
trace:wininet:SetUrlComponentValue (null) (0)
trace:wininet:SetUrlComponentValue
sources.redhat.com/cygwin/mirrors.lst (18)
trace:wininet:SetUrlComponentValue /cygwin/mirrors.lst (19)
trace:wininet:InternetCrackUrlA
http://sources.redhat.com/cygwin/mirrors.lst: host(sources.redhat.com)
path(/cygwin/mirrors.lst) extra()
trace:wininet:InternetConnectA ServerPort 80
trace:wininet:HTTP_Connect -->
trace:wininet:HTTP_Connect <--
trace:wininet:HttpOpenRequestA
trace:wininet:InternetCloseHandle 0x402d4db8
trace:wininet:HTTP_CloseHTTPSessionHandle
trace:wininet:SendAsyncCallback Send Callback 70
trace:wininet:InternetQueryOptionA 0x0009
trace:wininet:DllMain 0x41e4,3,(nil)

___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

--- End Message ---

Bug #416: Missing Exports in Winsocks

[Andrew John Hughes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This patch adds stubs for the functions listed in Bug #416, SetService{A,W} 
and GetTypeByName{A,W}.

License: LGPL
- - -- 
Andrew :-)

Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html 
- -BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE94VftSE/kMce1ABARAipUAJ0ew9mD8eqn+2HrS1Yk72lvy+h4QACfaIeV
uPloEX9A/xk4ptC6l0Xl5Z4=
=K3YG
- -END PGP SIGNATURE-

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE94VggSE/kMce1ABARAleXAJ40B6etNGsPhlZdm7GoqCrvYpGwpACgiU/o
2chi+d/NOUGg3WhHjj31UwQ=
=Za8w
-END PGP SIGNATURE-

/*
 * WSOCK32 specific functions
 *
 * Copyright (C) 2002 Andrew Hughes
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */
 
 #include "config.h"
 
 #include 
 
 #include "nspapi.h"
 #include "winerror.h"
 #include "winsock2.h"
 #include "winbase.h"

 #include "wine/debug.h"
 
 WINE_DEFAULT_DEBUG_CHANNEL(winsock);
 
/**
 *  GetTypeByNameA [WSOCK32.1113]
 *
 * Retrieves a service type GUID for a network service specified by name
 *
 * PARAMETERS
 *  lpServiceName -- Pointer to a zero-terminated ASCII string that uniquely represents the name of the service
 *  lpServiceType -- Pointer to a variable to receive a GUID that specifies the type of network service
 *
 * RETURNS
 *  Zero on success, SOCKET_ERROR on failure.
 *  GetLastError can return ERROR_SERVICE_DOES_NOT_EXIST
 *
 * NOTES
 *  Obsolete Microsoft-specific extension to Winsock 1.1.
 *  Protocol-independent name resolution provides equivalent functionality in Winsock 2.
 *
 * BUGS
 *  Unimplemented
 */
 
 INT WINAPI GetTypeByNameA(LPSTR lpServiceName, LPGUID lpServiceType)
 {
/* tell the user they've got a substandard implementation */
FIXME("wsock32: GetTypeByNameA(%p, %p): stub/n", lpServiceName, lpServiceType);

/* some programs may be able to compensate if they know what happened */
SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
return SOCKET_ERROR; /* error value */
 }
 
 /**
 *  GetTypeByNameW [WSOCK32.1114]
 *
 * Retrieves a service type GUID for a network service specified by name
 *
 * PARAMETERS
 *  lpServiceName -- Pointer to a zero-terminated Unicode string that uniquely represents the name of the service
 *  lpServiceType -- Pointer to a variable to receive a GUID that specifies the type of network service
 *
 * RETURNS
 *  Zero on success, SOCKET_ERROR on failure.
 *  GetLastError can return ERROR_SERVICE_DOES_NOT_EXIST
 *
 * NOTES
 *  Obsolete Microsoft-specific extension to Winsock 1.1.
 *  Protocol-independent name resolution provides equivalent functionality in Winsock 2.
 *
 * BUGS
 *  Unimplemented
 */
 
INT WINAPI GetTypeByNameW(LPWSTR lpServiceName, LPGUID lpServiceType)
{
/* tell the user they've got a substandard implementation */
FIXME("wsock32: GetTypeByNameW(%p, %p): stub/n", lpServiceName, lpServiceType);

/* some programs may be able to compensate if they know what happened */
SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
return SOCKET_ERROR; /* error value */
}

/**
 *  SetServiceA [WSOCK32.1117]
 *
 * Registers or unregisters a network service with one or more name spaces
 *
 * PARAMETERS
 *  dwNameSpace -- Name space or set of name spaces within which the function will operate
 *  dwOperation -- Specifies the operation that the function will perform
 *  dwFlags -- Set of bit flags that modify the function's operation
 *  lpServiceInfo   -- Pointer to a ASCII SERVICE_INFO structure
 *  lpServiceAsyncInfo  -- Reserved for future use.  Must be NULL.
 *  lpdwStatusFlags -- Set of bit flags that receive function status information
 *
 * RETURNS
 *  SOCKET_ERROR on failure.
 *  GetLastError can return ERROR_ALREADY_REGISTERED
 *
 * NOTES
 *  Obsolete Microsoft-specific extension to Winsock 1.1
 *  Pro

Re: Some additions to D3D

[Alexandre Julliard]

Lionel Ulmer <[EMAIL PROTECTED]> writes:

> Note (for Alexandre): how would you prefer for us to track dependencies
>  between patches ? Submit each time a patch agains fresh CVS with all
>  previous patches sent (with an ever growing changelog) or do you prefer
>  (like here) a lot of patches dependant one on the others ?
>  If it's the latter, do we need to do 'letter tracking' as Dimi did ?

In general separate patches are better; the exception is if they are
fixes to a previous patch then it's better to resend all so I don't
have to try to understand the broken version before reading the fix.

And yes, in either case please find a way to clearly mark the
sequence, don't rely on the submission order because mail doesn't
always arrive in the correct order.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

RE: Wintab.dll technical issues.

[Patrik Stridvall]

> Firstly a quick note:
> I have opened a bug for implementation of wintab.dll (Bug No. 1160)
> 
> Now the questions:
> 
> 1: Writing stubs.
> I'll be taking up Patrik Stridvall's offer to write stubs for 
> anyone new 
> to wine development.

Yes, I'm working on it right now.
Will probably not finish tonight though.

> One question about stubs:
> What's the wine policy on stub return values?

No general policy. It depends.

> Should a stub always return an error?

Normally stubs should indicate error (return NULL, FALSE or similar)
and do SetLastError(ERROR_NOT_IMPLEMENTED).

> Should/Can it return success?

In some cases indicating success (return TRUE or similar), even
though it not strictly correct, might be a good idea. It depends.

Lying to the application should be avoided of course but sometimes
it is nessary.

> 2: Testing wintab.dll in Win98.
> wintab.dll is quite complex for what it does.

I guess you mean wintab32.dll.
wintab.dll is the 16 bit variant AFAICS.

> Therefore the only practical way to implement it is
> to work on the functions and communication models that are
> used by the apps I want it to support.

Probably.
 
> To do this, I need some tool that can log the function calls and
> parameters to the DLL, while wunning Win98.The logging must 
> be able to 
> let the
> programmer choose elements from data stuctures in 
> parameters/retvals to log.
> Any ideas

There are no good tools to do this AFAIK. But if you find any
I'm very intrested.
 
> I've attempted to use apis32 and built a wintab.fnl file for 
> wintab.dll.
> Unfortunately apis32 doen't allow the logging of the contents of data 
> structs.

Yes. APIS32 is the best AFAIK and it sucks pretty bad IMHO.
 
> I would also like to know experinces with Spy++.
> Wintab can send it's own custom messages, so I'm wondering how good
> Spy++ is at detecting custom messages?
> 
> I've used it many times before, but only to examine standard windows 
> messages.

No idea, haven't used it for years. 
 
> 3: Coding standards.
> I haven't found any coding standards associated with wine.
> This is particularly important, as I'll be writing new source files.
> Can someone point me to the standards?

We have none. Decide for yourself. However please do not choose anything
to unlik anything else in Wine.

Wintab.dll technical issues.

[Robert North]

Firstly a quick note:
I have opened a bug for implementation of wintab.dll (Bug No. 1160)

Now the questions:

1: Writing stubs.
I'll be taking up Patrik Stridvall's offer to write stubs for anyone new 
to wine development.
One question about stubs:
What's the wine policy on stub return values?
Should a stub always return an error?
Should/Can it return success?

2: Testing wintab.dll in Win98.
wintab.dll is quite complex for what it does.
Therefore the only practical way to implement it is
to work on the functions and communication models that are
used by the apps I want it to support.

To do this, I need some tool that can log the function calls and
parameters to the DLL, while wunning Win98.The logging must be able to 
let the
programmer choose elements from data stuctures in parameters/retvals to log.
Any ideas

I've attempted to use apis32 and built a wintab.fnl file for wintab.dll.
Unfortunately apis32 doen't allow the logging of the contents of data 
structs.

I would also like to know experinces with Spy++.
Wintab can send it's own custom messages, so I'm wondering how good
Spy++ is at detecting custom messages?

I've used it many times before, but only to examine standard windows 
messages.


3: Coding standards.
I haven't found any coding standards associated with wine.
This is particularly important, as I'll be writing new source files.
Can someone point me to the standards?

Hope you guys have the answers
   -Rob.

Re: [bug 718] Executing dos DPMI programs

[Jukka Heinonen]

On Sun, Nov 24, 2002, Sylvain Petreolle wrote:
> as i'm sending patches and working on cygwin/wine, i'm always doing cvs
> update and looking into the wine-cvs/wine-patches lists to see if some
> patches are committed.
> 
> if you look at the log of some dpmi program, it makes call to int31
> handler and thus switches to 32-bit mode. after that program makes some
> things, then wants to make a dpmi call : wine says that int xx is
> forbidden in 32 bit mode.

Oh, that error message. Well, the line that generates the message
was deleted about seven weeks ago from official Wine CVS. Anyway, 
as I already has stated, most DPMI32 programs won't work and I will 
start working on that problem when I get interrupt handler migration 
finished. This would likely happen during late december or early january.

Sigh, I just sometimes wonder why I bother to explain these things...
All DPMI16 programs should work and for some strange reason
some DPMI32 programs work, too (pkzip for example). StartPM is called 
from int31 handler when "int 0x31" opcode is executed in DPMI protected 
mode switch wrapper. StartPM always makes a switch to 16-bit 
protected mode. DPMI32 applications usually allocate a 32-bit selector 
and make a jump which loads that selector into CS register. This makes
the application enter 32-bit protected mode. 

-- 
Jukka Heinonen 

Re: [bug 718] Executing dos DPMI programs

[Sylvain Petreolle]

> The problem is that Wine has no support for calling Wine 
> functions from application context whose stack and code pointers 
> use 32-bit segmented model. Wine interrupt emulation
> currently uses a simple scheme which works with any code pointer 
> but which fails miserably if stack pointer is over 0x. 
> The simplest fix would probably be to swap to 16-bit stack on 
> entry to Wine interrupt handler. This would mean that only
> winedos dll needs to deal with 32-bit segmented stuff.
> I have a rather good idea on how this can be implemented.
> 
> Anyway, your error message looks quite interesting because 
> current Wine version emulates *all* interrupt opcodes in real 
> mode, 16-bit protected mode and 32-bit protected mode and thus it
> should be impossible to get this error message. Are you sure
> you tried executing using the latest CVS version or at least 
> the latest release?
> 
as i'm sending patches and working on cygwin/wine, i'm always doing cvs
update and looking into the wine-cvs/wine-patches lists to see if some
patches are committed.

if you look at the log of some dpmi program, it makes call to int31
handler and thus switches to 32-bit mode. after that program makes some
things, then wants to make a dpmi call : wine says that int xx is
forbidden in 32 bit mode.

___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

[RFC] pthread emulation on FreeBSD (and Linux)

[Patrik Stridvall]

With the attached patch FreeBSD compiles again
even if OpenGL (which need pthreads) is used.

Since it is only stubs at present OpenGL can't really work,
but Wine and the normal test runs fine ("make test").


Anyway, to answer the first obvious question:
Why didn't you just put it in scheduler/pthread.c?

Well, the thing is it didn't work. It still generates the
same link errors. However that is not very suprising since
the pthread_ implementation is in ntdll.dll which is
not linked with during the "-Bsymbolic -z defs" step.

This begs the question:
Does the Linux implementation of pthread really work anyway?

The thing is Linux (or rather the GNU C library) always links
in pthread suppport. However since some of the symbols are
on purpose defined as weak they can be overriden. This is
what scheduler/pthread.c does on Linux. Or rather tryies to
do. I'm not really sure if works any longer.

Note that if I apply the attach patch and compiles on
Linux it seems to work with "make test" as well.

Anyway be pthreads on Linux working properly as it may, the big
question is how do we support pthreads on both Linux and FreeBSD.

FreeBSD since it AFAICS have no default overridable implementation
seems to require that we have some sort of wine_pthread library to
implement pthreads from scratch like outlined in the attached patch.

I'm not really very good on how runtime linking on Linux and FreeBSD.
So, I would very much like comments from people more knowledgeable
than I on that area.

Comments? Suggestions?

PS. Can somebody test if OpenGL:s pthread locking REALLY works properly on
Linux?




pthread.diff
Description: Binary data

Re: [bug 718] Executing dos DPMI programs

[Jukka Heinonen]

> Does someone has success when executing DPMI programs ?
> Every program I try to execute at this time fails,
> going to the debugger, saying :
>
> Unhandled exception: privileged instruction in 32-bit code
> (0x).
> In 32-bit mode.
> 0x: int $0x31

DPMI16 programs should work as should simple DPMI32 programs.
However, most DPMI32 programs are not even supposed to work
because there is no real implementation of 32-bit interrupt
handling. It is on my TODO list but I'm currently working on
moving interrupt handlers to winedos dll and I shall return
to DPMI32 support after this.

The problem is that Wine has no support for calling Wine 
functions from application context whose stack and code pointers 
use 32-bit segmented model. Wine interrupt emulation
currently uses a simple scheme which works with any code pointer 
but which fails miserably if stack pointer is over 0x. 
The simplest fix would probably be to swap to 16-bit stack on 
entry to Wine interrupt handler. This would mean that only
winedos dll needs to deal with 32-bit segmented stuff.
I have a rather good idea on how this can be implemented.

Anyway, your error message looks quite interesting because 
current Wine version emulates *all* interrupt opcodes in real 
mode, 16-bit protected mode and 32-bit protected mode and thus it
should be impossible to get this error message. Are you sure
you tried executing using the latest CVS version or at least 
the latest release?

-- 
Jukka Heinonen