September 2005 - Wine-Devel

Re: IDE disk geometry

by Michael Ost

On Tue, 2005-09-20 at 18:22, Vitaliy Margolen wrote: > Tuesday, September 20, 2005, 6:11:49 PM, Michael Ost wrote: > > Should I put my code in CDROM_DeviceIoControl? Or handle it in > > NtDeviceIoControlFile? Should I pass all other IoControlCodes except > > IOCTL_DISK_DRIVE_GET_GEOMETRY for a verifiable IDE drive on to the > > CDROM_... function? > I don't it make any sense to create the whole new file to parse just one IOCTL. > So you might just add it to the cdrom.c I think that might get accepted. I don't think it was clear that the device in question is not a CDROM, but a hard disk. Are IDE hard disks supposed to be lumped in with CDROMs in the code? > But before you go too far, pleas look at kernel/oldconfig.c. It does some > parsing of /proc already. So all you need to do is to find where this > information is stored on windows (it has to be somewhere in registry) and add to > that. Then you don't need to parse /proc all the time but just read info from > the registry. One possible option would be to use IOCTL_SCSI_GET_INQUIRY_DATA to OK. That's a good idea, except that in the Wine version my company is using there is no oldconfig.c. So for our version I guess I would patch dlls/ntdll/cdrom.c by reading out of proc directly. But I would submit a version that stores disk geometry in the registry. I'll look in to that. Thanks for the feedback... mo

Sept. 21, 2005

Re: Documentation volunteer(s) needed

by Dimi Paun

On Tue, 2005-09-20 at 23:30 +0200, Holly Bostick wrote: > But in any case, I'm having another problem somewhat more relevant-- > the docs don't compile as html for me: It should be fixed now, just get the latest version. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 21, 2005

Re: listview: infoPtr might be invalid after WM_NOTIFY

by Dimi Paun

On Wed, 2005-09-21 at 00:11 +0200, Lionel Ulmer wrote: > Correct me if I am wrong (I know absolutely nothing about how the > listview code works) but a flaw of the 'exception based' solution > would be if the application allocated memory that would re-use the > just freed memory pointed by 'infoPtr'. This is true only if we rely on the access violation exception (which is a possibility, I admit). But the test patch that I sent checked the hwnd after each notify message with IsWindow(), and if invalid it was throwing a custom exception. So no, it does not suffer from the flaw that you mentioned. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 21, 2005

freedce/win32 - making progress.

by Luke Kenneth Casson Leighton

