April 2002 - Wine-Devel - list.winehq.org

Re: [Bochs-developers] Porting WineLib on PPC, using Bochs for binaries

by Bryce Denney

On Wed, 24 Apr 2002, KandY wrote: > I'm currently very interested by porting some of the Wine tech.on PPC. > I've been looking for people interested in this kind of painful duty but > I didn't see anybody carrying this type of idea anywhere on the Web. > I've already mailed some people on that subject and someone told me some > people were trying to port WineLib on Sparc (Ulrich Weigand for > instance...). Does anybody of you have more information on that ? Did > somebody did that somewhere on the globe? > > Besides that, to achieve my binary compatibility, I was looking at the > Bochs emulation. Of course, I'm currently affected by some messages on > the web saying the performances are not that great. I have nothing > against emulation of machines but I only want to know of it is possible > to port the Bochs on my Linux PPC and what performances can I expect > (aren't there any benches to help me make my decision ?). Someone said > that with a PIII 933, one can reach 3.5MIPS. Who can tell me success > stories on that before I start working ? That performance estimate sounds about right. It's slow compared to running on a real machine; there's no denying it. In the wine port, you would have the advantage that all the OS calls and graphics are running in native code. I don't have a good measure of how much time bochs spends on graphics, polling for keyboard or mouse events, etc., but it would be pretty easy to make that measurement if you run Bochs with no gui for a while and test the instructions per second. Usually people test the speed by compiling bochs with BX_SHOW_IPS set to 1. Then every second it reports the number of instructions executed per second, in the log file. We frequently talk about ideas for performance improvements, but frankly I think it will be a while (if ever) before we make even a 2x improvement. We do get some benefit from just waiting around, thanks to Moore's Law applied to the machines that people typically run Bochs on. :) Bochs has been focused on emulating entire systems, but it makes perfect sense to used for a user-mode x86 binary emulation system as well. -Bryce

April 24, 2002

Porting WineLib on PPC, using Bochs for binaries

by KandY

Hi everybody, I'm currently very interested by porting some of the Wine tech.on PPC. I've been looking for people interested in this kind of painful duty but I didn't see anybody carrying this type of idea anywhere on the Web. I've already mailed some people on that subject and someone told me some people were trying to port WineLib on Sparc (Ulrich Weigand for instance...). Does anybody of you have more information on that ? Did somebody did that somewhere on the globe? Besides that, to achieve my binary compatibility, I was looking at the Bochs emulation. Of course, I'm currently affected by some messages on the web saying the performances are not that great. I have nothing against emulation of machines but I only want to know of it is possible to port the Bochs on my Linux PPC and what performances can I expect (aren't there any benches to help me make my decision ?). Someone said that with a PIII 933, one can reach 3.5MIPS. Who can tell me success stories on that before I start working ? Yann K.

April 24, 2002

Re: comm.c: TransmitCommChar

by Dimitrie O. Paun

On April 24, 2002 10:58 am, Mike McCormack wrote: > Unfortunately, that probably requires a hack in the serial driver. > Actually I should get all these hacks together (including the one for > polling on RTS,DTR,CD,RI deltas) and submit a patch for Linux 2.5.*... > in my copious amounts of spare time ;-) That'd be real nice, as there was much talk in modifying the serial driver some time ago. It also looks like the kernel people are willing to help out Wine. Since we've missed 2.4, maybe we can get them in in time for 2.6 :) -- Dimi.

April 24, 2002

Re: comm.c: TransmitCommChar

by Mike McCormack

Hi Dimi, It's not perfect because TransmitCommChar should bypass the Linux kernel's internal transmit buffer as well as any pending overlapped operations. The characters should be treated the same way as a flow control character. Unfortunately, that probably requires a hack in the serial driver. Actually I should get all these hacks together (including the one for polling on RTS,DTR,CD,RI deltas) and submit a patch for Linux 2.5.*... in my copious amounts of spare time ;-) Mike Dimitrie O. Paun wrote: > On April 23, 2002 07:26 pm, Mike McCormack wrote: > >>Hi Marcelo, >> >>Does this help things? It's not perfect, but it should be better than >>nothing... > > > A comment saying why it's not perfect would be nice... ;) >

April 24, 2002

Re: minor regression testing patch

by Geoffrey Hausheer

