Re: FW: Help debugging a problem!
On Wed, Sep 28, 2005 at 11:53:28PM +0100, Ann Jason Edmeades wrote:
Ok, more information...
The routine (slightly modified to allow code before the return) is
ATOM WINAPI RegisterClass16( const WNDCLASS16 *wc )
{
WNDCLASSEX16 wcex;
ATOM fred;
wcex.cbSize= sizeof(wcex);
:
fred = RegisterClassEx16( wcex );
return fred;
}
Advice please Anyone...
I think the passed class has cbClsExtra extrabytes set and used.
In this case you need to allocate more bytes then just WNDCLASSEX16 and
also copy the extra bytes.
So I guess this function is broken a bit.
This is just a guess, I might be wrong.
Ciao, Marcus
Re: xcursor and wine
Hi, I just started on writing support for Xcursor, i dont know about the configure stuff and all that. So i wrote a small xcursor.c file to be in the dlls/x11drv/ directory. could any body please tell me how to proceed further. And also i would like to wite another utility function to convert the BITMAPINFO into XcursorImage Thanks, Vijay On 9/27/05, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: Hi all, I any body wants tp implement Xcursor support in wine, for loading color cursors. What should be implemented, how it should be implemented? any details regarding this would be helpful. Thanks, Vijay xcursor.c Description: Binary data
Re: wine/ programs/winedbg/info.c programs/taskmgr ...
Vincent Béron [EMAIL PROTECTED] writes: This patch causes compilation with gcc 3.2 to issue some warnings about null format strings whenever a TRACE_ON() (or other) is used. I know there's a check in wine_dbg_log() for !format, but the warning is still annoying. I guess you don't want an empty line (except for type and class) to be printed everytime TRACE_ON is tested, so changing the 0 for wouldn't work out ok... It would, except gcc 4.0 prints a warning for a format string... I guess I'll have to export another function just for that purpose. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Problem with D3D9 CreateDevice
Oliver Stieber [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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
freedce-win32 - progress!
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 --
Re: FW: Help debugging a problem!
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.
Re: winspool/tests: New Testsuite
Detlef Riekenberg [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Unused function in regedit/treeview.c
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
headless question, and IPC question
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
Re: wine/ programs/Makeprog.rules.in include/wine/ ...
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 [EMAIL PROTECTED] Lattica, Inc.
Re: Problem Resolve
Molle Bestefich wrote: Molle Bestefich wrote: [EMAIL PROTECTED] 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.userquery=BerElement (USERS list, try first) http://search.gmane.org/?group=gmane.comp.emulators.wine.develquery=BerElement (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 ?
Re: Problem Resolve
On 9/29/05, Molle Bestefich [EMAIL PROTECTED] 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
Re: headless question, and IPC question
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
Re: MS VisualBasic apps have no minimize/maximise buttons, no taskbar button - RFC, help debugging
Dmitry Timoshkov wrote: Alex Villacís Lasso [EMAIL PROTECTED] 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
Re: headless question, and IPC question
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 Alex Villacís Lasso wrote: 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
Re: Problem Resolve
On 9/29/05, Brian Vincent [EMAIL PROTECTED] wrote: On 9/29/05, Molle Bestefich [EMAIL PROTECTED] 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? Depends.. Is the CVS drop distributed through other channels than the winehq front page? If not, and that one's going away in two days, then it's probably not worth it.. I'd be happy to write up a few lines for WWN if you want something in there (albeit my english does suck, so beware :-)). 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. Thanks for the clarifications. I'm super newbie so I don't know how these things work - sorry! Just thought I'd point it out since it seemed noone else had :-/.
Re: Problem Resolve
Molle Bestefich wrote: If not, and that one's going away in two days, then it's probably not worth it.. Well, assuming that nobody cares about the hundreds of (potential) users put off during those two days :-) Isn't it possible to post a previous version or remove it completely? Is it lots of work, or something rather easy? (the question is genuine, I don't know anything about insides of Wine release process) Krzysztof
Re: headless question, and IPC question
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
Re: Problem Resolve
At 09:40 AM 9/29/2005, Brian Vincent wrote: On 9/29/05, Molle Bestefich [EMAIL PROTECTED] 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. snip Are you referring to a multiple defined struct option in winedump? I spent quite a while trying to compile this drop on Solaris 9 this morning. The multiple defined struct was easy to find/fix, but assembler having BIG troubles. Pretty sure it is using gas, since I renamed as and made a symlink to gas. /snip 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 If I could find a Solaris 9 binary of ANY wine version in the last year or so, I would be VERY happy!!! Google found a couple links to Solaris 9 binaries a couple years old or so, but the link didnt even work. Rob D