okay, i'm getting somewhere, and there's a key part that i would appreciate some advice about: if there is anyone who knows how to do cross-compiling of dlls using libtool, mingw32 (in automake Makefile.am's) where the dlls need to link against _other_ libraries, i would love to hear from you. if you know of a better place to ask questions such as these, i would also appreciate some advice on where i should ask them. [please respond cc direct because although i am subscribed to the wine-devel list i have "receive postings" switched off because i haven't sufficient time any more to sort or delete hundreds of messages per day like i used to have. ] there are about eight libraries containing a function rpc__module_init_func() and these need to be LoadLibrary'd and GetProcAddress'd and called... ... but in endeavouring to create dlls, i am getting mad warnings from libtool about a) static libraries containing unresolved functions therefore libtool says it _could_ link against the library you requested, but only if you made a dynamic version and b) unresolved symbols for functions in other libraries, and it's all a bit of a vicious circle and i'd rather not bash my head against a brick wall for days on this. if this issue cannot be resolved then there are a number of nasty options remaining: 1) statically link binaries against the libraries, with hard-coded module init functions (which is what i'm doing now and i link against libnaf_ip.la, libcom.la, libprot_ncacn.la, libprot_ncadg.la, the list goes on and you have to do that for EVERY client AND server program) 2) abandon automake, work out how to manually create dlls. yes i know about .def files but libtool appears unconvinced. neither of these two is attractive options. anyway: what i have working so far can be found at the freedce-devel sf.net mailing list archives, and as of today, rpcd (the endpoint mapper on port 135) works. and also when i add a NamedPipes transport (ncacn_np) it will be on \PIPE\epmapper, too. that'll be a fun job. no, really! tomorrow's job is to link the echo_server and test that, and if that works, try the echo_client too. if those work, then the free software community will have its own DCE/RPC reference implementation running on win32. much damn good may it do, i am sure. l. p.s. thank goodness for pthreads-win32. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

Sept. 21, 2005

Re: XEmbed Systray Support

by James Liggett

Aside from the bugs I've mentioned before, it doesn't seem that the implementation of this works quite right. This patch should address the bugs in dlls/shell32/systray.c, not just the docking. I've fixed most things, but there is still one big problem. There's a window cleanup problem where the first Wine-systray window doesn't get cleaned up properly, and so some problems crop up. If you have more than one tray icon, they'll work fine at first. But, exit your programs and start up another app that uses systray, the first icon won't dock at all, but subsequent ones will. In short, this patch isn't really ready for CVS until things get cleaned up and fixed. James On Tue, 2005-09-20 at 18:07 -0500, Robert Shearman wrote: > Robert Shearman wrote: > > > Hi, > > > > This patch allows new non-KDE systems to display notification area > > icons for Win32 apps in the window manager's system tray, instead of > > in a 16x16 top-level window. > > > > Changelog: > > Support XEmbed protocol for system tray windows. > > > Anything wrong with this patch? >

Sept. 21, 2005

Re: XEmbed systray patch bugs

by James Liggett

Ok that's good. I've been looking through the systray code myself, and its quite messy... Have fun! ;-) James On Tue, 2005-09-20 at 16:23 -0500, Robert Shearman wrote: > James Liggett wrote: > > >1. The "Wine-Systray" window is still showing up. I've been able to fix > >this by getting rid of the WS_VISIBLE style when creating the window in > >systray.c, and then manually showing the window after it's been docked. > > > > > > This is just a bug with the existing systray code and something I can > fix with a separate patch to dlls/shell32/systray.c. > > >2. The rightmost edges of systray icons are cut off. The previous fix > >seemed to work for this problem too. I think it has something to do with > >painting/updating the embedded window. > > > > > > Same again. >

Sept. 21, 2005

Re: IDE disk geometry

by Vitaliy Margolen

Tuesday, September 20, 2005, 6:11:49 PM, Michael Ost wrote: > Any suggestions for a good "wineish" way to implement an IOCTL_ call for > an IDE disk? Use SCSI ioctls I think they should work on IDE drives as well. > I have some code that reads geometry information out of > /proc/ide/hd?/geometry that is working fine. But I am not sure how to > integrate it into ntdll. This is not portable. Does it really need to know geometry? Could you just tell it some fake stuff? > Should I put my code in CDROM_DeviceIoControl? Or handle it in > NtDeviceIoControlFile? Should I pass all other IoControlCodes except > IOCTL_DISK_DRIVE_GET_GEOMETRY for a verifiable IDE drive on to the > CDROM_... function? I don't it make any sense to create the whole new file to parse just one IOCTL. So you might just add it to the cdrom.c I think that might get accepted. > Thanks for any help. Patch against wine-20050419 is attached for > illustrative purposes. ... mo No this will not work. You can't add your function at front of what's there. This will slow down and add unnecessary fixmis. For onw IOCTL you might as well put into the cdrom.c But before you go too far, pleas look at kernel/oldconfig.c. It does some parsing of /proc already. So all you need to do is to find where this information is stored on windows (it has to be somewhere in registry) and add to that. Then you don't need to parse /proc all the time but just read info from the registry. One possible option would be to use IOCTL_SCSI_GET_INQUIRY_DATA to get the hdd info. I think it does work on IDE HDDs. And as I remember it has the info you need. And also all that info stored in registry as well. Vitaliy

Sept. 21, 2005

IDE disk geometry

by Michael Ost