Paul Millar wrote: > dwMajorVersion dwMinorVersion dwPlatformID > Win3x+Win32s ? ? VER_PLATFORM_WIN32s > Win95 4 0 VER_PLATFORM_WIN32_WINDOWS > Win98 4 10 VER_PLATFORM_WIN32_WINDOWS > WinME 4 90 VER_PLATFORM_WIN32_WINDOWS > NT3.51 3 51 VER_PLATFORM_WIN32_NT > NT4.0 4 0 VER_PLATFORM_WIN32_NT > Win2k 5 0 VER_PLATFORM_WIN32_NT > WINXP 5 1 VER_PLATFORM_WIN32_NT > WIN.NET 5 1 VER_PLATFORM_WIN32_NT > > So, NT3.51 and NT4.0 should both fail the above WIN98_PLUS test (as > version.dwPlatformId != VER_PLATFORM_WIN32_WINDOWS). If the test is (Major > == 4, Minor > 0) then this would include NT4.0, or am I missing something? NT4.0 has a minor==0, so no, my test will not allow it to pass. However, I was not aware of how dwPlatformID was defined (and I miscounted parentheses in your macro). I think the method you proposed would be more robust than the way I implemented the check, but currently my method should work fine for all availiable MS platforms. Perhaps it would be best to make a test.h somewhere and put all of these kind of definitions someplace so we don't need to redefine them for each test. I'm happy that someone is at least looking at my tests though :) .Geoff

April 24, 2002

Re: printing problem?

by Insyde

sorry, wine version 20020411 Ricardo.

April 24, 2002

printing problem?

by Insyde

I tried to run a program but When I log in and sends me to the other program I have this error: 0806ea98:Call kernel32.VirtualFree(40a50000,00000000,00008000) ret=6a91583f 0806ea98:Ret kernel32.VirtualFree() retval=00000001 ret=6a91583f 0806ea98:Call kernel32.VirtualFree(40b50000,00000000,00008000) ret=6a915818 0806ea98:Ret kernel32.VirtualFree() retval=00000001 ret=6a915818 0806ea98:Ret PE DLL (proc=0x6a9110d9,module=6a910000,type=0,res=0x1) retval=1 0806ea98:Call PE DLL (proc=0x405b0ea8,module=40593000,type=0,res=0x1) 0806ea98:Ret PE DLL (proc=0x405b0ea8,module=40593000,type=0,res=0x1) retval=1 0806ea98:Call PE DLL (proc=0x407a1268,module=40796000,type=0,res=0x1) 0806ea98:Ret PE DLL (proc=0x407a1268,module=40796000,type=0,res=0x1) retval=1 0806ea98:Call PE DLL (proc=0x406a61d0,module=4069c000,type=0,res=0x1) 0806ea98:Ret PE DLL (proc=0x406a61d0,module=4069c000,type=0,res=0x1) retval=1 0806ea98:Call PE DLL (proc=0x407271ec,module=40717000,type=0,res=0x1) 0806ea98:Ret PE DLL (proc=0x407271ec,module=40717000,type=0,res=0x1) retval=1 x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file err:winspool:WINSPOOL_OpenDriverReg win32 style printing used with 16 bits app, try -winver win95 err:winspool:AddPrinterDriverA Can't create Drivers key err:winspool:WINSPOOL_LoadSystemPrinters Failed adding PS Driver (6) fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=024f wine: Unhandled exception, starting debugger... x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=024f err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=024f err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=024f err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=024f err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=024f err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=024f err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=024f err:win:WIN_FindWndPtr window 30021 belongs to other process err:win:WIN_FindWndPtr window 30021 belongs to other process can anyone help me? Thanks Ricardo.

April 24, 2002

Re: C/L utility to translate unix and dos paths

by Andriy Palamarchuk

--- Michael Wetherell <mike.wetherell(a)ntlworld.com> wrote: > Here's a small utility to convert between Unix and > Windows style paths > at the command line. [... skip ...] Mike, you may be interested in cygwin utility cygpath of the same purpose. For description see: http://cygwin.com/cygwin-ug-net/using-utils.html#CYGPATH Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/

April 24, 2002

Re: Re: CoGetClassObject and SHQueryValueEx A/W/AW fixxes

by juergen.schmied＠debitel.net

> I chose SHGetRegPathW from shlwapi, because that seemed to be the best > matching function for getting the registry string. I did not call a *AW > function directly. I fixed the SHQueryValueExW to convert the incoming > strings to ascii, _because_ the SHQueryValueExAW function had a bug in > handling ExpandEnviromentStringsA (always failed) and was ascii-only (it > doesn't seem to handle unicode at all). That was also the part i was not > completely happy about. I must say i'm not to happy about including > shlwapi either, but i think it is better than reinventing the wheel. I'm looking into the SHReg* functions at the moment and do a little cleanup i allready found some more glitches. > What would you suggest i do? Move SHGetRegPath into a libwine and make a > dependency from shlwapi and compobj(ole32) to that library? reimplement > SHGetRegPathW and SHQueryValueExW in place in compobj.c ? Especially > with the lib seperation going on.. there will be more and more inter-dll > dependencys, must we avoid that at all cost? No, we must avoid such dependencys and reimplement this functionality where needed. I send a patch in a few days. juergen

April 24, 2002

Fail to run Dreamweaver 4 -iKernel error

by leanne

Dear all, I tried. to run Dreamweaver 4. After running "Preparing ...." I got iKernel error. Attached pls find the ikernel_error.png Could anybody help? Thanks. Leanne

April 24, 2002