September 2005 - Wine-Devel

Documentation on DIBENG.DLL exported functions

by Alex Villacís Lasso

Could somebody please point me to an online documentation on the functions exported by DIBENG.DLL and how an userspace application could use them? I want to evaluate whether a possible DIB engine for Wine could use the DIBENG.DLL API. I googled and all I find are reports of GPFs involving DIBENG.DLL. Same issue when searching MSDN. Of course, DIBENG.DLL might not be the best model to implement for a DIB engine, so I wait for suggestions. I was planning on writing a C program that would load DIBENG.DLL via LoadLibrary() and call its functions in order to build tests for it. Alex Villacís Lasso

Sept. 30, 2005

Re: Release plans

by Tony Lambregts

Alexandre Julliard wrote: > Folks, > > I just released 20050930, this should be considered the pre-0.9 > release, so please give it some good testing. In particular, please > test the things that new users will encounter first, like the > automatic .wine creation and winecfg. > This is fantastic. I have a question though what should I call this release in bugzilla? 20050930 20050930 pre beta 0.9.0 0.9.0 pre beta (20050930) other suggestions???? Obviously we should decide now how our release nameing structure is going to be called and I did not want to just put it in without some feedback... -- Tony Lambregts

Sept. 30, 2005

Re: headless question, and IPC question

by Kuba Ober

> >>2. The sockets trick was the simplest way I could figure out how to do > >>IPC between a linux process and a wine process. > >>However, is there are > >>any better or faster way to do this? As far as I know I can't use > > > > Your .exe can make regular linux syscalls as it's really running on > > linux. So you can essentially do whatever a regular linux application > > would, given constraints enforced by wine's signal handling and such. But > > all simple things like opening a pipe, using ipc() call etc will work. > > The only thing is that you need to code syscall() and a couple of > > wrappers for specific syscalls you want to use, but that's a simple > > matter and glibc sources are a reasonable reference for that. > This assumes that I'm using winelib, correct? Why so? I explicitly mention the .exe. So, no winelib. To the contrary, this assumes that you run your regular .exe under wine. There's nothing linux-only about generating syscall code, you can compile your .exe program say using mingw or Visual C++ as long as you've properly implemented syscall() in [inline] assembly. Presumably, the calling conventions for such a syscall() can be set such that the stack layout will match. Just have a look at the glibc sources. Of course the program will crash on windows, but on linux it should just work and provide a gateway to calling the functions from the .dll that you need. That's what you're after, right? Cheers, Kuba

Sept. 30, 2005

Re: OLEAUT32: add additional condition for creation of interface

by Steven Edwards

On 9/30/05, Alex Villacís Lasso <a_villacis(a)palosanto.com> wrote: > This patch is required in order to run any application that embeds > DBGRID32.OCX from MS VisualBasic 5 or 6 > > Changelog: > * Add additional condition for creation of interface A patch would be nice =) Thanks Steven

Sept. 30, 2005

Re: Off-topic, Was: Re: headless question, and IPC question

by Walt Ogburn

On Fri, 30 Sep 2005, Jakob Eriksson wrote: > Alex Villacís Lasso wrote: > > > > > > > You can try installing and configuring this X server. It will not > > output anything or use a console, but will behave otherwise like a > > valid X server. Then you should point the DISPLAY environment variable > > to this X server, and this will keep your app happy. However, I > > *strongly* recommend to try and create a true console-mode app before > > trying the virtual-framebuffer X server, because it will consume > > precious memory. > > > > You can also run a VNC server on the virtual X server. Then you can > leave and connect to your session > from any client computer, without shutting down your running X programs. > If it's not really trying to do anything graphical, maybe you could use ttydrv instead of xdrv.

Sept. 30, 2005

Re: Rpm's for Fedora Core 4

by Dimi Paun

From: "Dieter Komendera" <dieter.komendera(a)gmx.at> > Any comments, improvements, suggestions are very welcome! FC4 is a popular distro, we _need_ an official binary build for it for the upcoming beta. If Vincent is not going to do it, we need to get these official build uploaded to SF together with all the other ones. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 30, 2005

Re: headless question, and IPC question

by Ken Larson

Kuba Ober wrote: > On Sunday 25 September 2005 05:37, Ken Larson wrote: >>I'm using wine to access a particular proprietary DLL (I don't have the >>source for it) on Linux. The way I'm doing this is to write an EXE that >>wraps the DLL, and makes all of the functions available via socket >>request and response messages. My linux program has access to the >>functions of the DLL by sending socket messages to the EXE running under >>wine. 2 questions: >> >>1. My DLL/EXE uses no calls to pop up graphical windows, so >>theoretically no display is needed. Of course wine needs a display >>because it does not know that an EXE won't make such calls. Is there a >>way to run wine with a null or dummy display - so that it is effectively >>running headless? >> >>2. The sockets trick was the simplest way I could figure out how to do >>IPC between a linux process and a wine process. >>However, is there are >>any better or faster way to do this? As far as I know I can't use > > Your .exe can make regular linux syscalls as it's really running on linux. So > you can essentially do whatever a regular linux application would, given > constraints enforced by wine's signal handling and such. But all simple > things like opening a pipe, using ipc() call etc will work. The only thing is > that you need to code syscall() and a couple of wrappers for specific > syscalls you want to use, but that's a simple matter and glibc sources are a > reasonable reference for that. > > Cheers, Kuba > > > This assumes that I'm using winelib, correct? (I currently am not, I'm compiling on windows, but considering using winelib instead) Thanks, Ken

Sept. 30, 2005

Re: Release plans

by Holly Bostick

Brian Vincent schreef: > On 9/30/05, Alexandre Julliard <julliard(a)winehq.org> wrote: > >> We also still need many documentation updates, so please consider >> helping with that. > > > Is anyone actually working on this? I might have some time this > weekend, but I don't want to step on any toes. > > -Brian > Yes, actually, but right after I volunteered I caught a really bad cold that took me some time to get over. Today is the first day that I feel healthy enough to think about complex things (but unfortunately my boyfriend caught the bug from me, so I'm not getting back up to speed as fast as I might want). In any case, now that there's a new monthly, I can install it this evening and start "doing things like a new user" to see what the process currently looks like from that angle and what seems like it might need to be written down. So I'm here/back. Holly

Sept. 30, 2005

Re: headless question, and IPC question

by Paul Millar

Hi Ken, On Sunday 25 Sep 2005 10:37, Ken Larson wrote: > 2. The sockets trick was the simplest way I could figure out how to > do IPC between a linux process and a wine process. However, is > there are any better or faster way to do this? As far as I know I > can't use winelib because I don't have the source to the DLL. Apologies if this is all obvious ... However you do your IPC, you'll suffer from having to do context switching from changing between the different processes (server & client). Depending on the application, there might be merit in bunching requests together and processing them in one batch. That aside, there's additional overhead from the communication between the two tasks, which you can do in a number of ways (sockets, pipes, ...). Using shared memory (e.g. the SysV shmget() call) would allow the two processes to share parameters, results, etc with no [*] overhead. [*] not quite true (kernel might need to do some page fetching, for example) , but near enough. HTH, Paul.

Sept. 30, 2005

Re: Release plans

by Brian Vincent

On 9/30/05, Alexandre Julliard <julliard(a)winehq.org> wrote: > We also still need many documentation updates, so please consider > helping with that. Is anyone actually working on this? I might have some time this weekend, but I don't want to step on any toes. -Brian

Sept. 30, 2005