September 2005 - Wine-Devel

Re: MS VisualBasic apps have no minimize/maximise buttons, no taskbar button - RFC, help debugging

by Alex Villacís Lasso

Dmitry Timoshkov wrote: >"Alex Villacís Lasso" <a_villacis(a)palosanto.com> wrote: > > > >>The following is a problem I have been having with every single >>VisualBasic application for some time, and I ask for your help now: >> >>Every single VisualBasic application I have tried lacks the minimize and >>maximize buttons, even when the application is supposed to have them. In >>addition, the taskbar button is missing (on Gnome 1.4.x/Metacity 2.10.3 >>under Fedora 4), so there is no way to recall the application once the >>window is obscured by another application, except by clearing the >>desktop. The applications show the buttons on the virtual desktop, and >>the problem arises only when the application uses the window manager for >>its own window. This problem was confirmed on Metacity and MWM. >> >> > >Please open a bug in bugzilla, attach simple VB app to it and assign it to me, >once I have some free time I'll have a look at it. > >-- >Dmitry. > > > > This problem is also experienced with Delphi applications, it is not new, and it still exists as of current CVS (2005-09-29): http://bugs.winehq.org/show_bug.cgi?id=1598 I have uploaded the sample VB app there as an additional testcase for this bug. However, it seems that I am unable to assign the bug to you, since I did not create the bug report. Alex Villacís Lasso

Sept. 29, 2005

Re: headless question, and IPC question

by Alex Villacís Lasso

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 > winelib because I don't have the source to the DLL. > > Thanks, > > Ken Larson > > > If your program is a console-only app, it can run without an X server. For example, the command "regedit /?" works without defining a DISPLAY variable, even in a text console. If you write interesting information to a logfile instead of the screen, you could even do "wine wrapper.exe &" on the shell and put your app in the background. About winelib, you could try making a winelib app that loads the DLL dynamically. But this would only work for a true DLL (for example "propietary.dll") on which you can call LoadLibrary(). If your library is a static one such as "propietary.lib", with no companion DLL file to load, then all the interesting code is in the LIB file itself and cannot be loaded dynamically. About faster communication, you could try running the Linux app, which would fork(). One process runs your GUI or sets up your service, and the other could then exec() the winelib wrapper. Before the fork, you should set up a pair of pipes, or use socketpair() for communication. If you are careful, this can even work for a pure Windows app linked with a static LIB file, by connecting your pipe/socket to the stdin/stdout of the wine process (see the manpage on dup2() for details). Hope this helps. Alex Villacís Lasso

Sept. 29, 2005

Re: Problem Resolve

by Brian Vincent

On 9/29/05, Molle Bestefich <molle.bestefich(a)gmail.com> wrote: > That said, it seems a bit rude that the 20050830 CVS drop is *still* > on the front page of http://www.winehq.com/, even after everyone knows > that it's missing a patch to compile cleanly. > > Why not just add the patch to the package and slap it up as '20050830-1' ? > Or add a link to the bugzilla entry to the front page ? 1. Adding the Bugzilla entry as a news item is a good idea. However, we're possibly close to a September drop, so at this point it's probably easiest to just wait for that. I'm very open to adding news items to the front page, so definitely feel free to drop me an email when you think of things like that. How about WWN coverage instead? 2. CVS drops are just that - drops. They haven't been compiled on a bizillion systems or tested with real-world applications to ensure things aren't massively broken. Furthermore, no work was done to stabilize the release other than normal bug fixes. Instead, it represents a point in time where Alexandre ran the regression tests, things worked for him, and a tarball was made. There was discussion of that process changing after a beta release is made. 3. Binary packages are highly recommended unless you prefer to muck around occasionally with source code. That probably doesn't apply to you since you're reading wine-devel, but for 99% of the people in the world they should use the binaries. In theory we'll catch things at that point. -Brian

Sept. 29, 2005

Re: Problem Resolve

by Molle Bestefich

Molle Bestefich wrote: > Molle Bestefich wrote: > > j0zue(a)o2.pl wrote: > > > I had a problem with Wine20050830 compilation. > > > Error: error parse before "BerElement"; > > > > This question has been asked and answered a couple of times now. > > > > GMANE search: > > http://search.gmane.org/?group=gmane.comp.emulators.wine.user&query=BerElem… > > (USERS list, try first) > > http://search.gmane.org/?group=gmane.comp.emulators.wine.devel&query=BerEle… > > (DEVEL list) > > > > To view an entire thread in GMANE, after clicking the search result, > > click the 'Subject' link. > > Actually, your problem is in the Wine Bugs database too: > http://bugs.winehq.org/query.cgi > > The interface is absolutely horrid though, at least if you're a > bugzilla newbie or if you're searching for known bugs..: > > After typing 'BerElement' in the freetext field, you have to check all > of the items in the 'Status' field to make the search return anything. That said, it seems a bit rude that the 20050830 CVS drop is *still* on the front page of http://www.winehq.com/, even after everyone knows that it's missing a patch to compile cleanly. Why not just add the patch to the package and slap it up as '20050830-1' ? Or add a link to the bugzilla entry to the front page ?

