September 2005 - Wine-Devel

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