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

Re: enumerate the substorage transforms

by Mike McCormack

Dmitry Timoshkov wrote: > Do you really need this define? It looks like it's unused (not mentioning > that it breaks Wine rules on using unicode APIs). I thought that too before I sent the patch, so I removed it and recompiled just to make sure. It's used by the following definition in include/msiquery.h: #define MSIDBOPEN_READONLY (LPCTSTR)0 So, yes, I need it to open the database using MsiOpenDatabaseW. Mike

Sept. 30, 2005

Re: enumerate the substorage transforms

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > --- dlls/msi/action.c 30 Sep 2005 10:32:41 -0000 1.211 > +++ dlls/msi/action.c 30 Sep 2005 11:33:20 -0000 > @@ -46,6 +46,8 @@ http://msdn.microsoft.com/library/defaul > #define REG_PROGRESS_VALUE 13200 > #define COMPONENT_PROGRESS_VALUE 24000 > > +#define LPCTSTR LPCWSTR Do you really need this define? It looks like it's unused (not mentioning that it breaks Wine rules on using unicode APIs). -- Dmitry.

Sept. 30, 2005

Re: Release plans

by Vijay Kiran Kamuju

I think we need some more clean up of bugzilla, we need to close bugs till 2003/04 which have not updates since 6 months. And also those which cannot be replicatable. bye, Vijay On 9/30/05, Alexandre Julliard <julliard(a)winehq.org> 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. > > Even if you normally build from source, please for once try the binary > package for your distro and check if you spot anything the packager is > doing wrong. > > Bugzilla has had a good cleanup lately (thanks guys!) and most of the > irrelevant bugs have been closed, so please have a look at the > remaining ones to see if there's anything you know how to fix. > > We also still need many documentation updates, so please consider > helping with that. > > If you have scripts that handle releases, now is the time to ensure > they can cope with a version number not in the YYYYMMDD format... > > If all goes well, and if the documentation is updated by then, the > real 0.9 should be released in a couple of weeks. In the meantime we > should consider ourselves in a code freeze, so please don't submit new > features or large changes, only small bug fixes will be allowed in. > > Thanks everybody for your help, it has been a long trip but we are > getting there... > > -- > Alexandre Julliard > julliard(a)winehq.org > > >

Sept. 30, 2005

Release plans

by Alexandre Julliard

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. Even if you normally build from source, please for once try the binary package for your distro and check if you spot anything the packager is doing wrong. Bugzilla has had a good cleanup lately (thanks guys!) and most of the irrelevant bugs have been closed, so please have a look at the remaining ones to see if there's anything you know how to fix. We also still need many documentation updates, so please consider helping with that. If you have scripts that handle releases, now is the time to ensure they can cope with a version number not in the YYYYMMDD format... If all goes well, and if the documentation is updated by then, the real 0.9 should be released in a couple of weeks. In the meantime we should consider ourselves in a code freeze, so please don't submit new features or large changes, only small bug fixes will be allowed in. Thanks everybody for your help, it has been a long trip but we are getting there... -- Alexandre Julliard julliard(a)winehq.org

Sept. 30, 2005

Re: headless question, and IPC question

by Kuba Ober

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

Sept. 30, 2005

Re: headless question, and IPC question

by Ken Larson

cool, can you point me to where i can find the info on how to easily set up this cross-compiler on linux? thanks, Ken Richard Cohen wrote: > Ken Larson wrote: >> Well I am actually using a command-line with CL to compile it, but it >> was true that I had a WinMain instead of main. >> >> I've changed the WinMain to main, but this doesn't seem to be the issue. >> >> The issue appears to be initializing winsock. The following simple >> main program, when compiled with CL, and run with wine, requires an X >> display: >> > Your minimal winsock program doesn't need X when cross-compiled with > mingw, and runs happily using winetty.drv > > $ i586-mingw32msvc-gcc winsock.c -l wsock32 > > $ WINEDEBUG=loaddll DISPLAY= ~/wine/wine-20050830/wine ./a.exe > ... > trace:loaddll:load_builtin_dll Loaded module > L"c:\\windows\\system32\\winex11.drv" : builtin > trace:loaddll:MODULE_FlushModrefs Unloaded module > L"c:\\windows\\system32\\winex11.drv" : builtin > trace:loaddll:load_builtin_dll Loaded module > L"c:\\windows\\system32\\winetty.drv" : builtin > $ > > Richard. > > >