Sept. 29, 2005

Re: wine/ programs/Makeprog.rules.in include/wine/ ...

by Dimi Paun

> Declare debug channels as static variables so that we > don't need to generate an external .dbg.c file to define them. Way cool, thanks for fixing this, it was really bothering me that we had that additional pass over the source... I think our toolchain looks pretty good now! -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 29, 2005

Re: Unused function in regedit/treeview.c

by Krzysztof Foltman

> If that function is supposed to be useful, then scream or re-add it > later. Re-adding would be a good idea. I thought it will be useful for finding an item in the tree, but then managed to do the same without using it. --- Krzysztof

Sept. 29, 2005

Re: FW: Help debugging a problem!

by Rein Klazes

On Wed, 28 Sep 2005 23:53:28 +0100, you wrote: >I've tried the following > >1. Use DebugBreak before and after the RegisterClassEx16 call with no temp >defined >- Stacks are identical as far as winedbg traces (0x60 bytes) Hi Jason, This winedbg stack trace (info stack) is equivalent to the examine command: x /24x $esp (24 words == 0x60 bytes). Change the repeat count from 24 to what you want. If there is a stack corruption, this way you can find out where and then you can add a watch point on it. Rein.

Sept. 29, 2005

Re: winspool/tests: New Testsuite

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > Changelog: > - New Testsuite for winspool.drv for > GetPrinterDriverDirectoryA and > GetDefaultPrinterA Please try to follow the model of other test programs, don't define a whole new environment for yourself. Most of the stuff you do here is unnecessary, or downright wrong, notably the version checks. -- Alexandre Julliard julliard(a)winehq.org

Sept. 29, 2005

freedce-win32 - progress!

by Luke Kenneth Casson Leighton

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. rpcd.exe - the endpoint mapper - just crashed :) hmmm... recv_state_timer is indicating Ping timeout, sending "Orphan timeout", and then bombing out... hmmm... this despite echo_server.exe happily running. i don't really know enough to say what's going on here - other than to consider quite cheerfully disabling the ping rpc timer code with a _huge_ manic grin on my face :) i have had to disable TCP (ncacn_ip_tcp) for now, and will try that next. i've refrained from notifying wine-devel of status reports until i actually had something working. for your benefit: * i am using pthreads-win32, from sourceware.org, with pthread_self.c patched to set sp->implicit = 0 instead of 1. this gets the dcethreads test programs to work: whether this is a good thing remains to be seen... * i have removed the awfulness that is linux-specific (system call wrapping) which previously made dcethreads non-portable to win32: instead, you now must #define sys_pthread_create pthd4_create because dcethreads provides pthd4_xxx. * the dcethreads exception emulation library still uses setjmp and longjmp and to my surprise and horror it actually works. * i have tracked down an implementation of gettimeofday, and liberally sprinkled it across the code, statically, instead of providing a nice library routine * i have provided a win32_winsock.c "wrapper" set of code to divorce the #including of <windows.h> and <winsock.h> from everything else. no, it is _not_ appropriate to put #include <windows.h> in the freedce header files. there are too many conflicts for that to be suitable. HANDLE, handle_t, UUID, uuid_t rpc_binding_t ain't the half of it. * i could not be arsed to write yet another version of uuid_create() and the uuid_create() function in freedce conforms to the RFC - grabs networking MAC address etc. etc. therefore, rather than rip wine code from UuidCreate(), i decided to call UuidCreate() - via a wrapper function. this _could_ therefore get interesting, if someone decides to make rpcrt4.dll utilise uuid_create() ... :) * i have NOT done any proper file locking stuff - yet - in rpcd.exe. there's a database that really needs to be locked: i aim to grab APR's apr_open(), apr_flock() etc. etc. and utilise those because i _so_ cannot be bothered to reinvent the wheel. wine-devel team: you now have a partially-working and therefore proof-of-concept port of freedce to win32. there are many next steps that can be taken from here. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

Sept. 29, 2005

Re: Problem with D3D9 CreateDevice

by Mark Hatsell

"Oliver Stieber" <oliver_stieber(a)yahoo.co.uk> wrote in message news:20050928232524.85003.qmail(a)web26205.mail.ukl.yahoo.com... > > MDI was updated a few months ago, one of the results is that MDI no longer > works for Direct3D > applications. Fixing MDI for Direct3D is on my TODO list. I think the error occurs when Direct3D is used in any child (non-top level) window, not just MDI child windows. I say this since the mfctex sample is not an MDI application and the same problem exists. However, the Direct3D window is a child of the main application window. I'll keep my eyes peeled for a patch. Thanks Mark

Sept. 29, 2005