wine-devel

wine-devel@winehq.org

11 participants
84461 discussions

Re: Port to OS/390 mainframe USS?
by James Hatheway 22 Mar '01

22 Mar '01

Hello James, > I am not real clear about the difference between the PE loader and the > WINELIB, but then, I am also unclear as to why my user would want to run a > Windows app on the mainframe in the first place. Sorry, I should have been a bit more descriptive with my answer. The PE loader is used to run executable files that were compiled to be executed in Windows/intel environment (standard windows apps). It handles the 'magic' of loading a windows executable including the necessary dependecy checking, dynamic link library loading, etc. Once the executable is loaded and all dependecies to DLLs resolved and loaded the program is started and runs with the same intel code that would have executed in windows. Whenever the app makes a call to a Windows API function, the code actually is handled by WINE code (or the native windows DLLs if that is the user's configuration) That is why WINE is not an 'emulator' rather a reimplementation of the Windows API. That is also why it is tied to the intel platform, since it is still directly executing intel code. Since WINE is comprised mainly of a reimplementation of the Windows API, it can also be used as a porting library for application developers. WineLib allows a developer to recompile his Windows source so that it will run on other unix platforms (including other CPU architectures than intel). The problem is that not as much work goes into the WineLib side of WINE than does go into the mainstream WINE side of things. My understanding is that WineLib has been built on Solaris/Sparc, powerpc, and s390 with varying degrees of success. Also I don't know if the patches that got these platforms to build are actually in the main CVS tree. Searches through past WineHQ discussions can bring up the names of those who worked on this stuff. So, unless your user has access to the source code to his app, he can't use WINE to run his app on the S390. I'm not sure if WineLib has advanced enough to support his app on the S390, and in fact Wine itself might not support his app on intel either, that is a case by case thing. (although WINE works quite well for a lot of apps) Finally I have no idea why a user would want to run a windows app on a s390. ^_^ > Is there someone at Ulrich that I should be talking to? Ulrich is a person: Ulrich Weigand. He subscribes to the mailing list so I am sure he saw your message. You can get his email address from the mail list archives. -James -- James Hatheway Software Designer - Macadamian Technologies, Inc. james(a)macadamian.com ~ http://www.macadamian.com "Man könnte froh sein, wenn die Luft so rein wäre wie das Bier" "One could be happy if the air were as pure as the beer"

2 2

Re: Nasty Wine/kernel bug, anyone?
by Steve Fox 21 Mar '01

21 Mar '01

> Could you check in which kernel routine the process is blocked? > (e.g. using ps -Ao pid,wchan) Running 'ps -Ao pid,wchan' shows that all the processes in uninterruptible sleep are in the do_exit routine. >> Because the process is already gone, I can't strace or gdb it. > > What do you mean 'the process is already gone'? Could it be that > ptrace doesn't work because the Wine server has already attached > to that client process? I am unable to attach to it with gdb either. I get the error: Attaching to program: /opt/notes5/wine/bin/wine, Pid 22018 ptrace: Operation not permitted. > Steve, is VFAT also involved in your case? Only ext2 here. Steve Fox IBM Linux Technology Center http://oss.software.ibm.com/developerworks/opensource/linux http://stevefx.rchland.ibm.com (IBM Intranet)

1 0

Port to Sparc64
by Jutta Wrage 21 Mar '01

21 Mar '01

Hi! What about the suggested port to Sparc? Did anybody work on that again? There was a question in the Wine-HOWTO mailing list. cu Jutta -- http://www.witch.westfalen.de/ Wine-HOWTO http://www.la-sorciere.de/wine/

2 1

any questions?
by Natanael Copa 21 Mar '01

21 Mar '01

Hi! David A. Solomon, the author of "Inside MS Windows 2000", is comming for a seminar 2-3 April here in Oslo. He is a friend of one of mine friends so I got a free ride. I am not envolved in the wine development (I would love to if I had the time) and I don't have any experience with the win32 API or any windows programming. But when I got this invitation my first thought was you guys, who develop wine. So if anyone want me to ask him about anyhing about windows and the win32 API, I would love to so. David is an expert when it comes to win32 API and he has the source codes for windows. http://solsem.com Best Regards, Natanael Copa

1 0

Port to OS/390 mainframe USS?
by James.Robinson＠crowley.com 21 Mar '01

21 Mar '01

Will there be a port of WINE to OS/390 mainframe USS? LINUX runs fine under USS, so it would seem that WINE should run there as well. Has anyone done this yet? Thanks James Robinson james.robinson(a)crowley.com

4 3

any questions?
by Natanael Copa 21 Mar '01

21 Mar '01

1 0

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard 20 Mar '01

20 Mar '01

"Dmitry Timoshkov" <dmitry(a)sloboda.ru> writes: > Does the attached patch look as applicable? Yep, looks good. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: x11drv patch
by lawson_whitney＠juno.com 20 Mar '01

20 Mar '01

On Mon, 19 Mar 2001, Ove Kaaven wrote: > Here's some more x11drv code... in addition to the HAL bits, it adds some > gamma control stuff, so we can implement Get/SetDeviceGammaRamp (in GDI). > > Log: > Ove Kaaven <ovek(a)transgaming.com> > Added gamma ramp code to the XVidMode interface. Good day! I think this misses x11ddraw.h. At least, I don't have it. xvidmode.c:16: x11ddraw.h: No such file or directory I will find it though. Lawson ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

2 2

wine: debugtools.c:210: wine_dbg_vprintf: Assertion failed
by Dmitry Timoshkov 20 Mar '01

20 Mar '01

Hello all. I have this very strange situation: Debugging with +relay,+win,+region,+message has revealed: ... Call user32.18: CallNextHookEx(4b483218,00000000,00000001,405a3f40) ret=3d1010fe fs=008f Ret user32.18: CallNextHookEx() retval=00000000 ret=3d1010fe fs=008f trace:message:SPY_EnterMessage (0000565c) {Static} message [0087] WM_GETDLGCODE sent from self wp=00000000 lp=00000000 trace:relay:WINPROC_CallWndProc (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) trace:relay:WINPROC_CallWndProc (wndproc=0x40619540,hwnd=0000565c,msg=WM_GETDLGCODE,wp=00000000,lp=00000000) retval=00000100 trace:message:SPY_ExitMessage (0000565c) {Static} message [0087] WM_GETDLGCODE returned 00000100 wine: debugtools.c:210: wine_dbg_vprintf: Assertion `ret < sizeof(info->output) - (info->out_pos - info->output)' failed. err:ntdll:RtlpWaitForCriticalSection Critical section 0x40685190 wait timed out, retrying (60 sec) fs=0287 It seemed to be as libc bug and I have upgraded my stock rh 6.2 from ftp://updates.redhat.com/6.2 to the latest available glibc-2.1.3-22.i386.rpm and glibc-devel-2.1.3-22.i386.rpm. But nothing has changed. Any suggestions?

2 1

Re: Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set
by Alexandre Julliard 20 Mar '01

20 Mar '01

Dmitry Timoshkov <dmitry(a)sloboda.ru> writes: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Allow loading of built-in dlls with LOAD_LIBRARY_AS_DATAFILE flag set. I think it would be better to keep the existing support for native dlls, and simply fall back to loading the builtin library if SearchPath fails. It's unlikely we are ever going to support proper LOAD_LIBRARY_AS_DATAFILE for builtin dlls anyway. -- Alexandre Julliard julliard(a)winehq.com

2 2

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