Any suggestions for a good "wineish" way to implement an IOCTL_ call for an IDE disk? My winelib app is hosting a Windows DLL that is making an IOCTL_DISK_DRIVE_GET_GEOMETRY call on an IDE hard disk. ntdll/file.c NtDeviceIoControlFile is passing this off to ntdll/cdrom.c CDROM_DeviceIoControl and, of course, since it is not a cdrom disk, that fails. I have some code that reads geometry information out of /proc/ide/hd?/geometry that is working fine. But I am not sure how to integrate it into ntdll. Should I put my code in CDROM_DeviceIoControl? Or handle it in NtDeviceIoControlFile? Should I pass all other IoControlCodes except IOCTL_DISK_DRIVE_GET_GEOMETRY for a verifiable IDE drive on to the CDROM_... function? If anyone has a background in this code, you probably have an idea straight off how best to fit it in. Thanks for any help. Patch against wine-20050419 is attached for illustrative purposes. ... mo

Sept. 21, 2005

Re: Documentation volunteer(s) needed

by Oliver Stieber

--- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hello, > > > You need to turn on backbuffers / backingstore in your xf86config and those > > two functions were reasonable fast (so long as you don't play mess around > > with the transfer modes) older driver (can't renember which version) > Does this still work with newer drivers? 8.16.20 for example? It doesn't work > for me. > (I don't understand this clearly from your sentence.) > It stopped working a few driver versions ago gentoo only goes back as far as 8.14.13 and I don't have a copy of any older drivers kicking around., I've sent a bug report to ATI, I hoped they'ed fixed it as part of their performance improvements in 8.16.20 but apparently not. > > I've got a hack to go into wined3d that speeds up locking the backbuffer by > > not bothering to read it if it's just been cleared, this get's movies using > > DirectX and backbuffer locking up to a good frame rate with low CPU usage. > That's exactly the problem I have! I expect it to occur too when Empire Earth > finally runs. Can you send me your hack? I'd like to try it with D3D7. I'm just about to put it into wined3d, I can have a look at backporting it to d3d7 but the idea is to get d3d7 using wined3d at some point. All you have to do is flag the backbuffer when it's cleared as cleared, and then at the end of a drawing function flag the backbuffer as not cleared. Then when you lock the backbuffer check the flag and if it's flagged as cleared just memset the buffer to whatever the clear value is instead of doing a glReadPixels (most of the time you don't need the memset because the buffer is going to be completely rewritten, on my home pc without the hack I get about 10fps max with 100% CPU load, with the hack I get 30fps with about 30% CPU load) > > Another question: I've hit a problem where fglrx crashes on glBegin(GL_*) when > GL_TEXTURE_2D is enabled. Any experiance / hints? > Hmm.. I haven't had any problems with that yet, so long as I'm actually using GL_TEXTURE_2D and providing texture coordinates, in wined3d I disable any texture states that aren't used: for (i = 0; i< GL_LIMITS(textures); ++i) { /* Bind the texture to the stage here */ if (GL_SUPPORT(ARB_MULTITEXTURE)) { GLACTIVETEXTURE(i); } glDisable(GL_TEXTURE_1D); switch(This->stateBlock->textureDimensions[i]) { case GL_TEXTURE_2D: glDisable(GL_TEXTURE_3D); glDisable(GL_TEXTURE_CUBE_MAP_ARB); break; case GL_TEXTURE_3D: glDisable(GL_TEXTURE_CUBE_MAP_ARB); glDisable(GL_TEXTURE_2D); break; case GLTEXTURECUBEMAP: glDisable(GL_TEXTURE_2D); glDisable(GL_TEXTURE_3D); break; > Thanks for this hint, it looks like you saved me from doing a time-intensive > investigation! > > Stefan > > > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Sept. 20, 2005

Re: Documentation volunteer(s) needed

by Brian Vincent

On 9/20/05, Kuba Ober <kuba(a)mareimbrium.org> wrote: > Wouldn't such a book be mostly obsolete within a year of publication? That's > almost like with those linux kernel development books: in 2 years timeframe > they are mostly paperweights, unless you're interested only in 'big ideas' > rather than details. Well, that's one of the things I wrestle with. Some of the stuff is just cool ideas that won't get outdated any time soon. Some of it will get outdated... and then the publisher can pay me for the second addition. Holly - I should also mention that you'll want to make sure you have well-formed SGML when you write the docs, i.e. all opening tags must have a closing tag. I find xmllint and tidy are very helpful for that. tidy has easier output to understand, xmllint seems to be pretty standard on distros these days. -Brian

Sept. 20, 2005

Re: XEmbed Systray Support

by Robert Shearman

Robert Shearman wrote: > Hi, > > This patch allows new non-KDE systems to display notification area > icons for Win32 apps in the window manager's system tray, instead of > in a 16x16 top-level window. > > Changelog: > Support XEmbed protocol for system tray windows. Anything wrong with this patch? -- Rob Shearman

Sept. 20, 2005

Re: Windows CE on Wine

by Steven Edwards

Hi, On 9/20/05, Filip Navara <navaraf(a)reactos.com> wrote: > We have already made this experiment once ... you can find info about it > in the ros-dev (or ros-kernel) mailing list archives and skeletons of > the two WinCE DLLs in the ReactOS SVN history > (trunk/reactos/lib/commctrl and trunk/reactos/lib/coredll ... revision > ~14000). It was proved that to run simple WinCE/x86 programs all that is > needed is to get the loader to accept the WinCE PE signature (which Wine > used to ignore and probably still does) and have implementation of the > DLLs... I had to flip the subsystem ID of a WinCE test app using one of the msvc build tools. My sample application just called a message box api. I don't know if any more complex WinCE applications would work due to threading and memory management differences. Thanks Steven

Sept. 20, 2005

Re: [wined3d] state management for vertex shader constants

by Ivan Gyurdiev

>+ for (j = 0; j < GL_LIMITS(textures); i++) { >+ for (i = 0; i < NUM_SAVEDPIXELSTATES_T; i++) { >+ object->changed.textureState[j][SavedPixelStates_T[i]] = TRUE; >+ } >+ } > > This looks like a loop counter bug... >+ for (j = 0; j < GL_LIMITS(textures); i++) { >+ for (i = 0; i < NUM_SAVEDVERTEXSTATES_T; i++) { >+ object->changed.textureState[j][SavedVertexStates_T[i]] = TRUE; >+ } >+ } > > Same...

Sept. 20, 2005

Re: listview: infoPtr might be invalid after WM_NOTIFY

by Lionel Ulmer

On Tue, Sep 20, 2005 at 11:51:00AM -0400, Dimi Paun wrote: > I personally think an exception-based solution would be better. > This is what exceptions where invented. (...) Correct me if I am wrong (I know absolutely nothing about how the listview code works) but a flaw of the 'exception based' solution would be if the application allocated memory that would re-use the just freed memory pointed by 'infoPtr'. This would mean that no exception would be triggered while the code would still be wrong as it would write / read something that is clearly not what it expects. Now one could say that knowing the heap allocation algorithms this case should never happen, but well, better safe than sorry. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Sept. 20, 2005

Re: Documentation volunteer(s) needed

by Lionel Ulmer

On Tue, Sep 20, 2005 at 10:56:41PM +0200, Stefan Dösinger wrote: > That's exactly the problem I have! I expect it to occur too when Empire Earth > finally runs. Can you send me your hack? I'd like to try it with D3D7. If the game is well behaved, this optimisation should already be present in the D3D7 code (i.e. if the surface is locked 'write only', do not bother to read the buffer from the card). Alas most games are not well behaved and always lock in R/W mode :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Sept. 20, 2005

Re: Documentation volunteer(s) needed

by Holly Bostick

Oliver Stieber schreef: > --- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > >> Hello, >> >>> Oh yeah, another question-- are we making provision for 'special >>> circumstances'? I've got an ATI card, which makes me sensitive to >>> such things, since the ATI drivers fail to do many things that >>> they should, and often additional provisions need to be made >>> specifically to get an app or game to run with the stupid fglrx >>> drivers, where no such config workarounds need to be used with >>> nVidia cards, or so I've heard. Or does that just fall under >>> 'Troubleshooting'? Or does Wine not need such workarounds at all >>> (unlike Cedega)? >> >> There are for sure some cases where fglrx-specific problems exist. >> I am hunting two problems with this driver. One thing is that >> glTexSubImage2D() and glReadPixels() are HORRIBLY slow, another one >> is a crash in the fglrx driver somehow related to textures. >> >> Maybe I can solve these 2 in time, so you don't have to write about >> them ;-) >> > > You need to turn on backbuffers / backingstore in your xf86config and > those two functions were reasonable fast (so long as you don't play > mess around with the transfer modes) older driver (can't renember > which version) > > Section "Device" Identifier "ATI Graphics > Adapter" Driver "fglrx" ... # Backing > store increases performance when locking the backbuffer Option > "backingstore" "true" ... EndSection > > I've got a hack to go into wined3d that speeds up locking the > backbuffer by not bothering to read it if it's just been cleared, > this get's movies using DirectX and backbuffer locking up to a good > frame rate with low CPU usage. > Thank you, Oliver and Stefan! I've changed my config (this option did appear but was not only commented out, but in the wrong place in the file, as well as having no value of either true or false). And my impression is that it being commented is the default setting, but I'm not sure about that. I haven't restarted X yet, but it's good to know that this setting has some function (that's why I think it's commented by default; I certainly never knew what it did, so I most likely never messed with it), so it can certainly go into my collection of 'miscellaneous technical notes that might be useful'. I hope that it won't be necessary to go into the docs, but you never know what users might do (if the problems that come up on the user list are any guide), what Wine they might be using, on what even-less-supported-than-my-9800SE card (I'm thinking the Mobility users, and the X*00 users) they might have on their systems. So any and every little bit of info might be useful to somebody. Assuming of course that if you successfully hunt down the issue and tell the ATI team, they don't fix it themselves (which would be lovely, wouldn't it?). Would save us all a lot of work.... Holly

