Re: [test.winehq.org] Addition of todo on the results page
John Klehm wrote: Bit off topic: One thing that struck me was the difference in test results for the Wine runs. This has most likely to do with old Wine installations running new tests. I will add the Wine version to the infrastructure soon so that these outcomes make more sense. In the same vein of thinking perhaps there should be a registry key or file that records what version of wine created the .wine directory and that information should get recorded into the tests as well. -John Klehm The idea was to use the output of "wine --version" for this. When I said infrastructure I meant 'test results'. -- Cheers, Paul.
Re: What the web test reports need.
Jakob Eriksson wrote: We need a http://test.winehq.org/data/latest/ Which always points to the latest results. Instead of: http://test.winehq.org/data/200708221000/ etc... Who can fix this? regards, Jakob I was actually discussing this with Jeremy the other day but haven't found the inspiration yet. -- Cheers, Paul.
Re: [test.winehq.org] Addition of todo on the results page
Michael Stefaniuc wrote: Hello, Paul Vriens wrote: While I'm also busy with getting dll information on the page, I'm still adding stuff. This next iteration will add todo information on the pages. Current situation: http://test.winehq.org/data/200708221000/ There are several todo's for the Wine test but this is not shown on the page. New situation: http://www.xs4all.nl/~pvriens/200708221000_new/ The main difference is the yellow border on the left for some of the Wine tests (for the group shown in the Main Summary and individually at the Group 'Wine differences'). dumb question: how do you see if one of the "Some tests fail in some reports" has some todos too? Would be orange a better color for the left border? I picked orange only as it is a mix of yellow and red (in the subtractive color mixing ); not sure if somebody would get eye cancer from looking at the result. Hi Michael Thanks for taking to time to have a look. The answer is, you can't with yellow. I've experimented with some colors and went back to yellow all the time. (This mixed results AND todo is only for Wine results by the way.) Here's the one with orange: http://www.xs4all.nl/~pvriens/200708221000_new_orange the old one is now: http://www.xs4all.nl/~pvriens/200708221000_new_yellow/ I just hope we get more reports in in the future otherwise we will never have mixed results ;-). I'm also going to change the text in the legend, "some tests need some work" to something like "implementation need some work". Cheers, Paul
Re: [test.winehq.org] Addition of todo on the results page
> Bit off topic: > One thing that struck me was the difference in test results for the Wine runs. > This has most likely to do with old Wine installations running new tests. I > will > add the Wine version to the infrastructure soon so that these outcomes make > more > sense. > In the same vein of thinking perhaps there should be a registry key or file that records what version of wine created the .wine directory and that information should get recorded into the tests as well. -John Klehm
Photoshop CS2 surprise
I fired up Photoshop CS2 today on a hunch, and sure enough, it starts and runs just barely well enough to test! When it starts, you have to dismiss a dialog box, press ^C in the console, and then dismiss another dialog box, but after that you can open an image, edit it, and save it successfully. Quite a few menu items misbehave, so there's lots left to do, but this is a lovely improvement. It seems likely that Mikolaj's recent changes had something to do with this. He's been doing quite a bit on Photoshop lately. Go Mikolaj! - Dan
re: mscoree: Return S_OK if mono runtime is found
Hi Bryan, I believe your patch lets me install WinBITS successfully. Thanks! - Dan p.s. To be precise, it let winetricks mono12 wine msiexec /i WinBITS.msi work. I then had to do winetricks gdiplus corefonts else the startup would complain about a missing font. Now mono's only complaining about GetThreadContext failed in gc, but that's another kettle of fish.
Re: [patch] Garbage code in text string display
On 23/08/07, Guan Xin <[EMAIL PROTECTED]> wrote: > On 8/23/07, Juan Lang <[EMAIL PROTECTED]> wrote: > > You may generally post source to wine-devel if it's short and to the > > point. Please don't post a binary. > > Acturally, this bug is obvious as I have pointed it out. No source is needed > for demonstration. Also I always programmed with Borland's AFX when > I used Windows. So my source is unlikely to compile under WINE or MSVC. > Recently I have no Windows machine and cannot learn Windows API > programming to write those tests. You don't need to have a Windows machine to write the tests. You can write them and build them through the Wine libraries. The reason for building them on Windows is so that you can verify them against Windows, but you could always post the tests for other developers to try. > > Right to the first point, which is why we write tests that pass on > > Windows, and fix Wine to match the tests. This obviates the need to > > look at Windows source. > > You must be mistaken. Tests that fail when WINE is not patched > and pass when patched do not prove correctness of the midification. > They only increase the possibility of its correctness. > I am sorry I never learnt computer science and misunderstood your requisition. As well as being run on Wine, they are run on different Windows versions as well, to verify them on all platforms. > Here is an analogy to show what you are doing: > in order to find out how to turn off the light, a computer scientist > tried to place a piece of wire into the outlet and made a short-circuit. > He succeeded. His `test case' never failed as far as he lived. > The computer scientist electrocuted himself. A better analogy would be that you have a light switch and a light bulb. The light switch is your input and the light bulb is the output. Everything else is unknown (a black box). You don't know how it works. You could open the box up and look inside (the equivalent of looking at the Windows source), but Wine can't do that. Also, if you modify the Wine code to improve it, you may break something. This would be like making a short circuit in your example above: the light no longer works in your replica (i.e. Wine), so any tests will fail on that. What you can do instead is say that when the light switch is on the 'up' position, the light bulb is on and when the switch is on the 'down' position, the light bulb is off. Now say you have two rows of 4 switches and a row of 4 lights, aligned with each other. What is the behaviour of this system? The only way to find out (without looking inside) is to devise a set of tests. This way, you can find out what logic the system is using. For example, if the system is behaving like a binary adder, you can deduce that from the tests. The tests in Wine are designed to pass on Windows (and should, in theory, pass cleanly on that platform). The implementation of Wine is then written to pass those tests, therefore matching the _behaviour_ of Windows. Specifically, a test would need to be created that highlights the MBCS program issue you identified, and verify that on Window it is returning DEFAULT_CHARSET. When this is run on Windows, it will pass, because it is testing that what is returned is DEFAULT_CHARSET. However, when this is run on an unpatched Wine, it will fail because Wine is returning ANSI_CHARSET. Now, running the tests on a patched version of Wine will cause that test to pass, matching the behaviour on Windows. - Reece
Re: [test.winehq.org] Addition of todo on the results page
Hello, Paul Vriens wrote: > While I'm also busy with getting dll information on the page, I'm still > adding > stuff. > > This next iteration will add todo information on the pages. > > Current situation: > > http://test.winehq.org/data/200708221000/ > > There are several todo's for the Wine test but this is not shown on the > page. > > New situation: > > http://www.xs4all.nl/~pvriens/200708221000_new/ > > The main difference is the yellow border on the left for some of the > Wine tests > (for the group shown in the Main Summary and individually at the Group > 'Wine > differences'). dumb question: how do you see if one of the "Some tests fail in some reports" has some todos too? Would be orange a better color for the left border? I picked orange only as it is a mix of yellow and red (in the subtractive color mixing ); not sure if somebody would get eye cancer from looking at the result. > I deliberately didn't add all the todo tests on the Group level (as is > done for > the skips) as todo have more to do with tests/implementations than the > actual system running the test. > > If there are no objections, I'll sent the necessary patches in a few days. > > Bit off topic: > One thing that struck me was the difference in test results for the Wine > runs. This has most likely to do with old Wine installations running new > tests. I will add the Wine version to the infrastructure soon so that > these outcomes make more sense. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich
Re: DIB Driver code available
Am Donnerstag, 23. August 2007 20:59 schrieb Jesse Allen: > > While you're at it, can you make it more universal so we can add a > > wined3d driver too, and convince AJ about it? > > Okay, but the dib driver is special. A dib works on any device, so > that's why I can convert between. You're not supposed to blit across > different devices. Could you point out your issues with blitting and > wined3d? Applications are supposed to be able to blit between d3d DCs and "normal" DCs(DIBs mostly). This works currently because wined3d downloads the gl data into a DIB and passes a DC of that DIB to the app. I wanted to improve our performance of GetDC on render targets by writing my own GDI driver, and return a DC whose functions draw directly in opengl, rather than downloading and reuploading. Nice plan, with one exception: Now I have made d3d surfaces a different device, which they are not supposed to be. Cross-Device blits aren't supposed to work, d3d<->dib blits are. Or are Device Independent Bitmaps a different matter here? I do not think so, as I understand them they belong to the general windowing device class. Alexandre says that my opengl driver should go into winex11, and he's right with that. On Windows <= XP, d3d is part of gdi, thus the d3d implementation is part of the gdi driver. I am not sure about Vista, but I think they removed it from gdi there to simplify the drivers. Now I do not like the idea of moving wined3d into winex11 or gdi32 altogether, so I'd have to split out the opengl gdi parts. Now the trouble is, that doesn't work. WineD3D manages the opengl contexts, and the gdi calls would need a context, and specific states set up. This could be fixed by writing a wine-private gl extension to get a hdc on the back buffer, which offers the driver implementation a callback to request a context from the user of the extension(wined3d). Also not a really nice solution. Another way suggested by Chris was to create GLXPixmaps, copy the back buffer into it, and then have gdi draw on it, then copy them back. The X server can optimize this, and keep the copying and drawing GPU-Side. However, that way we depend on the mercy of X11 and the driver to be able to do the xlib calls on the gpu. I doubt that they do it, but I'll play with this approach a bit more. The only gdi function I am really interested in is ExtTextOut, and perhaps GetDIBBits. Some games use it to draw text on the back buffer, and they're terribly slow(down to 0.5 fps). I have started a proove of concept implementation[1] which suffered from the Cross-Device BitBlt problem(theoretically, and pop3d used it, but apparently without doing anything with the results). I do not see any essential difference between your DIB driver and a wined3d driver from the BitBlt point of view. http://www.winehq.org/pipermail/wine-devel/2007-May/057170.html
Re: [patch] Garbage code in text string display
On 8/23/07, Juan Lang <[EMAIL PROTECTED]> wrote: > You may generally post source to wine-devel if it's short and to the > point. Please don't post a binary. Acturally, this bug is obvious as I have pointed it out. No source is needed for demonstration. Also I always programmed with Borland's AFX when I used Windows. So my source is unlikely to compile under WINE or MSVC. Recently I have no Windows machine and cannot learn Windows API programming to write those tests. > Right to the first point, which is why we write tests that pass on > Windows, and fix Wine to match the tests. This obviates the need to > look at Windows source. You must be mistaken. Tests that fail when WINE is not patched and pass when patched do not prove correctness of the midification. They only increase the possibility of its correctness. I am sorry I never learnt computer science and misunderstood your requisition. Here is an analogy to show what you are doing: in order to find out how to turn off the light, a computer scientist tried to place a piece of wire into the outlet and made a short-circuit. He succeeded. His `test case' never failed as far as he lived. The computer scientist electrocuted himself.
What the web test reports need.
We need a http://test.winehq.org/data/latest/ Which always points to the latest results. Instead of: http://test.winehq.org/data/200708221000/ etc... Who can fix this? regards, Jakob
[test.winehq.org] Addition of todo on the results page
Hi, While I'm also busy with getting dll information on the page, I'm still adding stuff. This next iteration will add todo information on the pages. Current situation: http://test.winehq.org/data/200708221000/ There are several todo's for the Wine test but this is not shown on the page. New situation: http://www.xs4all.nl/~pvriens/200708221000_new/ The main difference is the yellow border on the left for some of the Wine tests (for the group shown in the Main Summary and individually at the Group 'Wine differences'). I deliberately didn't add all the todo tests on the Group level (as is done for the skips) as todo have more to do with tests/implementations than the actual system running the test. If there are no objections, I'll sent the necessary patches in a few days. Bit off topic: One thing that struck me was the difference in test results for the Wine runs. This has most likely to do with old Wine installations running new tests. I will add the Wine version to the infrastructure soon so that these outcomes make more sense. -- Cheers, Paul.
Re: DIB Driver code available
On 8/23/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Am Donnerstag, 23. August 2007 20:16 schrieb Jesse Allen: > > On 8/23/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > > Am Donnerstag, 23. August 2007 18:58 schrieb Jesse Allen: > > > > Hi, > > > > > > > > I have my DIB driver code available on a public git host now: > > > > http://repo.or.cz/w/wine/dibdrv.git > > > > > > > > I'm going to briefly describe it. > > > > > > Is your dib driver an all or nothing replacement of winex11 GDI drawing, > > > or can it be mixed with winex11? > > > > I think it was decided not to mix the dc_funcs of the drivers. It > > seems like it would be messy as you have to keep track of which > > physDev goes where. So I decided to go all or nothing and have > > replacements for at least every winex11 export to be safe. Forwarding > > can be done as I described in the first email. I haven't tried yet, > > since it is still pretty early. Some functions might not be needed, > > though, like CreateDIBSection or CreateBitmap, but I still stubbed > > everything so in testing anything that might show up will be easier to > > identify. > Ya, I've tried forwarding in wined3d, it is a pain. I've decided to drop that > idea. What I meant was wether all GDI stuff happens in the new driver now, or > if some windows/DIBs/whatevers can use the new code, and some the old. Not all. It's going to be the same. I'm not planning on changing the driver interface. So I'm planning to make the dib.drv replace winex11 cleanly for DIBs only. The best way to use the new code is to select in a DIB section into your DC. To use the old code, select in a DDB. I don't know if it's possible to use the driver outside of GDI. > > > How do you deal with BitBlt() or simmilar calls > > > between your driver and winex11? > > > > I convert the bitmap to the destination device and proceed with the call. > > See: > > http://repo.or.cz/w/wine/dibdrv.git?a=commit;h=ad667f577e120ab96125c658679b > >d4f8d2a2decc > While you're at it, can you make it more universal so we can add a wined3d > driver too, and convince AJ about it? > Okay, but the dib driver is special. A dib works on any device, so that's why I can convert between. You're not supposed to blit across different devices. Could you point out your issues with blitting and wined3d? Jesse
Re: DIB Driver code available
Am Donnerstag, 23. August 2007 20:16 schrieb Jesse Allen: > On 8/23/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > > Am Donnerstag, 23. August 2007 18:58 schrieb Jesse Allen: > > > Hi, > > > > > > I have my DIB driver code available on a public git host now: > > > http://repo.or.cz/w/wine/dibdrv.git > > > > > > I'm going to briefly describe it. > > > > Is your dib driver an all or nothing replacement of winex11 GDI drawing, > > or can it be mixed with winex11? > > I think it was decided not to mix the dc_funcs of the drivers. It > seems like it would be messy as you have to keep track of which > physDev goes where. So I decided to go all or nothing and have > replacements for at least every winex11 export to be safe. Forwarding > can be done as I described in the first email. I haven't tried yet, > since it is still pretty early. Some functions might not be needed, > though, like CreateDIBSection or CreateBitmap, but I still stubbed > everything so in testing anything that might show up will be easier to > identify. Ya, I've tried forwarding in wined3d, it is a pain. I've decided to drop that idea. What I meant was wether all GDI stuff happens in the new driver now, or if some windows/DIBs/whatevers can use the new code, and some the old. > > How do you deal with BitBlt() or simmilar calls > > between your driver and winex11? > > I convert the bitmap to the destination device and proceed with the call. > See: > http://repo.or.cz/w/wine/dibdrv.git?a=commit;h=ad667f577e120ab96125c658679b >d4f8d2a2decc While you're at it, can you make it more universal so we can add a wined3d driver too, and convince AJ about it?
Re: DIB Driver code available
On 8/23/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Am Donnerstag, 23. August 2007 18:58 schrieb Jesse Allen: > > Hi, > > > > I have my DIB driver code available on a public git host now: > > http://repo.or.cz/w/wine/dibdrv.git > > > > I'm going to briefly describe it. > Is your dib driver an all or nothing replacement of winex11 GDI drawing, or > can it be mixed with winex11? I think it was decided not to mix the dc_funcs of the drivers. It seems like it would be messy as you have to keep track of which physDev goes where. So I decided to go all or nothing and have replacements for at least every winex11 export to be safe. Forwarding can be done as I described in the first email. I haven't tried yet, since it is still pretty early. Some functions might not be needed, though, like CreateDIBSection or CreateBitmap, but I still stubbed everything so in testing anything that might show up will be easier to identify. > How do you deal with BitBlt() or simmilar calls > between your driver and winex11? > I convert the bitmap to the destination device and proceed with the call. See: http://repo.or.cz/w/wine/dibdrv.git?a=commit;h=ad667f577e120ab96125c658679bd4f8d2a2decc Jesse
Re: user32: static controls should have a clipping region set while sending the WM_CTLCOLORSTATIC (2nd version, with testcase, fixes bug #9195)
On 8/23/07, Mikolaj Zalewski <[EMAIL PROTECTED]> wrote: > Tests have shown that every control style should set the clipping > region so I've changed the patch. > You forgot the patch. -- James Hawkins
Re: Application minimizing resizes it to icon size.
Am Donnerstag, 23. August 2007 20:02 schrieb Meelis Mägi: > commands i used to run Ryzom: > 1)wine client_ryzom_rd.exe > 2)wine explorer.exe /desktop=ryzom,1280x1024 client_ryzom_rd.exe > (minimizing Ryzom window inside wine desktop) > > Ryzom hates to be resized to icon mode in both occasions. it detects > the size change and relocates ingame UI accordingly. window in > bottom-left is moved to top-right, bottom-right to top-left etc. its > completely Ryzom's problem that it behaves like that. Ok, in that case I have no idea about the problem. There was a change recently to catch focus losses away from wine correctly, but that patch caused unintuitive behavior in virtual desktops. When the virtual desktop looses the focus now, apps see that they lost the focus and react to it. Especially for games this is strange. I do not know if I should consider that behavior a bug though. It is correct to report the focus loss, since the focus is indeed lost, but apps minimizing in the VD isn't optimal either. But I do not think that this is related to your problem.
Re: DIB Driver code available
Am Donnerstag, 23. August 2007 18:58 schrieb Jesse Allen: > Hi, > > I have my DIB driver code available on a public git host now: > http://repo.or.cz/w/wine/dibdrv.git > > I'm going to briefly describe it. Is your dib driver an all or nothing replacement of winex11 GDI drawing, or can it be mixed with winex11? How do you deal with BitBlt() or simmilar calls between your driver and winex11?
Re: Application minimizing resizes it to icon size.
2007/8/23, Stefan Dösinger <[EMAIL PROTECTED]>: > Am Donnerstag, 23. August 2007 18:56 schrieb Meelis Mägi: > > Hello, i have a silly question. > > > > Why does application resized to icon size when it gets minimized ? > > (also when switching desktops, but thats acts as minimizing i think) > > > > Reason i ask is that, there is MMO Ryzom (ryzom.com), that gets a bit > > confused when minimized and ingame UI gets messed up (only game i know > > that has this problem) > > > > If i comment out SetWindowPos() line in X11DRV_UnmapNotify() function > > (file dlls/winex11.drv/winpos.c), then ingame ui stays ok. > > Does that happen in a virtual desktop, or without it? > commands i used to run Ryzom: 1)wine client_ryzom_rd.exe 2)wine explorer.exe /desktop=ryzom,1280x1024 client_ryzom_rd.exe (minimizing Ryzom window inside wine desktop) Ryzom hates to be resized to icon mode in both occasions. it detects the size change and relocates ingame UI accordingly. window in bottom-left is moved to top-right, bottom-right to top-left etc. its completely Ryzom's problem that it behaves like that. i was just curious why does wine resize application window to icon size when application is minimized (and it's not just in one place, all over the code ;-) thanks.
Re: DIB Driver code available
"Jesse Allen" <[EMAIL PROTECTED]> writes: > Indeed, my tests show that there is a 50 second difference with GDI > Get/SetPixel. If anyone wants to try my app, I'll send it to them :) Note that GetPixel is the worst possible case under X, since it takes a full server roundtrip for each pixel. So yes, a DIB engine will definitely be faster here, the opposite would be very worrying. Testing just SetPixel would be a more meaningful test however. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Application minimizing resizes it to icon size.
Am Donnerstag, 23. August 2007 18:56 schrieb Meelis Mägi: > Hello, i have a silly question. > > Why does application resized to icon size when it gets minimized ? > (also when switching desktops, but thats acts as minimizing i think) > > Reason i ask is that, there is MMO Ryzom (ryzom.com), that gets a bit > confused when minimized and ingame UI gets messed up (only game i know > that has this problem) > > If i comment out SetWindowPos() line in X11DRV_UnmapNotify() function > (file dlls/winex11.drv/winpos.c), then ingame ui stays ok. Does that happen in a virtual desktop, or without it?
DIB Driver code available
Hi, I have my DIB driver code available on a public git host now: http://repo.or.cz/w/wine/dibdrv.git I'm going to briefly describe it. The dib driver (or engine) is a gdi driver. It is loaded into a dc when an application selects a dib, and overrides the existing driver. The magic takes place in SelectBitmap. Safe interaction is provided in gdi32 in four patches. If the winedib.drv.so library is available, then gdi will use the dib driver for drawing into the selected dib. If winedib.drv.so is not available, then gdi will continue using winex11 for example just as before. So these four patches can be safely integrated with the main tree if that is decided to be done. The rest of the code is the driver itself. It can handle all the standard uncompressed dib formats. It can convert between formats, and it can Get/SetDIBits/Blt. Get/SetPixel is implemented too. No other drawing code is done yet, so only simple GDI apps work. I've tested several apps and I'll list my results. notepad -- no regressions found winefile -- visual artifacts, but usable bmp loading -- works fine for what has been tested pixel setting -- works fine for every supported format opengl app -- Tribes 1 -- no regressions found d3d app -- Star Wars Battlefront -- no regressions found ddraw app -- Diablo shareware -- no regressions found ddraw app -- Diablo prerelease -- discovered one visual artifact These are the deficiencies in current code (non-stubs): No RLE support Missing raster operations in *Blt Get/SetDIBits does not conform exactly yet Bottom-up DIB's not tested for (and probably broken) DIB_PAL_COLORS not tested for No stretching No forwarding calls back to original driver* *For forwarding back the calls, what I think can be done is use the hbitmap handle originally given, convert it to a DDB, select it, and make the same gdi call again which will then go to the actual device. I do probably need to make sure the dibdrv's physdev persists and doesn't get deleted during this ;) (probably something in Create/Delete DC) Performance Originally I was going to state not to expect there really to be any performance improvements. I feel that there are optimizations possible that I have not done, but I left room for. My first concern was correct pixel by pixel operation. So I thought not to expect anything but last night I discovered this, so I might as well share. I have written a program that performs Get/SetPixel to test the various formats. There are 13 total tests, and the program produces 52 MB of output. Just for fun I ran my program without the dib driver and found it took a very long time (I was thinking it hung up at first since it took so long!): timed with winex11.drv real0m53.903s user0m19.807s sys 0m5.869s So I tried it with my driver: timed with winedib.drv real0m3.924s user0m3.537s sys 0m0.191s Indeed, my tests show that there is a 50 second difference with GDI Get/SetPixel. If anyone wants to try my app, I'll send it to them :) Still, I wouldn't expect *your* app to seem much different (or work at all :P) So will all the interested parties take a look at the driver and I'd sure appreciate feedback on the direction this is going, so we move towards finishing this project beyond the summer of code. :) Jesse
Application minimizing resizes it to icon size.
Hello, i have a silly question. Why does application resized to icon size when it gets minimized ? (also when switching desktops, but thats acts as minimizing i think) Reason i ask is that, there is MMO Ryzom (ryzom.com), that gets a bit confused when minimized and ingame UI gets messed up (only game i know that has this problem) If i comment out SetWindowPos() line in X11DRV_UnmapNotify() function (file dlls/winex11.drv/winpos.c), then ingame ui stays ok. thanks
Re: shlwapi: Fix UrlCombineW for absolute URLs without slashes.
"Robert Shearman" <[EMAIL PROTECTED]> wrote: +process_case = (*base.pszSuffix == L'/') ? 5 : 1; Although using the L prefix is harmless in this case, it's better to avoid it in Wine code IMO. -- Dmitry.
Re: [winetest] Use of HeapAlloc and friends
"Paul Vriens" <[EMAIL PROTECTED]> wrote: Is there any particular reason we don't use HeapAlloc/HeapReAlloc in winetest? The rest of our programs do, but winetest uses malloc and realloc. I recall that replacing malloc/realloc by HeapAlloc/HeapReAlloc has fixed user32/tests/msg.c failures under Win95 (that were caused by buggy msvcrt implementations), so if are still aming to run the tests on that platform we should get rid of malloc/realloc. -- Dmitry.
Re: [winetest] Use of HeapAlloc and friends
Paul Vriens <[EMAIL PROTECTED]> writes: > Ferenc Wagner wrote: >> Paul Vriens <[EMAIL PROTECTED]> writes: >> >>> Is there any particular reason we don't use HeapAlloc/HeapReAlloc in >>> winetest? The rest of our programs do, but winetest uses malloc and >>> realloc. >> >> I can't recall any. I'm more comfortable with the latter, since >> winetest is the only Win32 application I've ever written. > > So when I add functionality should I use malloc or can we use a mix? > Should winetest be changed to use HeapAlloc? That I can't tell. At least I haven't heard a single objection against my style in this respect. Mixing the two doesn't sound like a particularly compelling idea for me. -- Cheers, Feri.
Re: [winetest] Use of HeapAlloc and friends
Ferenc Wagner wrote: Paul Vriens <[EMAIL PROTECTED]> writes: Is there any particular reason we don't use HeapAlloc/HeapReAlloc in winetest? The rest of our programs do, but winetest uses malloc and realloc. I can't recall any. I'm more comfortable with the latter, since winetest is the only Win32 application I've ever written. So when I add functionality should I use malloc or can we use a mix? Should winetest be changed to use HeapAlloc? -- Cheers, Paul.
Re: [winetest] Use of HeapAlloc and friends
Paul Vriens <[EMAIL PROTECTED]> writes: > Is there any particular reason we don't use HeapAlloc/HeapReAlloc in > winetest? The rest of our programs do, but winetest uses malloc and > realloc. I can't recall any. I'm more comfortable with the latter, since winetest is the only Win32 application I've ever written. -- Feri.
Re: wordpad: Add initial printing support
Torsdag 23 august 2007 12:16, skrev du : > Am Donnerstag, 23. August 2007 01:52 schrieb Alexander Nicolaysen Sørnes: > > wordpad: Add initial printing support > > I usually don't read non-d3d patches, but when I saw the wordpad patches I > decided to see what wordpad looks like today, and I am really impressed :-) > Good work! > Thanks, man! :) There is one backdraw, though: our richedit has a stubbed EM_FORMATRANGE, so without the native dll it won't print anything. > This makes me wonder if Wine does or should register mime types for > wordpad, notepad, regedit, msiexec or .bat files? We really don't have to > be ashamed of our wordpad implementation, it is a nice lightweight editor > for .rtf files. I definitely think we should, both in the Wine environment and the native one. Registering it with icons in WIne is on my to-do list, then I'll see about adding it to the native environment if no one else is planning to. Alexander N. Sørnes
[winetest] Use of HeapAlloc and friends
Hi, Is there any particular reason we don't use HeapAlloc/HeapReAlloc in winetest? The rest of our programs do, but winetest uses malloc and realloc. Cheers, Paul.
Re: [PATCH try3 5/5] wininet: When sending INTERNET_STATUS_HANDLE_CLOSING make sure the freed handle is not yet available.
Misha Koshelev <[EMAIL PROTECTED]> writes: > +/* As on native when the equivalent of WININET_Release is called, the > handle > + * is already invalid, but if a new handle is created at this time it > does > + * not yet get assigned the freed handle number */ > if( info ) > WININET_Release( info ); > > +EnterCriticalSection( &WININET_cs ); > + > +if( WININET_dwNextHandle > handle ) > +WININET_dwNextHandle = handle; > + > +LeaveCriticalSection( &WININET_cs ); This is wrong, the handle could have been reused by then, you can't assume it is still free. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wordpad: Add initial printing support
Am Donnerstag, 23. August 2007 01:52 schrieb Alexander Nicolaysen Sørnes: > wordpad: Add initial printing support I usually don't read non-d3d patches, but when I saw the wordpad patches I decided to see what wordpad looks like today, and I am really impressed :-) Good work! This makes me wonder if Wine does or should register mime types for wordpad, notepad, regedit, msiexec or .bat files? We really don't have to be ashamed of our wordpad implementation, it is a nice lightweight editor for .rtf files.
Re: [1/5] WineD3D: Fall back to drawStridedSlow if fog coords are used
> This patch is probably fine, but it makes me look into the surrounding > code [ software blending, changing the strided data ], which is still > incredibly misleading. That should go into its own function, with the > FIXVBO macro removed (since all such macros are evil, without > exception), and a big comment should be added that named access to the > strided data is only valid in the fixed function pipeline and will not > work in the shader pipeline. Maybe it makes sense to use two different > structures to make this clearer - not sure. Yes, I think you're right about the macro, a function and a comment. I will make a patch for this. As for the separate structure for named and numbered attribs I am not sure either. We might need extra checks for useVS, but in theory we shouldn't because code that would need them is broken, since it either uses named access with shaders, or numbered access with fixed function. Another thing to consider is getting rid of the strided vertex structure altogether. I am not sure if it will work, or improve things. It may make the code simpler and faster to use the vdecl directory, but otoh there's IDirect3DDevice7::DrawPrimitiveStrided. We could handle that call with a bit of memcpy() calling, this method is hardly used(only one dx sdk sample, and the Ogre based 3D games. Ogre has a gl renderer too).
Re: user32: static controls should have a clipping region set whilesending the WM_CTLCOLORSTATIC (with testcase, fixes bug #9195)
"Mikolaj Zalewski" <[EMAIL PROTECTED]> wrote: Photoshop ImageReady depends on it. You have added an explicit clipping to STATIC_PaintTextfn, but since you are working on it, please test other static styles as well. Btw, if you are keen on writing a test (or making your test generic) for button control, that would help in investigating and fixing the bug 7569 which suffers from the same problem. -- Dmitry.
