Re: Linux 2.2.14 vs 2.3.x networking problem
On Wed, Jun 07, 2000 at 03:45:47PM -0700, Berend Ozceri wrote: > I have a Windows application (Meeting Maker - > http://www.meetingmaker6.com) that works fine under the latest Wine > (built yesterday from CVS) using Linux kernel version 2.2.14. When I > switch to a 2.3.x kernel, the application has networking problems and > can't connect to a server. The really strange thing is that if I run > tcpdump (and leave it running) before I launch Wine and the Windows > application it almost always works under 2.3.x, too. If I don't run > tcpdump, it fails every single time. > > Does this ring a bell with anyone? No, also the networking between 2.2 and 2.4 should not have changed. This sounds like a timing problem somewhere, most likely in our code. select() internal functionality was changed a lot in 2.3.x* if I remember correctly, so this might be a starting point to look. > A cursory look at a winsock trace > under both kernel versions didn't show anything out of the ordinary and > I wanted to check to see if anyone has experienced a similar problem > before I dig deeper. Not reportedly. Ciao, Marcus
Re: Missing prototypes (courtesy of winapi_check)
Alexandre Julliard wrote: > MCIWndCreate is simply an alias for MCIWndCreateA, presumably for > compatibility with apps compiled before #ifdef UNICODE was > invented. So we should make both point to MCIWndCreateA in the spec > file, there's no need for a separate definition or a prototype. But according to the stub, one takes an LPCSTR, while one takes an LPVOID. This could just be a mistake though. The str vs ptr in the spec file has to be sorted out as well. Does anyone have an app which uses this function, so that this can be checked? As I mentioned the win16 version takes an LPSTR (not const), which is why I'm not sure about the LPVOID parameter. Of course, if noone actually has such an app, then it doesn't really matter :) > > -- > Alexandre Julliard > [EMAIL PROTECTED] Bradley
Re: Missing prototypes (courtesy of winapi_check)
Francois Gouget <[EMAIL PROTECTED]> writes: > From their header file actually. It contains the following comment: > > *Thus for the api MCIWndCreate, there are in fact two apis, > *MCIWndCreateA and MCIWndCreateW. If you call MCIWndCreate, this will be > *re-routed to MCIWndCreateA unless UNICODE is defined when building your > *application. In any one application, you can mix calls to the > *Ansi and Unicode entrypoints. > > Also they indicate this API was already there in the Win3.1 times. > Everything else is just an educated guess. MCIWndCreate is simply an alias for MCIWndCreateA, presumably for compatibility with apps compiled before #ifdef UNICODE was invented. So we should make both point to MCIWndCreateA in the spec file, there's no need for a separate definition or a prototype. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Missing prototypes (courtesy of winapi_check)
On Mon, 5 Jun 2000, Bradley Baetz wrote: > Francois Gouget wrote: [...] > > I guess this is what happened. They forgot to split it to A/W when > > they switched to Win32. So after they had to keep it with for > > compatibility. But what type should they give it: LPCSTR or LPCWSTR. In > > fact their doc says it automatically detects which case they are in and > > call the proper A/W function. This is why they have put an LPVOID: > > because it can be either LPCSTR or LPCWSTR. > > And I'll add a comment to that effect. Where did you get that doc from? > I can't find it on the ms website. From their header file actually. It contains the following comment: *Thus for the api MCIWndCreate, there are in fact two apis, *MCIWndCreateA and MCIWndCreateW. If you call MCIWndCreate, this will be *re-routed to MCIWndCreateA unless UNICODE is defined when building your *application. In any one application, you can mix calls to the *Ansi and Unicode entrypoints. Also they indicate this API was already there in the Win3.1 times. Everything else is just an educated guess. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean
Re: Linux 2.2.14 vs 2.3.x networking problem
On Wed, 7 Jun 2000, Berend Ozceri wrote: > I have a Windows application (Meeting Maker - > http://www.meetingmaker6.com) that works fine under the latest Wine > (built yesterday from CVS) using Linux kernel version 2.2.14. When I > switch to a 2.3.x kernel, the application has networking problems and > can't connect to a server. The really strange thing is that if I run > tcpdump (and leave it running) before I launch Wine and the Windows > application it almost always works under 2.3.x, too. If I don't run > tcpdump, it fails every single time. > > Does this ring a bell with anyone? A cursory look at a winsock trace > under both kernel versions didn't show anything out of the ordinary and > I wanted to check to see if anyone has experienced a similar problem > before I dig deeper. Sure. I don't use 2.3.x myself, but it seems like everyone that does have reported some kind of Winsock problems. (If I remember right, one of them reported problems with receiving UDP packets, while sending packets still worked, or something.)
Linux 2.2.14 vs 2.3.x networking problem
I have a Windows application (Meeting Maker - http://www.meetingmaker6.com) that works fine under the latest Wine (built yesterday from CVS) using Linux kernel version 2.2.14. When I switch to a 2.3.x kernel, the application has networking problems and can't connect to a server. The really strange thing is that if I run tcpdump (and leave it running) before I launch Wine and the Windows application it almost always works under 2.3.x, too. If I don't run tcpdump, it fails every single time. Does this ring a bell with anyone? A cursory look at a winsock trace under both kernel versions didn't show anything out of the ordinary and I wanted to check to see if anyone has experienced a similar problem before I dig deeper. Thanks, Berend
Re: Large stack handling update
Alexandre Julliard wrote:
> This breaks i386, since it switches to a stack above the current one
> which corrupts the environment.
Oops, sorry, I overlooked that. The following patch should fix it ...
Bye,
Ulrich
--- wine-cvs/scheduler/sysdeps.cSun Jun 4 22:32:45 2000
+++ wine-uw/scheduler/sysdeps.c Wed Jun 7 23:03:01 2000
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#ifdef HAVE_SYS_SYSCALL_H
# include
@@ -31,6 +32,7 @@
#include "selectors.h"
#include "server.h"
#include "winbase.h"
+#include "global.h"
#include "wine/exception.h"
#include "debugtools.h"
@@ -225,8 +227,7 @@
/***
* SYSDEPS_CallOnStack
*/
-static int SYSDEPS_DoCallOnStack( int (*func)(LPVOID), LPVOID arg ) WINE_UNUSED;
-static int SYSDEPS_DoCallOnStack( int (*func)(LPVOID), LPVOID arg )
+int SYSDEPS_DoCallOnStack( int (*func)(LPVOID), LPVOID arg )
{
int retv = 0;
@@ -281,6 +282,9 @@
void SYSDEPS_SwitchToThreadStack( void (*func)(void) )
{
+DWORD page_size = VIRTUAL_GetPageSize();
+DWORD cur_stack = (((DWORD)&func) + (page_size-1)) & ~(page_size-1);
+
TEB *teb = NtCurrentTeb();
LPVOID stackTop = teb->stack_top;
LPVOID stackLow = teb->stack_low;
@@ -293,8 +297,11 @@
rl.rlim_cur = 8*1024*1024;
}
-SYSDEPS_LargeStackTop = teb->stack_top = &func - 128;
-SYSDEPS_LargeStackLow = teb->stack_low = teb->stack_top - rl.rlim_cur;
+teb->stack_top = (LPVOID) cur_stack;
+teb->stack_low = (LPVOID)(cur_stack - rl.rlim_cur);
+
+SYSDEPS_LargeStackTop = (LPVOID)(cur_stack - 2*page_size);
+SYSDEPS_LargeStackLow = (LPVOID)(cur_stack - rl.rlim_cur);
SYSDEPS_CallOnStack( stackTop, stackLow,
(int (*)(void *))func, NULL );
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
Re: treeview patch
Alex Priem wrote: > Silly question: why aren't the corel-patches also mailed to wine-patches, > so alexandre can apply them at will? Because they won't apply cleanly to the Winehq CVS tree. We have posted some of our patches and hope to do a merge when we finish up our current project. -- Jeff Tranter Project Leader, Linux Development (Wine team), Corel Corporation Take your office suite performance to an exciting new level. Check it out at http://www.corel.com/featuresinaction -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: treeview patch
Marcus Meissner writes: >On Wed, Jun 07, 2000 at 11:47:21AM -0500, Aric Stewart wrote: >> This patch causes the treeview in wine to properly handle InsertItem >> with an invalid HTREEITEM. Windows handles these like a TVI_LAST. >> >> Note: Corel's tree does this properly also, but the corel comctrls are >> so extensively rewritten that i was unable to figure out a direct way to >> use their code. Basically i expect this patch along with most of the >> remainder of the function to be tossed out once someone take the time to >> bring in the cleaner corel code. But for now this fixes a problem with >> the current wine tree. > >The Corel treeview.c has so far deviated from the WINE HQ I see no real chance >in merging it. (Well, at least for my knowledge.) Only replacement might be >possible. Last time I looked at it (in march) it was still possible to split things up in small chunks; however I all lumped it together in one big chunk (stupid) and mailed that to alexandre (also without mentioning the authors of the original patches), and then it got dropped in /dev/null (understandably). Taking things apart could take a few days, but is certainly doable IMO. There are however a lot of things (treeview edit control, for instance) where I don't have test applications for, or where I think things like `err...could be', so I wouldn't know if things were done `the right way'. (The only place where even I would do a direct copy from corel is in the drawing code. That part of my code is just a kludge.) [Unfortunately I don't think that I have the time to do this myself; I have a PhD thesis to finish and the dutch social security[+] isn't as `cooperative' as they used to be] [+] bastards. Silly question: why aren't the corel-patches also mailed to wine-patches, so alexandre can apply them at will? Regards, alex
Re: CVS Errors
Hi, I'm still getting the error "`/home/wine/wine/dlls/kernel': Permission denied", all other directories work fine. Is there still a problem? Thanks Dave Hawkes Cadlink Technology - Original Message - From: "Douglas Ridgway" <[EMAIL PROTECTED]> To: "Jason Mawdsley" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, June 07, 2000 11:17 AM Subject: Re: CVS Errors > > > On Wed, 7 Jun 2000, Jason Mawdsley wrote: > > > Hi- > > > > We seem to be getting these errors again. > > > > cvs server: failed to create lock directory in repository > > `/home/wine/wine/dlls/kernel': Permission denied > > Should be fixed, at least temporarily. If it happens again, let me know, > and I'll try and figure out what's going on. > > doug. > [EMAIL PROTECTED] > >
Re: How to start WINE the first time
On Wed, 7 Jun 2000, Stephen Liu wrote: > Hi all people, > > (If this posting is OT, please accept my apology first and advise me the > right list for its posting. Thanks) > I don't know of a list for it, but you might get more joy out ot the newsgroup comp.emulators.ms-windows.wine > > Wine is completely new to me. I have RPM wine-2526-7.i386.rpm in RH > 6.2 > as follows: > > /tmp/wine-2526-7.i386.rpm > /etc/wine.conf > /usr/bin/wine/windclipsrv > /usr/bin/wine/winedbg > /usr/bin/wine/windserver > /usr/doc/wind-2526/ > /usr/lib/wine/ > /usr/man/man1/win.1 > /usr/man/man5/win.conf.5 > etc. > > I have the complete documents re: > - Wine Binaries for Linux > - Wine Documentation > > printed out but can't find articles relevant to the procedure to make Wine > works. I tried to link this application on KDE and Gnome but could not get > Wine executed as an application. > > Could somebody shed me some light and/or pointer. Red Hat has seen fit to rearrange wine for the rpm such that it is unfamiliar to me. Did they see fit to include the README? That is where you should start. It tells you how to run a program from the command line with wine. AFAIK, wine will not simply run by itself. You use it to run a windows executable. Try from an xterm, wine or have a nice read of man wine, man wine.conf, and the README. > > Thanks in advance. > > B.R. > Stephen > (Remark. I already have Win98 working in hda1) > wine-devel is for discussions concerning the design and development of wine. If you can't work the RedHat package, maybe you should complain on a RedHat list. Regards, Lawson ---cut here YOU'RE PAYING TOO MUCH FOR THE INTERNET! Juno now offers FREE Internet Access! Try it today - there's no risk! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
Re: Calling PE DLLs from ELF
Gavriel State wrote: > > Gavriel State wrote: > > This could be worked around with some kind of import library system - IE: > > have a tool that can build an ELF stub import library from a PE DLL, with > > a initialization routine that would do the LoadLibrary and proc address > > resolution for you. But that doesn't exist right now, as far as I know. > > It occurs to me that this might be a nice way to avoid having to make > manual calls to GetProcAddress to support using native MS DLLs. The > current way of doing things is really ugly. Also, doing this would > help us keep track of the dll-dependance tree more precisely. > > Alternatively, we could perhaps come up with a replacement for ld.so > that can resolve ELF imports from PE exports. I don't know enough > about how the loader/relay code works to know how hard this would be. > Anyone? This is what elfdlls are supposed to be like. An encapsulation of the pe structure in elf. However, I haven't got the time to finish it. I hope to find some time soon. Greetings Bertho
Re: treeview patch
On Wed, Jun 07, 2000 at 11:47:21AM -0500, Aric Stewart wrote: > This patch causes the treeview in wine to properly handle InsertItem > with an invalid HTREEITEM. Windows handles these like a TVI_LAST. > > Note: Corel's tree does this properly also, but the corel comctrls are > so extensively rewritten that i was unable to figure out a direct way to > use their code. Basically i expect this patch along with most of the > remainder of the function to be tossed out once someone take the time to > bring in the cleaner corel code. But for now this fixes a problem with > the current wine tree. The Corel treeview.c has so far deviated from the WINE HQ I see no real chance in merging it. (Well, at least for my knowledge.) Only replacement might be possible. Ciao, Marcus
Calling PE DLLs from ELF
Gavriel State wrote: > This could be worked around with some kind of import library system - IE: > have a tool that can build an ELF stub import library from a PE DLL, with > a initialization routine that would do the LoadLibrary and proc address > resolution for you. But that doesn't exist right now, as far as I know. It occurs to me that this might be a nice way to avoid having to make manual calls to GetProcAddress to support using native MS DLLs. The current way of doing things is really ugly. Also, doing this would help us keep track of the dll-dependance tree more precisely. Alternatively, we could perhaps come up with a replacement for ld.so that can resolve ELF imports from PE exports. I don't know enough about how the loader/relay code works to know how hard this would be. Anyone? -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: [Q] compiling mfc application with winelib
Vivek Dasgupta wrote: > I also tested one more combination. i.e. i have my mfc application > which uses my single function mfc based dll . Now > i compile myapp.exe linking to libmfc.so & winelib. But i want to use > native mydll.dll. > BUt it didn't work. > SO do I have to also load mydll.dll and GetProcAddress for each function > in mydll.dll? For now, that's probably the best solution, though it may not actually work properly if mydll.dll needs to import from libmfc. The problem is that myapp.exe is being built with ELF linkage - all the function calls are being resolved by the ELF linkage mechanisms in ld and ld.so. Let's say you have myapp.cpp, which makes a call to function Foo() in mydll.dll. Since you're compiling with ELF tools, ld doesn't know where to find Foo(), since you can't put mydll.dll on the linker command line (ld wouldn't know what to do with a PE dll). This could be worked around with some kind of import library system - IE: have a tool that can build an ELF stub import library from a PE DLL, with a initialization routine that would do the LoadLibrary and proc address resolution for you. But that doesn't exist right now, as far as I know. Furthermore, even if it did exist, you're going to run into problems with C++ name mangling if mydll.dll wants to link to mfc: the gcc name mangling will be different from what mydll expects, so you'll need to make a full spec file for MFC. You'd probably need the ordinals too. > All this because some apps use third party dlls for which source code is > not available and it has to be loaded natively. > > If you need ordinals in your spec file, the necessary information is in a file > > MFC42.DEF in the MFC source tree. This file has the mangled names and the > > ordinals. To create the spec file, you need the unmangled names. The function > > UnDecorateSymbolName() in the win32 API (see documentation in Visual C++) can > > unmangle the names. It looks like the spec file can be automatically generated > > if necessary. > > But I suppose we need the mangled names for g++. i.e. unmangle names > from mfc42.def and use g++ to mangle them and then put them in spec file > ? I haven't tried this yet. Yes, this should be what you need if you want your libmfc.so to work with mydll.dll. The spec file should map the MFC .def name to the g++ mangled name: For example, for CWnd::Attach(HWND hWndNew): The line in the MFC .def file is: ?Attach@CWnd@@QAEHPAUHWND__@@@Z @ 1651 NONAME And the g++ mangled name is: Attach__4CWndP6HWND__ So the line in the .spec file should be something like: 1651 stdcall ?Attach@CWnd@@QAEHPAUHWND__@@@Z(ptr ptr) Attach__4CWndP6HWND__ > Also while compiling MFC (or any app) the attribute errors are very > important. There were a few crashes due to ignoring of attribute > (stdcall/cdecl) by the compiler. This causes both > the called function and the calling function to free the used stack > space resulting in misplacement of stack pointer. > For most such cases the compiler issues warnings but for a friend > function the compiler doesn't give warning and still ignores __stdcall > attribute. Thus function definition uses __stdcall attribute but when it > is called it uses __cdecl attribute. > For such cases we declared the function outside the class without friend > keyword and it works now. > You could put this in winelib/mfc howto. This is a g++ bug that Corel had Cygnus work on for g++ compiler enhancements. Basically, the compiler was ignoring __stdcall attributes in member functions, if I recall correctly. I'd try using the latest version of g++ to see if it fixes the problem, and if not, ask people on the gcc mailing list about it. You'll also want to edit wine/include/wine/obj_base.h to turn on the com_interface attribute macros. You need these in order to be able to use native COM objects from C++ built with g++, or for native code to use COM objects built using g++. Again, you'll need the latest version of g++ for this to work properly. > Now I am compiling MFC with -D_AFXDLL . However it is giving problems > with a type > IBindStatusCallback in oleimpl.h. This is supposed to come from urlmon.h > and wine doesn't have urlmon.h. Has anybody complied MFC with -D_AFXDLL? Corel has not yet sent in patches from the header work that was done for their MFC development. There was definitely a full implementation of urlmon.h, and other headers. Jeff - would Corel be willing to make the old win_include headers like urlmon.h available for WineHQ developers to integrate? -Gav -- Gavriel State CEO TransGaming Technologies Inc. [EMAIL PROTECTED]
Re: CVS Errors
On Wed, 7 Jun 2000, Jason Mawdsley wrote: > Hi- > > We seem to be getting these errors again. > > cvs server: failed to create lock directory in repository > `/home/wine/wine/dlls/kernel': Permission denied Should be fixed, at least temporarily. If it happens again, let me know, and I'll try and figure out what's going on. doug. [EMAIL PROTECTED]
Cvs mirrors
Hi, Could everybody who has setup a public CVS mirror give me the address? Then I can compile a list which will subsequently go onto the website. Greetings Bertho
Re: CVS Errors
Yes, I've been having the exact same problem for the past couple of days. Maybe someone with root access to the server can check that the ownership/permissions are correct on the relevant directory. Thanks Dave Hawkes Cadlink Technology - Original Message - From: "Jason Mawdsley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 07, 2000 10:18 AM Subject: CVS Errors > Hi- > > We seem to be getting these errors again. > > cvs server: failed to create lock directory in repository > `/home/wine/wine/dlls/kernel': Permission denied > cvs server: failed to obtain dir lock in repository > `/home/wine/wine/dlls/kernel' > cvs [server aborted]: read lock failed - giving up > > logging in and logging out did not resolve the problem > > TIA, > _ > Jason Mawdsley > Macadamian Technologies > > > >
CVS Errors
Hi- We seem to be getting these errors again. cvs server: failed to create lock directory in repository `/home/wine/wine/dlls/kernel': Permission denied cvs server: failed to obtain dir lock in repository `/home/wine/wine/dlls/kernel' cvs [server aborted]: read lock failed - giving up logging in and logging out did not resolve the problem TIA, _ Jason Mawdsley Macadamian Technologies
Re: [Q] compiling mfc application with winelib
Hi Damyan Ognyanoff wrote: > I sugest you to write your app as a .so lib and to > write a small loader. which can perform additional > LoadLibrary'c in it's WinMain routine to load MFC and > your app. Thanks.. this method works. i.e. dlopen(libmfc..) LoadLibrary( mfc..) GetProcAddress ( for MFC's WinMain) Call WinMain I also tested one more combination. i.e. i have my mfc application which uses my single function mfc based dll . Now i compile myapp.exe linking to libmfc.so & winelib. But i want to use native mydll.dll. BUt it didn't work. SO do I have to also load mydll.dll and GetProcAddress for each function in mydll.dll? All this because some apps use third party dlls for which source code is not available and it has to be loaded natively. "Wilbur N. Dale" wrote: > > hand, if libmfc is meant for winelib use only, you may not need to list the > ordinals. I have not tried to create a library with out ordinals so you may > want to experiment. It works without ordinals also if only used for winelib as u said. > > If you need ordinals in your spec file, the necessary information is in a file > MFC42.DEF in the MFC source tree. This file has the mangled names and the > ordinals. To create the spec file, you need the unmangled names. The function > UnDecorateSymbolName() in the win32 API (see documentation in Visual C++) can > unmangle the names. It looks like the spec file can be automatically generated > if necessary. But I suppose we need the mangled names for g++. i.e. unmangle names from mfc42.def and use g++ to mangle them and then put them in spec file ? I haven't tried this yet. Also while compiling MFC (or any app) the attribute errors are very important. There were a few crashes due to ignoring of attribute (stdcall/cdecl) by the compiler. This causes both the called function and the calling function to free the used stack space resulting in misplacement of stack pointer. For most such cases the compiler issues warnings but for a friend function the compiler doesn't give warning and still ignores __stdcall attribute. Thus function definition uses __stdcall attribute but when it is called it uses __cdecl attribute. For such cases we declared the function outside the class without friend keyword and it works now. You could put this in winelib/mfc howto. Now I am compiling MFC with -D_AFXDLL . However it is giving problems with a type IBindStatusCallback in oleimpl.h. This is supposed to come from urlmon.h and wine doesn't have urlmon.h. Has anybody complied MFC with -D_AFXDLL? Thanks Vivek
HOWTO-winelib: Thanks
Thanks to all the people who sent corrections and comments on my HOWTO. I will be making corrections and additions this weekend and submitting the new version on Monday. -- Wilbur Dale Lumin Software BV Zandheuvel 52 B 4901 HW Oosterhout (NB) The Netherlands phone: +31-(0)162-47.88.42 fax: +31-(0)162-43.31.52
How to start WINE the first time
Hi all people, (If this posting is OT, please accept my apology first and advise me the right list for its posting. Thanks) Wine is completely new to me. I have RPM wine-2526-7.i386.rpm in RH 6.2 as follows: /tmp/wine-2526-7.i386.rpm /etc/wine.conf /usr/bin/wine/windclipsrv /usr/bin/wine/winedbg /usr/bin/wine/windserver /usr/doc/wind-2526/ /usr/lib/wine/ /usr/man/man1/win.1 /usr/man/man5/win.conf.5 etc. I have the complete documents re: - Wine Binaries for Linux - Wine Documentation printed out but can't find articles relevant to the procedure to make Wine works. I tried to link this application on KDE and Gnome but could not get Wine executed as an application. Could somebody shed me some light and/or pointer. Thanks in advance. B.R. Stephen (Remark. I already have Win98 working in hda1)
