September 2005 - Wine-Devel

Re: Problem Resolve

by Rob D

At 09:40 AM 9/29/2005, Brian Vincent wrote: >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. <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

Sept. 30, 2005

Re: headless question, and IPC question

by Alex Villacís Lasso

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. 29, 2005

Re: Problem Resolve

by Krzysztof Foltman

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

Sept. 29, 2005

Re: Problem Resolve

by Molle Bestefich

On 9/29/05, Brian Vincent <brian.vincent(a)gmail.com> wrote: > 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? 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 :-/.

Sept. 29, 2005

Re: headless question, and IPC question

by Ken Larson

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 > > > >

Sept. 29, 2005

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

Re: wine/ programs/winedbg/info.c programs/taskmgr ...

by Alexandre Julliard

Vincent Béron <vberon(a)mecano.gme.usherb.ca> 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 julliard(a)winehq.org

Sept. 29, 2005

Re: xcursor and wine

by Vijay Kiran Kamuju

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 <infyquest(a)gmail.com> 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 >

Sept. 29, 2005

Re: FW: Help debugging a problem!

by Marcus Meissner

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

Sept. 29, 2005

headless question, and IPC question

by Ken Larson

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

Sept. 29, 2005

Re: Problem with D3D9 CreateDevice

by Oliver Stieber

--- Mark Hatsell <mark.hatsell(a)btinternet.com> wrote: > "Oliver Stieber" <oliver_stieber(a)yahoo.co.uk> wrote in message > news:20050928194419.37697.qmail(a)web26204.mail.ukl.yahoo.com... > > > > I believe all top level windows should have a valid visual ID. > My application is an MDI application and the Direct3D window is an MDI > child. I have found that the mfctex sample in the DirectX SDK also stops > with this error. > 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. Oliver. > Let me know if you need any further info. > > Thanks > Mark > > > > > > ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Sept. 28, 2005

Re: FW: Help debugging a problem!

by James Hawkins

On 9/28/05, Ann & Jason Edmeades <us(a)edmeades.me.uk> wrote: > > Adding in char temp[8]; before the WNDCLASSEX16 and it still fails > Adding in char temp[9]; and the program starts working... > Adding in char temp[9]; after the WNDCLASSEX16 and it still fails > (Yes, temp is unused...) > > So that would agree heap corruption of some sort > Stack corruption :) > > Next question... how to pin this down. > You can try the method of commenting out large portions of the called code, then sequentially uncommenting function calls. Also, look for variables allocated on the stack (especially strings or arrays) and make sure they never get overwritten. > I've tried the following > > 2. Initialize temp to 0x00's (still works @ 9 and fails @ 8). Then adding an > 'if' statement before the return to query the bytes... > a. If I put a stream of if statements it always works > I wouldn't try this route, adding stack vars or printfs and seeing what makes it not crash that way. The hard thing about stack or heap corruption is that it's seemingly random and can crash at any point (more or less). I would focus on finding which variable is being overwritten. -- James Hawkins

Sept. 28, 2005

Re: winehq at the CIA Open Source Notification System

by Mike Hearn

I ceased running the gateway some time ago. Newman was going to move it to a CodeWeavers box but never did. At some point I shall try restoring service. On Sun, 18 Sep 2005 16:32:27 +0200, Detlef Riekenberg wrote: > Hi. > > There are no updates listed for wine at the CIA Open Source Notification > System: > > http://cia.navi.cx/stats/project/winehq > > > Is this our fault?

Sept. 28, 2005

FW: Help debugging a problem!

by Ann & Jason Edmeades

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; } This fails for the application as it stands. Adding in char temp[8]; before the WNDCLASSEX16 and it still fails Adding in char temp[9]; and the program starts working... Adding in char temp[9]; after the WNDCLASSEX16 and it still fails (Yes, temp is unused...) So that would agree heap corruption of some sort Next question... how to pin this down. 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) - registers are nearly identical, only difference is ESI after 2. Initialize temp to 0x00's (still works @ 9 and fails @ 8). Then adding an 'if' statement before the return to query the bytes... a. If I put a stream of if statements it always works b. If I put a single statement it works(a)9 / fails(a)8. Manually, I have confirmed chars 0->11 are not touched (3 longs). c. I changed temp to be 8192 in size, memset it to 0x00 and then post call checked each byte to see if it had changed - it hadn't, they were all still 0x00 => I don't think the actual values are important, size matters (so they say!) 3. I recompiled user.c with -O0 and got different results. With char temp; in it works, with it removed it fails! 4. I compared the assembler output produced with temp[8] and temp[9] and as expected they are identical except for some offsets in that routine. ARGH... Advice please.... Anyone... Jason

Sept. 28, 2005

Re: Problem with D3D9 CreateDevice

by Mark Hatsell

"Karsten Elfenbein" <elfe-sysmail(a)elfe.mine.nu> wrote in message news:004c01c5c453$02755220$6e080a0a(a)elfe1... > > Could you tell us what app/game you are trying to run. (trail/demo > available?) > I have a game (Eve Online) that fails while detecting the direct modes. > http://bugs.winehq.org/show_bug.cgi?id=3157 It is an app I have written myself for plotting 2D/3D graphs etc. Mark

Sept. 28, 2005

Re: Problem with D3D9 CreateDevice

by Mark Hatsell

"Oliver Stieber" <oliver_stieber(a)yahoo.co.uk> wrote in message news:20050928194419.37697.qmail(a)web26204.mail.ukl.yahoo.com... > > I believe all top level windows should have a valid visual ID. > > Can you tell me what your passing in as the creation parameters, if your > creating a window and > using it's HWND when creating a device or expecting DirectX 9 to create > the device for you, and if > your application is MDI or not. The window is created prior to the CreateDevice call but is not yet shown. It has the following Window Styles and Extended Styles: WS_CAPTION WS_CHILDWINDOW WS_VISIBLE WS_CLIPSIBLINGS WS_CLIPCHILDREN WS_SYSMENU WS_THICKFRAME WS_MINIMIZEBOX WS_MAXIMIZEBOX WS_EX_LEFT WS_EX_LTRREADING WS_EX_RIGHTSCOLLBAR WS_EX_MDICHILD WS_EX_WINDOWEDGE My application is an MDI application and the Direct3D window is an MDI child. I have found that the mfctex sample in the DirectX SDK also stops with this error. Let me know if you need any further info. Thanks Mark

Sept. 28, 2005