wine-devel

wine-devel@winehq.org

9 participants
84457 discussions

Re: Nasty Wine/kernel bug, anyone?
by gerard patel 25 Mar '01

25 Mar '01

At 12:14 PM 20/03/2001 -0600, you wrote: <snip> >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. Where did this Notes bug turn up ? I never saw it on the news group, and it's not in your bug database. I'm curious because I would like to know how to reproduce it (I don't want not install Win98 and Outlook to test this :-/) Btw, since Borland released Kylix they talk of a glibc bug in dlopen : http://community.borland.com/article/0,1410,26998,00.html do you know if it's a concern for Wine too ? Gerard

3 2

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Alexandre Julliard 25 Mar '01

25 Mar '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > Exactly. > > I think a compromise would be to create a wrapper script that modifies > the config file first to use appropriate settings and then calls the main > Wine binary. That's certainly a possibility. If you want a more temporary change you could also use regapi to change the config branch in the registry. Yet another possibility would be to add a "fast" mode to the debugger where it wouldn't load symbols or anything, simply setup the environment and launch an application. This could be the first step towards making it change debugmsg options during execution too. And all these solutions are potentially much more generic than the few existing options, since you could use the same mechanism to change just about anything in the configuration. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Guy L. Albertelli 24 Mar '01

24 Mar '01

-----Original Message----- From: Alexandre Julliard <julliard(a)winehq.com> To: andi(a)rhlx01.fht-esslingen.de <andi(a)rhlx01.fht-esslingen.de> Cc: Wine Devel <wine-devel(a)winehq.com> Date: Saturday, March 24, 2001 2:34 PM Subject: Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ... >There are tons of settings that can only be set through the config >file; why are the few remaining options so much different that you >need to set them on the command line? and how do you pass options >when an app is not launched from the command-line (like from another >Windows app, or from a desktop icon)? > As a developer, I find the ability to change -desktop/-managed, -debugmsg, -dll options on every run from the command line invaluable. If I had to edit config every time I wanted to change -debugmsg or -dll options, my progress would be at least cut in half. Guy

2 1

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Alexandre Julliard 24 Mar '01

24 Mar '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > There are some options, like the --desktop/--managed option, that the user > may want to change quite often. Having to edit the config file is painfull > in that case. It will soon be possible to specify them per-application in the config file, so this should address the main reason for changing them often. If people really want more flexibility there are many ways of doing that; but hard-coding the options in kernel32 isn't one of them. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Alexandre Julliard 24 Mar '01

24 Mar '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > IMHO --desktop is *very* important. > > This will inevitably lead to tons of very confused questions, just like > with the sudden config file change. Yep, and there will still be other changes that will break everything and confuse users (think window management for instance); that the reason we are not at 1.0 yet. > And why don't you get rid of --managed then either ? It will happen, don't worry... > And how exactly does this break dll separation ? Because with these command-line options kernel32 must know about and export information specific to x11drv. Also there's a larger issue of mechanism vs. policy; if we want to be able to use the same set of Wine libraries for multiple usage (wine loader, Winelib apps, mp3 players loading Windows dlls, etc.) we need to move all policy decisions to the higher layers. We cannot have kernel32 enforce a specific command-line usage, since this doesn't apply in all cases. For another instance of the same issue, see the discussion about the deferred debug trace a couple of weeks ago: we need the Wine libraries to provide the *mechanism* to display tracing and other informations, but the *policy* of when and how to switch tracing on or off must be moved to higher layers (like the debugger) instead of hardcoding a magic key sequence in user32. > Can't we solve this in another way ? > (i.e. maybe keep cmdline options for Wine, but don't use them for Winelib > apps) > Getting rid of all command-line options is not really an option IMHO. > They are just way too useful. There are tons of settings that can only be set through the config file; why are the few remaining options so much different that you need to set them on the command line? and how do you pass options when an app is not launched from the command-line (like from another Windows app, or from a desktop icon)? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Alexandre Julliard 24 Mar '01

24 Mar '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > Huh ?? > > Why would you consider --desktop to be "obsolete" ? It's not obsolete, it just has to be specified in the config file instead. All command-line options are going to disappear at some point, first because they are problematic for some Winelib apps, and second because they break dll separation. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/ dlls/x11drv/x11drv_main.c documentation/ ...
by Andreas Mohr 24 Mar '01

24 Mar '01

On Fri, Mar 23, 2001 at 06:45:46PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 98539114690732747875154 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard@wine2. 01/03/23 18:45:46 > > Modified files: > dlls/x11drv : x11drv_main.c > documentation : wine.man.in > documentation/samples: config > graphics/x11drv: xfont.c > include : options.h x11drv.h > misc : options.c > windows : dce.c win.c > windows/x11drv : event.c wnd.c > > Log message: > Cleanup properly on x11drv unloading. > Moved --synchronous option into config file. > Removed --desktop, --display and --language command-line options. Huh ?? Why would you consider --desktop to be "obsolete" ? Andreas Mohr

1 0

Re: Handling overlapping buffers in wcstombs_sbcs
by Alexandre Julliard 23 Mar '01

23 Mar '01

Fran=E7ois Gouget <fgouget(a)codeweavers.com> writes: > Actually the documentation specifies that WideCharToMultiByte (cal= led > by ConvertVersionInfo32To16) fails if the source and destination > pointers are the same. But it does not specify what happens if the > buffers merelyt overlap. And of course in the ConvertVersionInfo32To16 > case there's a 2 byte difference between them! Then ConvertVersionInfo32To16 is broken; WideCharToMultiByte does not support overlapping buffers. > I'm not really convinced by the loop unrolling but I tried to keep= it > anyway. I just modified it a bit. If someone's interested in doing > actual performance tests, wants to look at the assembly or knows how > manual loop unrolling must be done, go ahead. You know, I did exactly that (looking at the assembly and running performance tests) when implementing it; it may be possible to improve it more by optimizing CPU pipelines usage, which is something I don't know too much about. But I strongly doubt you can improve it by only looking at the C source... --=20 Alexandre Julliard julliard(a)winehq.com

1 0

Re: [PATCH] Add Callback for wavemapper -> widOpen
by Alexandre Julliard 22 Mar '01

22 Mar '01

"James Hatheway" <james(a)macadamian.com> writes: > Changelog: > James Hatheway - james(a)macadamian.com > widOpen in the wavemapper should use a callback. It doesn't seem right to use winmm internal structures here. Are you sure this is the right way to do it? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Nasty Wine/kernel bug, anyone?
by Alexandre Julliard 22 Mar '01

22 Mar '01

lawson_whitney(a)juno.com writes: > Or is this a different glibc bug? Yes, it's apparently a bug in reference counting when freeing libraries; since we never free our libraries at the moment, we haven't run into this one yet. -- Alexandre Julliard julliard(a)winehq.com

1 0

problems compiling mfc with winelib
by Doug Alcorn 22 Mar '01

22 Mar '01

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.

2 1

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

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: > Perhaps version.dll code should use DONT_RESOLVE_DLL_REFERENCES instead of > undesirable LOAD_LIBRARY_AS_DATAFILE? Not necessarily, it may be considered a feature to load version info from the native dll, even though the actual code will run from the builtin. This may help programs believe they got the exact version they wanted (since presumably the app installed the dll in the first place). > Will DONT_RESOLVE_DLL_REFERENCES work with built-in dlls somewhere in the future? Unlikely; the problem is that we cannot prevent constructors from running, and we need to resolve imports before running constructors. -- Alexandre Julliard julliard(a)winehq.com

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: > But here is a problem. This doesn't honor a load order. If load order > of a requested dll explicitly specified as 'builin' but 'native' library > there is somewhere in the path, then we will get unexpected result. > How to cope with it? I think it's reasonable to give the native dll priority when doing LOAD_LIBRARY_AS_DATAFILE. An app using this wants to poke inside the dll binary file and we are much better off giving it the 'real' thing in this case IMO. -- Alexandre Julliard julliard(a)winehq.com

2 1

fixme:win32:DeviceIoControl Unimplemented control 104 for VxD device SECPROV
by Achilleas Mantzios 19 Mar '01

19 Mar '01

Does anyone have a clue??? P.S. You have done serious job :) i wanna say. -- Á÷éëëÝáò ÌÜíôæéïò Application Developer Eurisko A.E. ÐéíäÜñïõ 9 106 71 ÁèÞíá Ôçë: +301 3633362 Öáî: +301 3633074 e-mail: achilleas.mantzios(a)eurisko.gr

1 0

Re: RFC: client side implementation of async I/O
by Mike McCormack 19 Mar '01

19 Mar '01

Hi All, WWW reported that my client side async patch relies on the service thread... sorry for not clearly explaining, but it doesn't. It works by multiplexing the server's wait reponse fd with pending i/o operation fds using poll. When i have time, i'll try to clean it up a bit. Currently i'm working on a kernel patch to help implement other WaitCommEvent flags. i hope Alexandre considers applying the client side async patch in some form. Mike ------------------------------------------ mailto:Mike_McCormack@looksmart.com.au ph +82 16 430 0425 __________________________________________________________________ Get your own free web email at http://www.looksmart.com.au LookSmart Australia

1 0

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