Sept. 30, 2005

Re: freedce-win32 - progress!

by Luke Kenneth Casson Leighton

On Fri, Sep 30, 2005 at 08:41:17AM +0200, Jakob Eriksson wrote: > Luke Kenneth Casson Leighton wrote: > > >i am making the "amateur" version of progress: i just had > >echo_server.exe run for the first time on win32: echo_client.exe > >has been running successfully since this morning. > > > > > > > That's really great! yeh :) winsock is a pain in the nuts, i can't ctrl-c echo_server.exe because all signals are blocked (in the demo code, there's some #ifdef AIX stuff i just copied that), tcp/ip is going ape, rpcd.exe the endpoint mapper has no file locking, but it's progress. i've made a decision _not_ to focus on fixing the tcp/ip stuff - ncacn_ip_tcp - and instead to jump straight in to creating a ncacn_np and then a ncalrpc transport. i figured that my expertise is _not_ in fixing friggin winsock: if by the time i've done ncacn_np nobody's picked this up then i'll come back to it. ncacn_np is more important for reactos than ncacn_ip_tcp. l.

Sept. 30, 2005

Re: headless question, and IPC question

by Dmitry Timoshkov

"Mike McCormack" <mike(a)codeweavers.com> wrote: > It looks like the only dependency is from the PostMessageA in > dlls/winsock/async.c #514. > > The windows version of ws2_32.dll does not link to user32.dll however, > it appears to load it on demand. I can see the following strings in it: > > USER32.dll > TranslateMessage > PeekMessageA > PostMessageA > DispatchMessageA > > Seems like it wouldn't be too hard to change the PostMessageA to > LoadLibrary/GetProcAddres. depends.exe shows that ws2_32 has a delay load dependency on user32. We have to move user32 to a delay loaded section as well in our version. -- Dmitry.

Sept. 30, 2005

Re: headless question, and IPC question

by Richard Cohen

Ken Larson wrote: > Well I am actually using a command-line with CL to compile it, but it > was true that I had a WinMain instead of main. > > I've changed the WinMain to main, but this doesn't seem to be the issue. > > The issue appears to be initializing winsock. The following simple main > program, when compiled with CL, and run with wine, requires an X display: > Your minimal winsock program doesn't need X when cross-compiled with mingw, and runs happily using winetty.drv $ i586-mingw32msvc-gcc winsock.c -l wsock32 $ WINEDEBUG=loaddll DISPLAY= ~/wine/wine-20050830/wine ./a.exe ... trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winex11.drv" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system32\\winex11.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system32\\winetty.drv" : builtin $ Richard.

Sept. 30, 2005

Re: headless question, and IPC question

by Mike McCormack

> Remove the call to WSAStartup, and the program requires no X display. > > As I said, I know winsock uses hidden windows handles to do some things, > which is pretty ugly architecturally. However, it seems like it should > be possible to not have a display in this case. any ideas? It looks like the only dependency is from the PostMessageA in dlls/winsock/async.c #514. The windows version of ws2_32.dll does not link to user32.dll however, it appears to load it on demand. I can see the following strings in it: USER32.dll TranslateMessage PeekMessageA PostMessageA DispatchMessageA Seems like it wouldn't be too hard to change the PostMessageA to LoadLibrary/GetProcAddres. Mike

Sept. 30, 2005

Re: headless question, and IPC question

by Ken Larson

Well I am actually using a command-line with CL to compile it, but it was true that I had a WinMain instead of main. I've changed the WinMain to main, but this doesn't seem to be the issue. The issue appears to be initializing winsock. The following simple main program, when compiled with CL, and run with wine, requires an X display: #include <windows.h> #include <winsock.h> int main(int argc, const char *argv[]) { WORD sockVersion; WSADATA wsaData; sockVersion = MAKEWORD(1, 1); WSAStartup(sockVersion, &wsaData); } Remove the call to WSAStartup, and the program requires no X display. As I said, I know winsock uses hidden windows handles to do some things, which is pretty ugly architecturally. However, it seems like it should be possible to not have a display in this case. any ideas? I do like the idea of using winelib and having my wrapper be compiled under linux in winelib, but the proprietary DLL I am using also uses winsock so I would expect to have the same problem. Thanks, Ken Alex Villacís Lasso wrote: > Ken Larson wrote: > >> Alex - >> >> Thanks for the good info. As far as not needing an X server, when I >> try to run my exe under wine without one, I get: >> >> wine: Could not load graphics driver 'x11drv'. >> Make sure that your X server is running and that $DISPLAY is set >> correctly. >> >> but yes, the regedit /? trick works fine. >> >> I wonder if there is something obvious I'm missing in the compilation >> and linking of my EXE? Where might I look to make sure it doesn't >> think it needs a display. >> >> My exe and the wrapped DLL do use sockets and I know that sockets in >> windows often need a window handle to do their thing... >> >> My DLL is a true DLL as far as I know, I currently link to it using >> the accompanying .lib, but I think I could link dynamically to it. >> >> Ken > > It seems that you are using VisualC++ to compile your app. There is a > wizard to create a new application, in which the user can select to > create a "console app", one that runs from main() instead of WinMain(). > Try creating such a skeleton app and running it from Wine. Once you > succeed, you can start adding source files from your previous app into > the skeleton console app. This would be the "blind" way of doing this - > I don't remember much about the options available for creating a console > app out of an arbitrary project in VisualC++. I know for a fact that > console apps run without an X server in Wine, because I have just tested > cl.exe from MS VisualStudio in a raw text console in Linux, after > resolving a missing dll. > > If the above *still* does not solve your problem (even after upgrading > to the latest Wine CVS), you might try using a virtual framebuffer X > server: > > (output of yum xorg-x11-Xvfb): > Name : xorg-x11-Xvfb > Arch : i386 > Version: 6.8.2 > Release: 37.FC4.49.2 > Size : 1.6 M > Repo : updates-released > Summary: A X Windows System virtual framebuffer X server. > Description: > Xvfb (X Virtual Frame Buffer) is an X server that is able to run on > machines with no display hardware and no physical input devices. > Xvfb simulates a dumb framebuffer using virtual memory. Xvfb does > not open any devices, but behaves otherwise as an X display. Xvfb > is normally used for testing servers. > > 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. > > Alex Villacís Lasso > > > >

Sept. 30, 2005

Re: freedce-win32 - progress!

by Jakob Eriksson

Luke Kenneth Casson Leighton wrote: >i am making the "amateur" version of progress: i just had >echo_server.exe run for the first time on win32: echo_client.exe >has been running successfully since this morning. > > That's really great! //Jakob

Sept. 30, 2005

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

by Jakob Eriksson

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. regards, Jakob

Sept. 30, 2005

WWN: Rpm's for Fedora Core 4

by Dieter Komendera

Hi people, I read in the today's Wine Weekly News something about rpms for Fedora Core 4. In august I begann building some for FC 4. I built rpm's for the july and the august version. The rpm's were based on Vincent Beron's. They were downloaded about 700 times from my server. There is also a mirrorserver that also hosts my rpms. In fedoraforums.org just one guy reported a problem with the rpm. They can be downloaded here: http://komi.bluezones.org/wine/fc4/ I'll build also rpms for the coming cvs drop out. In this, I will take care of things I read in the WWN. Any comments, improvements, suggestions are very welcome! Regards, Dieter Komendera

Sept. 30, 2005

Subject: Re: Newsleecher Installer Failing

by josephblack

For information on debugging, these official docs may help http://www.winehq.org/site/docs/wine-devel/debugging http://www.winehq.org/site/docs/wine-devel/index http://wiki.winehq.org/DebuggingTutorials there is an unofficial list of examples from the mailing lists, here. http://wine-wiki.org/index.php/Debugging_Wine if you see or think of something that could be added to the official documents - please send a suggestion to the wine-devel list. -- Joseph Black

Sept. 30, 2005