March 2001 - Wine-Devel - list.winehq.org

Re: Port to OS/390 mainframe USS?

by Andreas Mohr

On Wed, Mar 21, 2001 at 02:27:08PM -0500, James Hatheway wrote: > > 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. ROTFL ! This really fits nicely into the old suspicion that he's not simply one person, but in fact a myriad of people happily hacking away :) (due to the amount of patches he used to submit) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

March 22, 2001

problems compiling mfc with winelib

by Doug Alcorn

I have a small apps with only about half a dozen dialogs. It was originally developed in MS-DevStudio. Our desire is to use the same code between MS-Windows and Linux/Unix using the winelib. This app is derived from CWinApp and uses mfc for all the widgets. I'm told it would take too much effort to redo the app without mfc (I'm not a windows programmer, and don't know much about all that). So, my assumption based on reading winehq.com is that I need to compile the mfc using winelib. I got all the code over to my linux box and converted all the files/directories to lowercase only. I got the mfc, atl, and some other include directory that was under "Program Files/Visual Studio/VC98" (or something similar). I ran winemaker on the mfc directory and successfully got the configure script built. The problem is getting the make files built. I had to define both CFLAGS and CPPFLAGS "-D_WIN32 -DWIN32 -D_WINDOWS -D_MBSC" in the environment. Here's my configure line: $ ./configure --with-win=/path/to/wine/sources --with-atl-includes=/path/to/atl/includes --with-mfc-includes=/path/to/parent/of/mfc/includes It goes allong pretty well until it checks for afx.h. That's when it bombs majorly. I get pages and pages of compile time errors in the config.log. Lots of parse errors, syntax errors, scoping errors, redifinitions... lots of stuff. Am I right that I have to compile mfc? Is this something that most developers using winelib to compile windows programs do? Are there instructions for doing so? At this point I'm totally stumped. I'm not about to start debugging mfc. I'll re-write the app before I do that. What is the suggested course of action? -- (__) Doug Alcorn <doug(a)lathi.net> http://www.lathi.net oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543 |_/ If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait.

March 22, 2001

Re: Nasty Wine/kernel bug, anyone?

by Steve Fox

> 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)

March 21, 2001

Re: Port to Sparc64

by Ulrich Weigand

Hi Jutta, > What about the suggested port to Sparc? > Did anybody work on that again? I did send my fixes to Alexandre; I think the current release should build on Sparc (unless it has been broken again in the meantime -- I haven't tried for some time). In any case, that is a port to Sparc32; Sparc64 is another issue completely (and probably much more difficult) ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 21, 2001

Re: Nasty Wine/kernel bug, anyone?

by Ulrich Weigand

Hi Jeremy, > That is, if I use a pretty stock Wine config, and launch > msimn.exe, we get the splash screen, and then a process > stuck in 'D' (uninterruptible sleep). At this point, > AFAIK, the only solution is to wait for the IO to timeout > (I haven't been patient enough to see if it does), or > to reboot. Could you check in which kernel routine the process is blocked? (e.g. using ps -Ao pid,wchan) > 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? > Anyone > a) Want to take this on? > b) Have advice on how I can generate enough debug info > that we can feed it to the Kernel guys to get it fixed? > > And yes, this happens both on a 2.2 system and a 2.4 system. Hmm. Could you try getting a Wine trace (especially the server/ client interaction)? > I saw at least other user report on this (Steve Fox reported this > with Lotus Notes). > > My best guess is that this is a bug in the vfat driver, > but that's just a hunch. Steve, is VFAT also involved in your case? Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 21, 2001

Re: Port to OS/390 mainframe USS?

by Ulrich Weigand

James, > 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? To clear up a possible misunderstanding first: Linux for S/390 does *not* run under USS or under OS/390. OS/390 is (one of) the standard operating system(s) used on S/390 mainframes. One component of OS/390, the Unix System Services (USS), provides an environment that allows to run certain Unix applications. However, USS is not itself an operating system, just an ABI layer on top of OS/390 (somewhat similar to the POSIX subsystem of Windows NT). Linux for S/390, on the other hand, is a true port of the Linux operating system to the S/390 hardware. It runs directly on the S/390 platform, *instead* of OS/390 or any other mainframe operating system. This has the effect that while USS is much more integrated into the OS/390 environment, Linux on S/390 is much more similar to 'real' Unix platforms. Porting Unix or Linux applications to USS is often non-trivial (e.g. gcc does not run on USS at all), while porting to Linux on S/390 is most of the time just a recompile. What I want to say by that is that a port of Wine to *USS* seems rather unlikely, given the difficulties I mentioned. However, a port to *Linux* on S/390 should really be possible, and some time ago I already did a proof-of-concept implementation. Of course, a port of Wine to any non-Intel hardware means just a port of the Wine *library* at the moment, as Wine does not contain a Intel processor emulator and cannot run Windows/Intel binaries on non-Intel hardware. James (Hatheway) has already explained this ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

March 21, 2001

Re: Port to OS/390 mainframe USS?

by James Hatheway

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"

March 21, 2001

Re: Port to OS/390 mainframe USS?

by James Hatheway

> 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? Hi James, If you are talking about WINE the Windows binary PE loader (directly supporting and loading windows .exe files) this will probably never happen, unless somebody wants to add intel emulation code into WINE. (at a significant speed penalty, of course) If you are talking about WineLib, I believe that Ulrich made a post earlier this year mentioning getting at least a partial port of a WineLib app running on an S390. (I believe he mentioned getting Winemine to compile) >From the sounds of it there is still some work needed before WineLib will build and run out of the box on that platform. -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"

March 21, 2001

Port to OS/390 mainframe USS?

by James.Robinson＠crowley.com

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

March 21, 2001

any questions?

by Natanael Copa

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

March 21, 2001