Sept. 20, 2005

Re: Documentation volunteer(s) needed

by Holly Bostick

Tom Wickline schreef: > On 9/20/05, Holly Bostick <motub(a)planet.nl> wrote: > >> Oh yeah, another question-- are we making provision for 'special >> circumstances'? I've got an ATI card, which makes me sensitive to >> such things, since the ATI drivers fail to do many things that they >> should, and often additional provisions need to be made >> specifically to get an app or game to run with the stupid fglrx >> drivers, where no such config workarounds need to be used with >> nVidia cards, or so I've heard. Or does that just fall under >> 'Troubleshooting'? Or does Wine not need such workarounds at all >> (unlike Cedega)? > > > IMHO.... Cedega should not even remotely be in the equation, the > documentation is about Wine and only Wine. The folks at TG can write > docs for Cedega as CW writes docs for CrossOver. So please don't > reference Cedega in the docs. > > Tom > No, I had no intention of doing so, and the reference to Cedega was peripheral to my question. It is only referenced at all because that is how I learn to understand things, by triangulation between points. But in any case, I'm having another problem somewhat more relevant-- the docs don't compile as html for me: ./configure; make checking whether make sets $(MAKE)... yes checking for docbook2html... docbook2html checking for docbook2pdf... docbook2pdf checking for docbook2ps... docbook2ps checking for docbook2txt... docbook2txt checking for nsgmls... nsgmls configure: creating ./config.status config.status: creating Make.rules config.status: creating Makefile config.status: creating en/Makefile config.status: creating fr/Makefile Configure finished. Do 'make' to compile the documentation. make[1]: Entering directory `/usr/local/src/docs/en' docbook2html -u winedev-guide.sgml Using catalogs: /etc/sgml/sgml-docbook-3.1.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on: /usr/local/src/docs/en/winedev-guide.sgml Done. docbook2html -u wineusr-guide.sgml Using catalogs: /etc/sgml/sgml-docbook-3.1.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on: /usr/local/src/docs/en/wineusr-guide.sgml Done. docbook2html -u winelib-guide.sgml Using catalogs: /etc/sgml/sgml-docbook-3.1.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on: /usr/local/src/docs/en/winelib-guide.sgml Done. docbook2html -u wine-faq.sgml Using catalogs: /etc/sgml/sgml-docbook-3.1.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on: /usr/local/src/docs/en/wine-faq.sgml jade:/usr/local/src/docs/en/wine-faq.sgml:1611:13:E: document type does not allow element "PARA" here; missing one of "FOOTNOTE", "MSGTEXT", "CAUTION", "IMPORTANT", "NOTE", "TIP", "WARNING", "BLOCKQUOTE", "INFORMALEXAMPLE" start-tag jade:/usr/local/src/docs/en/wine-faq.sgml:1616:14:E: end tag for "PARA" omitted, but OMITTAG NO was specified jade:/usr/local/src/docs/en/wine-faq.sgml:1602:8: start tag was here jade:/usr/local/src/docs/en/wine-faq.sgml:1737:21:E: non SGML character number 132 jade:/usr/local/src/docs/en/wine-faq.sgml:1738:84:E: non SGML character number 132 make[1]: *** [wine-faq.html] Fout 8 make[1]: Leaving directory `/usr/local/src/docs/en' make: *** [en] Fout 2 I don't have time to look at the files right now, but from what Brian said before, it's not strictly necessary to compile them to use/modify them. Is that correct, or should I be disturbed by this? If I should be disturbed, can someone point me to a quick fix? Holly

Sept. 20, 2005

Re: XEmbed systray patch bugs

by Robert Shearman

James Liggett wrote: >1. The "Wine-Systray" window is still showing up. I've been able to fix >this by getting rid of the WS_VISIBLE style when creating the window in >systray.c, and then manually showing the window after it's been docked. > > This is just a bug with the existing systray code and something I can fix with a separate patch to dlls/shell32/systray.c. >2. The rightmost edges of systray icons are cut off. The previous fix >seemed to work for this problem too. I think it has something to do with >painting/updating the embedded window. > > Same again. -- Rob Shearman

Sept. 20, 2005

Re: listview: infoPtr might be invalid after WM_NOTIFY

by Robert Shearman

Michael Jung wrote: >Hello Alexandre, Dimi and Phil, > >This is a patch for the infoPtr problem in comctl32's listview.c. I guess it >matches your suggestion on IRC? I've only changed the minimum necessary to >get rid of the file dialog crash. If that's the correct approach in your >opinion, I will continue to work on this. I will be on vacation for three >weeks, though, starting from Friday. > >Dimi, if you think this is ugly, or if you are working on a better solution, >please do protest. > >Changelog: > infoPtr might be invalid after a WM_NOTIFY message was sent, since the >application might have destroyed the listview. Pass around hwnd instead and >call GetWindowLongPtr, if we have to access the listview instance data. >Spotted by Phil Krylov. > > Since this was a behaviour in our file open dialog, did we even verify that this was a listview bug or is it that destroying the listview in the middle of a notification is something that you shouldn't do? If the latter, then one could easily modify the file dialog to post a message to itself to destroy the listview after the listview has finished processing the message that caused the notification. -- Rob Shearman

Sept. 20, 2005

Re: Documentation volunteer(s) needed

by Stefan Dösinger

Hello, > You need to turn on backbuffers / backingstore in your xf86config and those > two functions were reasonable fast (so long as you don't play mess around > with the transfer modes) older driver (can't renember which version) Does this still work with newer drivers? 8.16.20 for example? It doesn't work for me. (I don't understand this clearly from your sentence.) > I've got a hack to go into wined3d that speeds up locking the backbuffer by > not bothering to read it if it's just been cleared, this get's movies using > DirectX and backbuffer locking up to a good frame rate with low CPU usage. That's exactly the problem I have! I expect it to occur too when Empire Earth finally runs. Can you send me your hack? I'd like to try it with D3D7. Another question: I've hit a problem where fglrx crashes on glBegin(GL_*) when GL_TEXTURE_2D is enabled. Any experiance / hints? Thanks for this hint, it looks like you saved me from doing a time-intensive investigation! Stefan

Sept. 20, 2005

Re: Windows CE on Wine

by Filip Navara

Boaz Harrosh wrote: [snip] > What if I want to do the same but for WindowsCE x86? We have already made this experiment once ... you can find info about it in the ros-dev (or ros-kernel) mailing list archives and skeletons of the two WinCE DLLs in the ReactOS SVN history (trunk/reactos/lib/commctrl and trunk/reactos/lib/coredll ... revision ~14000). It was proved that to run simple WinCE/x86 programs all that is needed is to get the loader to accept the WinCE PE signature (which Wine used to ignore and probably still does) and have implementation of the DLLs... - Filip

Sept. 20, 2005

Re: Documentation volunteer(s) needed

by Oliver Stieber

--- Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hello, > > Oh yeah, another question-- are we making provision for 'special > > circumstances'? I've got an ATI card, which makes me sensitive to such > > things, since the ATI drivers fail to do many things that they should, > > and often additional provisions need to be made specifically to get an > > app or game to run with the stupid fglrx drivers, where no such config > > workarounds need to be used with nVidia cards, or so I've heard. Or does > > that just fall under 'Troubleshooting'? Or does Wine not need such > > workarounds at all (unlike Cedega)? > There are for sure some cases where fglrx-specific problems exist. I am > hunting two problems with this driver. One thing is that glTexSubImage2D() > and glReadPixels() are HORRIBLY slow, another one is a crash in the fglrx > driver somehow related to textures. > > Maybe I can solve these 2 in time, so you don't have to write about them ;-) > You need to turn on backbuffers / backingstore in your xf86config and those two functions were reasonable fast (so long as you don't play mess around with the transfer modes) older driver (can't renember which version) Section "Device" Identifier "ATI Graphics Adapter" Driver "fglrx" ... # Backing store increases performance when locking the backbuffer Option "backingstore" "true" ... EndSection I've got a hack to go into wined3d that speeds up locking the backbuffer by not bothering to read it if it's just been cleared, this get's movies using DirectX and backbuffer locking up to a good frame rate with low CPU usage. Oliver > Stefan > > > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Sept. 20, 2005

Re: Documentation volunteer(s) needed

by Stefan Dösinger

Hello, > Oh yeah, another question-- are we making provision for 'special > circumstances'? I've got an ATI card, which makes me sensitive to such > things, since the ATI drivers fail to do many things that they should, > and often additional provisions need to be made specifically to get an > app or game to run with the stupid fglrx drivers, where no such config > workarounds need to be used with nVidia cards, or so I've heard. Or does > that just fall under 'Troubleshooting'? Or does Wine not need such > workarounds at all (unlike Cedega)? There are for sure some cases where fglrx-specific problems exist. I am hunting two problems with this driver. One thing is that glTexSubImage2D() and glReadPixels() are HORRIBLY slow, another one is a crash in the fglrx driver somehow related to textures. Maybe I can solve these 2 in time, so you don't have to write about them ;-) Stefan

Sept. 20, 2005

Re: Documentation volunteer(s) needed

by Kuba Ober

> There's enough material on this topic to practically write a book. > Someone should think about that. Wouldn't such a book be mostly obsolete within a year of publication? That's almost like with those linux kernel development books: in 2 years timeframe they are mostly paperweights, unless you're interested only in 'big ideas' rather than details. I might of course be wrong :) Kuba

Sept. 20, 2005

Re: Documentation volunteer(s) needed

by Tom Wickline

On 9/20/05, Holly Bostick <motub(a)planet.nl> wrote: > > Oh yeah, another question-- are we making provision for 'special > circumstances'? I've got an ATI card, which makes me sensitive to such > things, since the ATI drivers fail to do many things that they should, > and often additional provisions need to be made specifically to get an > app or game to run with the stupid fglrx drivers, where no such config > workarounds need to be used with nVidia cards, or so I've heard. Or does > that just fall under 'Troubleshooting'? Or does Wine not need such > workarounds at all (unlike Cedega)? IMHO.... Cedega should not even remotely be in the equation, the documentation is about Wine and only Wine. The folks at TG can write docs for Cedega as CW writes docs for CrossOver. So please don't reference Cedega in the docs. Tom > Holly >

Sept. 20, 2005