Re: Rethinking WineConf
On January 17, 2012 at 8:49 PM Dan Kegel d...@kegel.com wrote: Well, sure. I was replying to a suggestion that we tack wineconf onto the side of, say, http://monospace.us/ by saying that I didn't think they'd be interested. Do you think they would be? Well, if they would, it would be the greatest thing since sliced bread IMHO. Someone please ask. best regards, Jakob
Re: Rethinking WineConf
On January 10, 2012 at 11:00 PM Marcus Meissner mar...@jet.franken.de wrote: - Perhaps a shrinking audience is unavoidable. This is a bit of a fact that some projects I have been in found hard to cope with... That after the interest peak it might go down. And if you are looking for a reason, one is that interest in the Windows platform itself is waning. Maybe if Wine picked up the Metro glove, interest in Wine as a whole could be rekindled. //Jakob
Re: (Resent) Documentation - Reference to MSDN?
On 07/01/2010 04:34 AM, Dmitry Timoshkov wrote: Max TenEyck Woodburym...@mtew.isa-geek.net wrote: I created the top page as a table and populated it with all the directory entries in the 'dll' directory. Somebody immediately deleted it. WTF? Creating a MSDN clone does not belong to the Wine project. But maybe it should? MSDN is famous for being pretty good, but incomplete, incorrect and changing URLs all the time. // Jakob
Re: Make test drill, next steps, call for help with Winetest
Francois Gouget wrote:
While I prefer the autorun approach because it has fewer dependencies on
the Windows side and thus allows me to test in as clean a Windows as
desired, your approach could be pretty useful for testing on a real
Windows machine. Maybe if you post your script with some instructions it
will inspire some people to set up automated testing on their real
Windows machines. I'm sure it would make the Direct3D guys happy (if the
testers have Nvidia ;-) ).
I forgot... I did a C hack. cc -o runstuff.exe runstuff
Then copied runstuff.exe to c:\win95\Start-Menu\Program\Autostart
#include stdlib.h
#include unistd.h
int main ()
{
chdir (/tmp);
unlink (winetest-latest.exe);
system (wget
http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-latest.exe;);
system (./winetest-latest.exe -q -c -t JakobAuto);
system (shutdown -h now);
return 0;
}
About virtual machines starting in a clean state, nothing stops anyone
from booting linux
in between and dd if=windows_part.bin of=/dev/hdb1 and then reboot
into Windows.
This way you could get consistent Windows regression testing on real
hardware.
regards,
Jakob
Re: Make test drill, next steps, call for help with Winetest
Hans Leidekker wrote: On Saturday 27 October 2007 14:03:02 Francois Gouget wrote: That's something I've wanted to do for some time and this finally spured me to action. So here's a script that will do essentially the same thing but with VMware Workstation. Cool! I think I'll borrow some of your nice extra options. I'm moving towards VirtualBox now, it's FOSS, as good as VMware for my purposes and less painful to keep running on a bleeding edge Linux distro. I achieved much the same thing by putting a wget script in the Auto-startup folder of Windows. Then I copy in this vmware windows virtual machine and start it. Then Windows itself downloads winetest and upon completion, does a shutdown -h now. (Via cygwin.) I often find cygwin a relief when working with Windows. Just FYI. regards, Jakob
Re: Lots of 'make test' failures on Windows
Francois Gouget wrote: And I have recently put together a script for running winetest in VMware virtual machines unattended (see my other post). So going forward I will be running it on Windows 98, Windows XP and Windows 2003 nightly. This is s good. test.winehq.org will became several times more useful than before. A consistent track record from the same installations of Windows. regards, Jakob
Re: ddraw:d3d tests failing consistently
Francois Gouget wrote: It seems what you want is unit tests that would garantee that WineD3D behaves in the way which _you_ have decided. Most of the time that's the same as writing a _conformance_ test, but apparently in this specific case it's different. If that's so, then maybe we have to see how we can distinguish the two (separate test suites, enabling additional tests when running in Wine, etc). This sort of infrastructure could also be useful in the case I mentionned above, where a specific version of Windows returns something stupid, but where we'd very much prefer to match the behavior of the other non-buggy versions. This is very interesting and what I always thought lacking in Wine testing. We need both a way of checking that Wine works like Windows and, our a test to our own standards. regards, Jakob
Re: Improving http://tests.winehq.org/data/
Francois Gouget wrote: On Fri, 26 Oct 2007, Robert Shearman wrote: [...] Win9x's rpcrt4 is quite buggy and I don't think it's worth the trouble of diagnosing what is happening and trying to work around it, both with the crash and the test failures. Then rpcrt4_test should detect this and skip the server test. Otherwise it will show up as failed in the results and this will get reported again and again. Yes, can somebody please do that? It would also be an excellent precedent when similar problems occur with other tests. regards, Jakob
Re: ddraw:d3d tests failing consistently
Francois Gouget wrote: acceleration that they added in 6.0. So the relevant tests should be easy to skip, either by detecting lack of any 3D support or in the worst case by detecting the name of the graphics /sound card. Agree 100%. Windows on vmware is still Windows. // Jakob
Re: Lots of 'make test' failures on Windows
Alexandre Julliard wrote: If we require tests to pass on all Windows versions before getting committed it will drastically reduce the number of tests accepted, with little benefit. In most cases tests fail on some Windows boxes because they are too strict in the behavior they expect, and that's not a problem for us. Except that the tests clutter up the reports. We should have at least one dedicated, declared sane, Windows installation that we regard as most important. When you _start_ expecting tests to fail is when you _stop_ paying attention to tests. (That Codeweavers do not have such an installation yet, is beoynd me. Or if you do, please make it automatically submit its findings to test.winehq.org!) The only cases that we should really worry about are tests that fail the same way on all Windows versions, because it shows that the test is expecting the wrong thing. Cleaning up these tests to not expect the wrong thing should lead to a deeper understanding of desired behaviour of Wine. regards, Jakob
Re: Lots of 'make test' failures on Windows
Robert Shearman wrote: We do. I've got a machine that regularly runs the test on Windows 2003 on real hardware: http://test.winehq.org/data/200710241000/2003_rshearman/report That's excellent! However, the tests are run by a service rather than manually by me to reduce the effort needed. This results in some tests failing when they perhaps shouldn't. I have found that scripting a wget that runs periodically works good, with winetest in Desktop mode. Maybe something for that server? This also doesn't help the Direct3D developers since D3D is disabled by default on Windows 2003, so we also need a real Windows XP box to run the tests regularly. True... regards, Jakob
Re: Lots of 'make test' failures on Windows
Juan Lang wrote: Just looking at the pretty colors may not make this very obvious, but the state of the tests is APPALLING. Agreed. I wonder how much of it has to do with not noticing that the tests have failed? I may just be transforming the problem from an easy one (we shouldn't be lazy about checking the test results) to a hard one, but: what about automatically doing a regression test to find the patch that broke the test, and logging a bug for it? Amen!!! I have meaning to do this, but I have not been able to find the time. I suspect the biggest problem is keeping the winetest executable up to date on the systems. If the test system can't compile the tests, it can't easily perform a regression test. What's the biggest obstacle to that? One could do like Bazaar developers do, they have mailing list robot that snatches patches on their dev list and commits them. Our robot could build them (on a linux system) and run the resulting winetest.exe on a virtual machined windows. Then the patch could be blackflagged _before_ it was commited by Alexandre. regards, Jakob
Re: Priority/severity of test suite hangs
Dan Kegel wrote: I'm going to start filing bugs for anything that makes the test suite hang, and I'm going to lash out and give them unreasonably high priority and severity. There's just no excuse for a test suite that can't run to completion. +1
Re: nhelp, Vector NTI, molecular biologists
Francois Gouget wrote: Uwe Bonnes wrote: [...] Missing MFC42 and other redistributable DLLs is a showstopper for winelib and running windows code on non i386 archtecture... Well, not quite. If you're going to use Winelib it means that you have the source of the application. And if it is using the MFC it should mean that you have a Visual Studio license, and thus the MFC sources (though maybe that's only in the 'Pro' edition or some such). So then you should be able to recompile the MFC using Winelib. That's exactly what I did five years or so ago. I had to trim quite a few things but got something that was somewhat usable. I did not pursue it further though. Modern day MFC probably changed a bit (did it really change much?), but then Winelib should be much better too. The real issue is the license. In the Visual Studio 6 era, it seemed like it was legal to redistribute the MFC dll with your non-trivial application, with no mention of the platform. This might have changed since, and in any case that's something you'd want to check with a lawyer. In Visual Studio 6 it was allowed. In Visual C++ .net, it says not only only in object code form and together with a product that adds significant and primary functionality to the Redistributables, but also: Redistributables only operate in conjunction with Microsoft Windows platforms. I believe this is a direct response to Wine being rather useful. Also, end users may not distribute the Redistributable further. (Of course, programs developed with Visual C++ .net may still be distributed, but this license covers Microsofts copyrights on their redistributables.) regards, Jakob
Re: Hmm. Cider and the LGPL
Dan Kegel wrote: http://www.linux-community.de/story?storyid=23294 and http://www.macnews.de/news/102145.html mention that some users are using Cider from one game to run a second game on the Mac. The game vendors are upset, and are saying they'll do something to make that harder. There is some question about whether Cider includes LGPL components of Wine, and whether there are any violations lurking there. I imagine our friends at Cedega would instinctively avoid such infringement, but accidents might happen. It'll be interesting to see if anybody finds a real problem. - Dan Users can do whatever they want, (in most jurisdictions, even mostly the USA) with their binaries. But they can not then redistribute those hacked games or Cider binaries. regards, Jakob Eriksson
.NET support
Now that GDIplus is shaping up, is there a chance of implementing .forms support in mono with it? regards, Jakob
Re: .NET support
Bryan DeGrendel wrote: On 8/29/07, Jakob Eriksson [EMAIL PROTECTED] wrote: Now that GDIplus is shaping up, is there a chance of implementing .forms support in mono with it? regards, Jakob I haven't observed any Mono on Wine problems with GDI+. Do you have a .NET application that runs on Native Windows Mono but not Wine Windows Mono? Bryan DeGrende No, I wasn't clear enough. Roderick helped me (by having his act together.) regards, Jakob
Re: .NET support
Roderick Colenbrander wrote: On Thursday 30 August 2007 00:35, Jakob Eriksson wrote: Now that GDIplus is shaping up, is there a chance of implementing .forms support in mono with it? regards, Jakob Mono contains its own version of gdiplus for rendering system.drawing and in the end Windows.Forms. Though on windows I think it uses the native gdiplus.dll. You can install the win32 version of mono and see if it works. I'm not sure what you had in mind. Well, Monos version of Windows.Forms isn't exactly 100% compatible with .NETs. I figured now that the foundation of a REAL (gdiplus) is coming together, it might built on that instead. regards, Jakob
Re: .NET support
Roderick Colenbrander wrote: O I think the incompatibilities you mean are for instance that in case of Mono you can mix Windows.Forms with win32 calls. If you don't like the behavior of something you can call a standard gdi32/user32 function and change some stuff. Yes! Thank you, I didn't know 100% what I was talking about. Things like that work because I think the .NET version of Windows.Forms maps to win32 controls. Mono renders everything itself through System.Drawing. I don't think a different gdiplus.dll will make any difference for this. To allow mixing of Windows.Forms with gdi32 stuff everything needs to be rendered using native controls. That's what mono attempted years ago using Wine but they had various Wine integration troubles and we didn't come to a good solution for it. And wasn't one of those troubles that there was not gdiplus DLL? I was hoping an integration was coming closer. regards, Jakob
Re: .NET support
Roderick Colenbrander wrote: The main issues were related to using Wine as a sort of 'plugin'. They didn't want to use standard winelib. The Mono hack they proposed for it wasn't accepted and they didn't want to distribute their own Wine. Gdiplus was also an issue because they had to mix it with winex11.drv but that would have been fixable. OK. Win32 mono will be able to work on Wine. After some more integration it might be able to embed lets say Win32 ActiveX controls and use win32 dlls. It will never be able to use gdi32/user32 to change the behavior of some of the drawing stuff. For that they would need to rewrite Windows.Forms to not render the controls themselves. They will never do that. (It also means restarting from about scratch) But is mono modular enough, that implementing a third party Windows.Forms for Win32 mono is possible, that uses gdiplus/gdi32/user32? Or are there other, more intertwined dependencies? (If so, then not all is lost. A separate project may do this if compatibility is needed. This would of course lead to mono being more compatible both on Win32 and Unix.) regards, Jakob
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
Re: How to Calling PE Dlls on linux??
trulyliu wrote: I have tried these code, It works well. Thanks a lot. Could I use gcc/g++ instead of winegcc/wineg++ ??? mplayer use gcc as it's complier？ What's the mystery in it? AFAIK mplayer uses their own old version of wine they have adapted to mplayer. regards, Jakob
Re: Issue(s) when running winetest on Windows
Alexandre Julliard wrote: Paul Vriens [EMAIL PROTECTED] writes: Anyone? This is getting pretty serious now as several test reports that are submitted will never be processed. I could of course try and fix this in the parser but I do want to know what the issue is. The strange thing is that it only happens in the msvcrt test (maybe because it's file related). The only way is for the parent to wait for the child processes to terminate, by waiting on the process handles. By the way. I also noticed that Windows 95 actually bluescreens on rpcrt4 tests. regards, Jakob
Re: A script for automatic regression testing
Completely awesome, thank you! Mikolaj Zalewski wrote: I wrote a small script that automates regression testing. It requires an Autohotkey script that tests the program and creates a file C:\Test-failed.txt if the test failed. The bash script will then do the regression testing. It starts with copying the source tree and wineprefix so it should be possible to do some normal work during compilations. At the beginning of the script there are some variables that needs to be configured before running it. The wineprefix has to have Autohotkey installed and associated with *.ahk. The attached script's settings will find the regression for bug #9249. If anyone is interested in it I'd be interested in some feedback. Mikołaj Zalewski
Re: win16 tests
It would be sweet if you put up the executables too. Jennifer Lai wrote: Hi, I've collected and fixed some win16 tests. Since they are not going to be included in the wine tree, I've placed them under http://www.cs.ucla.edu/~jlai/win16test/ In order to build these tests, Open Watcom was used. The tar ball also includes the scripts of installing Open Watcom, building the tests, and running them. Details are described in the README. More tests will be added in the future, and comments are greatly appreciated. Thank you, Jennifer Lai
Re: [MSI/tests] ConvertSidToStringSid not available on win98/NT4
Paul Vriens wrote: Hi, ConvertSidToStringSid (advapi32) is not available on win98/NT4 so the msi tests (all of them) do not run on those platforms currently. I could use skip but that basically would mean no MsiQueryProductState, MsiQueryFeatureState and MsiQueryComponentState tests. Another thing is to copy over the ConvertSidToStringSid implementation from advapi32 to the relevant tests. Any other ideas (or better yet, solutions)? My $.05 ; I would like to see the NT4 column all green some day, because NT4 ended as a very stable and useful version of Windows. If we can't even verify we support NT4 functionality with Wine, how far have we really come? (I know Wine is supposed to run win32 applications, not emulate a Windows version, but still...) regards, Jakob
Re: [SNMPAPI] How to fix the tests for win98 and NT4?
Paul Vriens wrote: Hi, There are several functions in the util.c test that are not available on win98 and NT4. That can be dealt with easily. Almost all tests with a NULL parameter crash on win98/NT4. I know that a few weeks back we talked about ignoring win98 if it would mean skipping a lot of tests, but now NT4 is involved as well. I could introduce a variable of course that's set when we are on NT4 or lower (because of the missing functions) and don't run the 'NULL' tests. Any ideas, comments? I had this idea rejected before. Something about the test should not test Windows version, only Windows behaviour, except when an app relies on it. (In which case it IS some kind of meta-behaviour one might say.) regards, Jakob
Re: [MSI/tests] ConvertSidToStringSid not available on win98/NT4
Kai Blin wrote: On Thursday 09 August 2007 18:01:47 Jakob Eriksson wrote: My $.05 ; I would like to see the NT4 column all green some day, because NT4 ended as a very stable and useful version of Windows. If we can't even verify we support NT4 functionality with Wine, how far have we really come? That won't happen. E.g. I plan to eventually have Kerberos support in secur32.dll. NT4 doesn't do that. So whatever you do that's Win2k or beyond won't work on older Windows versions. That doesn't mean the test is bad. It also doesn't mean Wine can't run NT applications. I don't see how exactly having all test work on NT4 will make Wine better. Thats not exactly what I meant, I think. This Kerberos support comes from extra functions in secur32.dll right? The tests then will notice that there is no Kerberos support and not run Kerberos tests. Am I mistaken? Ahh.. :-) I did not mean a column with all green, but a column with no red. Quite a difference. Is that possible to achieve? regards, Jakob
Re: Wine disassembly and reverse engineering rules.
James Hawkins wrote: On 8/5/07, Jakob Eriksson [EMAIL PROTECTED] wrote: DMCA Reverse engineering exemption: http://www.chillingeffects.org/reverse/faq.cgi#QID210 From the article: The reverse engineer is required to ask permission first, however. ...good luck with that. It is strange that the say that, because I can not find anything about asking permission in the actual law text: http://cyber.law.harvard.edu/openlaw/DVD/1201.html#f regards, Jakob
Re: [winetest] Show missing tests in single/group results
Paul Vriens wrote: Comments/remarks etc.. are welcome. It is excellent that you are doing this, the reports are clearer for it. I will try to submit test results regularly. regards, Jakob Eriksson
Re: #1 winhttp: Forward WinHttpTime{From, To}SystemTime to their counterparts in wininet.
Jacek Caban wrote: Hans Leidekker wrote: I haven't seen a convincing argument for code duplication yet. Then why do you want to add hacks instead of proper implementation? We may even be able to achieve 100% by extending wininet a bit. E.g. we could add a Wine internal INTERNET_OPTION_CALLBACK_WINHTTP if we find an app that depends on winhttp specific behavior of callbacks. It'd be not only an ugly hack, but also unneeded code complication. Alright then. The pretty solution IMHO, is to create a third DLL, which both wininet and winhttp use. (Derive from.) That's how you usually refactor code. regards, Jakob
Re: Wine disassembly and reverse engineering rules.
Peter Dons Tychsen wrote: By browsing MSDN, i found out that i can accomplish this by using the documented function StalkWalk64(), which can examine the call stack. I would then introduce this into the test system for DLLs like user32. By running the test on original Windows we could know which messages we are incorrectly posting or sending where it should have been the opposite. This could fix some vital issues. I don't think there is a problem as i am just using documented APIs from MSDN, but since it includes looking at the call stack, i was curious if there might be a legal problem. I don't want to put the idea to use or release it if it in any way is illegal. Please think long and hard before you reply. DMCA Reverse engineering exemption: http://www.chillingeffects.org/reverse/faq.cgi#QID210 regards, Jakob
Re: Wine disassembly and reverse engineering rules.
Kai Blin wrote: On Sunday 05 August 2007 04:23:15 Peter Dons Tychsen wrote: It was regarding the fact that it is not allowed to disassemble and reverse engineer Microsoft DLLs. I understand this part, as their license prohibits it (EULA). Please note that reverse engineering by disassembly is not the same as reverse engineering by black box testing. The former is not only disallowed by many license agreements, it's actually a violation of copyright in most (western) countries. Not all western countries by far. Reverse engineering by black box testing is an established and legal method in industry. Wine uses this method extensively by writing test cases. However, i would be more clear if someone would make these rules commonly available on the WineHQ website. [Omitting a quote about disassembly being useless] This should probably be fixed. It should make it crystal clear was is allowed and what is not. This would help avoid situation like the one mentioned above. It's also not allowed to break other laws while developing software. Where would you draw the line? Disassembling software is (almost always) illegal. Killing people is illegal. Should both be in the development guide? I would assume common sense would tell people that they should only do things that are legal. Dissambling is not illegal. Disassembling and then writing another implementation is against copyright. [snip MSDN etc] This is the common sense I was talking about before. Thank you for asking. Please think long and hard before you reply. The usual disclaimer about how I'm not a lawyer and can't give legal advice applies, of course. But a rule of thumb is: If you never looked at disassembled code and you are using tests using the Windows APIs to determine how the API you're interested in works, you're fine. I also can't see how it would be illegal to, for instance, person A disassembling a DLL, then writing documentation for that DLL. Then for person B to reimplement said DLL by means of the specification specified by person A. This is how Compaq legally reverse engineered the IBM PC BIOS. I don't see how there would be any difference writing the documentation as unit tests or english. I.e. disassembling for the purpose of creating unit tests must be ok, AFAIK. regards, Jakob
Re: Wine disassembly and reverse engineering rules.
Kai Blin wrote: Why would you even bother to disassemble to write a unit test? All Wine cares about is What's the output of function X when I put in Y and Z as parameters?. That's why you write a conformance test that will run on Windows. Then you make Wine behave the same. No need to disassemble anything there. That is very true. There's no need. regards, Jakob
Re: Removal of unused audio drivers
Marcus Meissner wrote: Hi Maarten, I'm using esd actively. There are some audiocard drivers OSS provide and ALSA don't. I haven't used NAS at all and the winecfg delay annoys me too. Regards Vit What has esound (esd) to do with OSS? If you have soundcard only OSS supports, you cant use ALSA network sound, so you use esd instead. AFAIK. // Jakob
Re: wine and msys rxvt.exe
Phil Krylov wrote: AFAIR MSys's rxvt.exe uses libW11.dll, which implements Xlib API on top of Win32 USER/GDI (no extra X server). However, it could be still difficult (probably because of API name clashes?) Not sure why the message is about libX11.dll - probably it sees $DISPLAY and tries to use real X? AFAIR rxvt can be used both with and without X server, so that's probable. regards, Jakob
Re: Patchwork (was Re: Governance revisited)
Ge van Geldorp wrote: Actually, that's not how I intended things to work. The automatic removal from the queue would only happen if the patch had a RFC status, i.e. if action is expected from the patch submitter. If the patch is unopposed and just waiting in the queue, it should stay there. It's reasonable to tell a submitter you seem to have lost interest in this patch, it has been waiting on action from you for [a month, whatever] but nothing has happened, therefore it will be removed from the queue. Sending a warning message your patch is going to be dropped without explanation is no improvement over the current situation. Ok, I misunderstood. These things are tricky to comprehend and even harder to discuss. :) // Jakob
Re: Patchwork (was Re: Governance revisited)
Mike McCormack wrote: Ge van Geldorp wrote: My objective is to improve Wine by maximizing the number of patches of acceptable quality. In my opinion, this can be done by: 1) assuring no patches get lost 2) assuring an author gets informed about why his patch is not acceptable in its current form so he can improve it. That sounds good, but it's not reasonable to put the responsibility on Alexandre, as he has enough work already. I have been watching this thread with keen interest. Alexandre does not HAVE to respond to that patch, he can silently ignore it just like he can now. The only difference with Patchwork would be that after a certain time with no comments and no commits, the patch would be removed from the queue and the submitter would get an email warning. regards, Jakob Eriksson
Re: [RPCRT4] support for RPC TCP servers
Jan Zerebecki wrote: On Fri, Sep 22, 2006 at 12:04:40PM +0100, Robert Shearman wrote: I appreciate your attempt at solving this hard problem, but I don't believe this is the right approach. Using winsock2 instead of Unix sockets adds overhead in terms of wineserver calls and extra processing time to mangle arguments, which we shouldn't need. But shouldn't we have the possibility to use winsock so a build of our RPCRT4 is possible for native (and e.g. ros)? Exactly my thoughts too, but I didn't dare voice them. regards, Jakob
Re: OpenGL multiplexing and Wine
Stefan Dösinger wrote: Am Freitag 15 September 2006 09:40 schrieb Molle Bestefich: I think they are very interesting in combination with Wine, because Wine can let Direct3D games run on top of OpenGL, making the multiplexers work for all modern games, whereas running a real Microsoft Windows guest would only allow acceleration for some games. I think you'd have to run wined3d in windows to get that, or use a D3D multiplexer and use a Win32 vm app. There are plans for porting WineD3D to wgl, then it should run on windows too :-) And that would be really cool!
Re: How to use a windows dll in linux
[EMAIL PROTECTED] wrote: Thanks for the helpful replies. I have been working on the Winelib approach suggested by Jeremy. As my first step I wanted to get a windows console application to compile and run anyway. I now have an executable that runs and calls functions in the windows dll, but it does not work correctly. If I run it with winedbg it gives me a backtrace with errors coming from deep inside the dll. I assume there is some problem with the arguments going to the function that serves as the entry to the dll. Is there a way to find out what is getting passed to the dll and/or debugging inside the dll (without source code)? Can you open the DLL from a very simple standard Windows EXE with Wine? If that doesn't work, there is probably something within the DLL that Wine can not handle, yet. // Jakob
Re: --without-opengl problems
Off-topic, has anyone run Wine with this? http://bugle.sourceforge.net/ It checks OpenGL calls for validity. regards, Jakob Saulius Krasuckas wrote: If I compile Wine by starting with ./configure, it builds dlls/wined3d/wined3d.dll.so file. Then If I run some Ogre (d3d) game, I get all video setup stuff OK. If I connect to my tightvnc server after and run the game here, I get Xlib errors in the output (about missing GLX on :1.0 or a like). Then I decide to disable OpenGL support in Wine and start with ./configure --without-opengl. After this the wined3d.dll.so is left on the disk. And if later I run the game again via vnc server, I get weird errors and see Wine crashing in wined3d.dll (and sometimes wineprefixcreate crashes inside shlwapi.dll or opengl.dll). Isn't this behaviour strange a bit? Shouldn't configure delete dlls/wined3d/wined3d.dll.so or unlink dlls/wined3d.dll.so or at least define code don't try loading wined3d.dll when --without-opengl option is given to it? IOW, make clean shouldn't be necessary here, right? Well, I just may be missing some information... TIA
Re: freedos - dossystem under gpl - for Wine and vdm - fully compatiebel - LFM and all what we need
Vitaliy Margolen wrote: Thursday, May 11, 2006, 12:45:46 AM, blackcrack wrote: Hy Peoples, a idea again... why not use FreeDos in Wine... as dos for older programms... : You are welcome to start sending patches. Oh wait, it's GPL. So is Linux. regards, Jakob
Re: SOC: D3D Test Suite
H. Verbeet wrote: On 19/04/06, Sagar Mittal [EMAIL PROTECTED] wrote: The ones that D3D9 has also don't test the generated graphics for conformance. That's because OpenGL implementations aren't guaranteed to produce identical outputs when given identical inputs. Graphical conformance tests would probably be usefull, but they can't easily be automated afaik. How is that coming along? Codeweavers supposedly has utility to do just that?! regards, Jakob
Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
Mike McCormack wrote: Willie Sippel wrote: You announced working on the unmanaged window problem in September 2001 IIRC, but I guess you didn't so far? Wouldn't, for the time being, a Cedega-like approach be feasible? They seem to ignore 'chromeless' windows and handle them just like regular windows (with window decoration and all, for Steam for example) - this is obviously not correct, but it would at least work 'till someone comes up with a real fix...? Wouldn't be much motivation for somebody to come up with a real fix if there was already a half-baked fix in Wine already, would there? Mike That could be said about a lot in Wine. regards, Jakob
Re: winspool/tests: dump filename and version of the tested file
Detlef Riekenberg wrote: Am Dienstag, den 17.01.2006, 14:18 -0600 schrieb James Hawkins: We generally have a policy of silence for the test suite unless a failure occurrs. Then we need to update many Tests, which do not respect this. +1.
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
Stefan Dösinger wrote: Am Freitag, 25. November 2005 18:00 schrieb Jakob Eriksson: Aric Cyr wrote: All in all I think it would be worth while, but I'd still like to hear from others so as not to waste (a lot!) of my time. ReactOS would benefit as well from your approach. From what I have read in the ReactOS forums, they don't like this approach, because they have the ability to implement real Direct3D. It's also expected to be much easier than the D3D-OGL approach, because a lot of D3D functionality is provided by the device drivers. So, I don't think that they would benefit much. They would, but they don't know it. :-) It's quite conceivable for ReactOS to run on hardware where there is OpenGL support, but no vendor DirectX drivers. regards, Jakob
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
Aric Cyr wrote: All in all I think it would be worth while, but I'd still like to hear from others so as not to waste (a lot!) of my time. ReactOS would benefit as well from your approach. regards, Jakob
Re: CRYPT32/tests: don't crash on win98
Saulius Krasuckas wrote: AFAIR, he or someone else told me that isNT should be set by testing real behaviour of API, not by using GetVersion(). As the behaviour difference materializes itself in a shape of unhandled exception, we should catch it. Are we able do it in Wine easily? I think the answer is known. The recommended thing to do is check for something that can hint of bad things to happen. regards, Jakob
Test framework RFC (Was: Re: CRYPT32/tests: don't crash on win98)
Saulius Krasuckas wrote: * On Mon, 14 Nov 2005, Jakob Eriksson wrote: * Saulius Krasuckas wrote: isNT should be set by testing real behaviour of API, not by using GetVersion(). The recommended thing to do is check for something that can hint of bad things to happen. Yes, plus that something and GetVersion() doesn't hint that: (GetVersion() 0x8000) gives 0 both under Win98 SE and WinME. Test crashes under Win98SE but it doesn't under WinME. I am sure, the versions of crypt32.dll on both boxes are different. Yes, GetVersion() doesn't hint anything. I see no API-related tricks, which would help in such cases. Except for tested DLL version check, maybe. But that may be too hard, too: Proposal: Add a mechanism for detecting running a test several times. The first time serving the purpose of checking if the test crashes or not. If the test crashes, it is run again, but with an argument telling it that it crashed last time. This information is used to hint the test to avoid whatever it feels should be avoided. we should know not only the version of DLL, isNT value and tested function name, but we should also see what parameters and what their values can crash. This would require a 5-dimensional array of strings, I'd say. Would anynone here like to maintain such beast? I'm crazy enough, but probably has too little time. So no. regards, Jakob
[Fwd: joystickinput fixes (attempt number 4)]
---BeginMessage---
hiho
this is the forth time i send this patch, which was silently ignored
three times before and it is honestly the very last time i try.
this patch fixes in special IL2+addons, Pacific Fighters and Live For
Speed, if used with evdev-joysticks/wheels.
License: LGPL
ChangeLog
- moved and adopted joystick-linux.c code into the joystick-linuxinput.c
--
cu
Index: dlls/dinput/joystick_linuxinput.c
===
RCS file: /home/wine/wine/dlls/dinput/joystick_linuxinput.c,v
retrieving revision 1.32
diff -u -r1.32 joystick_linuxinput.c
--- dlls/dinput/joystick_linuxinput.c 12 Sep 2005 10:30:06 - 1.32
+++ dlls/dinput/joystick_linuxinput.c 10 Nov 2005 11:40:47 -
@@ -145,6 +145,7 @@
};
static void fake_current_js_state(JoystickImpl *ji);
+static int find_property_offset(JoystickImpl *This, LPCDIPROPHEADER ph);
#define test_bit(arr,bit) (((BYTE*)arr)[bit3](1(bit7)))
@@ -420,13 +421,35 @@
_dump_DIDATAFORMAT(df);
+ if (df == NULL) {
+WARN(invalid pointer\n);
+return E_POINTER;
+ }
+
+ if (df-dwSize != sizeof(*df)) {
+WARN(invalid argument\n);
+return DIERR_INVALIDPARAM;
+ }
+
+ if (This-joyfd!=-1) {
+WARN(acquired\n);
+return DIERR_ACQUIRED;
+ }
+
/* Store the new data format */
This-df = HeapAlloc(GetProcessHeap(),0,df-dwSize);
+ if (This-df==NULL) {
+return DIERR_OUTOFMEMORY;
+ }
memcpy(This-df, df, df-dwSize);
This-df-rgodf = HeapAlloc(GetProcessHeap(),0,df-dwNumObjs*df-dwObjSize);
+ if (This-df-rgodf==NULL) {
+HeapFree(GetProcessHeap(), 0, This-df);
+return DIERR_OUTOFMEMORY;
+ }
memcpy(This-df-rgodf,df-rgodf,df-dwNumObjs*df-dwObjSize);
- return 0;
+ return DI_OK;
}
/**
@@ -593,6 +616,47 @@
ji-js.rglSlider[1] = map_axis(ji, ABS_RUDDER, ji-axes[ABS_RUDDER
][AXE_ABS]);
}
+static int find_property_offset(JoystickImpl *This, LPCDIPROPHEADER ph)
+{
+ int i,c;
+ switch (ph-dwHow) {
+case DIPH_BYOFFSET:
+ for (i=0; iThis-df-dwNumObjs; i++) {
+if (This-df-rgodf[i].dwOfs == ph-dwObj) {
+ return i;
+}
+ }
+ break;
+case DIPH_BYID:
+ /* XXX: this is a hack - see below */
+ c = DIDFT_GETINSTANCE(ph-dwObj)WINE_JOYSTICK_AXIS_BASE;
+ for (i=0; (c1)==0 i0x0F; i++) {
+c = 1;
+ }
+ if (i0x0F) {
+return i;
+ }
+
+ /* XXX - the following part wont work with LiveForSpeed
+ * - the game sets the dwTypes to something else then
+ * the ddoi.dwType set in EnumObjects
+ */
+#if 0
+ for (i=0; iThis-df-dwNumObjs; i++) {
+TRACE(dwType='%08x'\n, This-df-rgodf[i].dwType);
+if ((This-df-rgodf[i].dwType 0x00ff) == (ph-dwObj
0x00ff)) {
+ return i;
+}
+ }
+#endif
+ break;
+default:
+ FIXME(Unhandled ph-dwHow=='%04X'\n, (unsigned int)ph-dwHow);
+ }
+
+ return -1;
+}
+
static void joy_polldev(JoystickImpl *This) {
struct timeval tv;
fd_set readfds;
@@ -769,17 +833,68 @@
DWORD flags
) {
JoystickImpl *This = (JoystickImpl *)iface;
-
-
FIXME((%p)-(dods=%ld,entries=%ld,fl=0x%08lx),STUB!\n,This,dodsize,*entries,flags);
+ DWORD len;
+ int nqtail;
+ HRESULT hr = DI_OK;
+
+
TRACE((%p)-(dods=%ld,entries=%ld,fl=0x%08lx)\n,This,dodsize,*entries,flags);
+
+ if (This-joyfd==-!1) {
+WARN(not acquired\n);
+return DIERR_NOTACQUIRED;
+ }
joy_polldev(This);
if (flags DIGDD_PEEK)
FIXME(DIGDD_PEEK\n);
+ len = ((This-queue_head This-queue_tail) ? This-queue_len : 0)
++ (This-queue_head - This-queue_tail);
+ if (len *entries)
+len = *entries;
+
if (dod == NULL) {
+if (len)
+ TRACE(Application discarding %ld event(s).\n, len);
+
+*entries = len;
+nqtail = This-queue_tail + len;
+while (nqtail = This-queue_len)
+ nqtail -= This-queue_len;
} else {
+if (dodsize sizeof(DIDEVICEOBJECTDATA_DX3)) {
+ ERR(Wrong structure size !\n);
+ return DIERR_INVALIDPARAM;
}
- return 0;
+
+if (len)
+ TRACE(Application retrieving %ld event(s).\n, len);
+
+*entries = 0;
+nqtail = This-queue_tail;
+while (len) {
+ /* Copy the buffered data into the application queue */
+ memcpy((char *)dod + *entries * dodsize, This-data_queue + nqtail,
dodsize);
+ /* Advance position */
+ nqtail++;
+ if (nqtail = This-queue_len)
+nqtail -= This-queue_len;
+ (*entries)++;
+ len--;
+}
+ }
+
+ if (This-overflow) {
+hr = DI_BUFFEROVERFLOW;
+if (!(flags DIGDD_PEEK)) {
+ This-overflow = FALSE;
+}
+ }
+
+ if (!(flags DIGDD_PEEK))
+This-queue_tail = nqtail;
+
+ return hr;
}
/**
@@ -799,36 +914,53 @@
case (DWORD)
Re: A small bounty for fixing a bug
Willie Sippel wrote: Hi there. I want to offer 100 EUR for a fix for bug #1973. It's not much, and I have no idea how complicated the bug is to fix, but maybe it's only trivial problem. The URL in Bugzilla is 404 again. regards, Jakob
Re: [Resend] printer dialog fixes part1 + french + other rcs
Andreas Mohr wrote: Hi, On Thu, Nov 03, 2005 at 01:20:00PM +0100, Jonathan Ernst wrote: Le jeudi 03 novembre 2005 à 13:09 +0100, Andreas Mohr a écrit : Hi, On Thu, Nov 03, 2005 at 12:02:21PM +0100, Jonathan Ernst wrote: Try2:This time, we just tell the user he needs to install a printer (we don't let him install one from Wine as it is not (won't ever?) be implemented). You really should have written: ...install a printer... *on your system.* What about on the underlying operating system ? Is it more clear ? Yup, while longer, I think it's better. On you computer. I believe is best. regards, Jakob
Re: shell32: Remove redundant .\\ from test files
James Hawkins wrote:
Hi,
I started by removing all .\\ from the shlfileop.c test file in msvc
and the tests all passed , but three of the tests failed in wine.
If the tests fail on wine, should they not be todo_wine{} then?
regards,
Jakob
Re: Fix for #3464
Can I create b: on the fly, allocate 1.44 megabyte RAM, do all copies
there and then
copy it back?
Am I on crack?
regards,
Jakob
Eric Pouech wrote:
It turns out that DOS' ioctl 0x440F (set logical drive map) was
strangely implemented. From the doc I have, this ioctl is responsible
for setting the logical drive to access a physical drive. This is used
for example, on a single floppy PC when implementing the copy a:foo
b:bar command, where a: and b: refer to the same physical device (the
floppy), and this ioctl is called to toggle the access from a: or b:
to the physical device.
This implies that this ioctl is not responsible for creating the
mapping of a: and b: to the same physical device.
The current implementation was trying to achieve this goal and
moreover it was done in the wrong way :-/
The attached patch removes altogether the support for logical drive
map in int21h (and fixed Myst BTW).
A+
Name: int21_mapdrv
ChangeLog: ioctl 440F only returns non mapped drives (for now)
License: X11
GenDate: 2005/10/12 18:41:20 UTC
ModifiedFiles: dlls/winedos/int21.c
AddedFiles:
RemovedFiles:
===
RCS file: /home/cvs/cvsroot/wine/wine/dlls/winedos/int21.c,v
retrieving revision 1.81
diff -u -u -r1.81 int21.c
--- dlls/winedos/int21.c18 Sep 2005 11:11:36 - 1.81
+++ dlls/winedos/int21.c12 Oct 2005 18:40:47 -
@@ -2627,19 +2627,12 @@
break;
case 0x0f: /* SET LOGICAL DRIVE MAP */
-{
-WCHAR dev[3], tgt[4];
+TRACE(IOCTL - SET LOGICAL DRIVE MAP for drive %s\n,
+ INT21_DriveName( BL_reg(context)));
-TRACE(IOCTL - SET LOGICAL DRIVE MAP for drive %s\n,
- INT21_DriveName( BL_reg(context)));
-dev[0] = 'A' + drive; dev[1] = ':'; dev[2] = 0;
-tgt[0] = 'A' + drive + 1; tgt[1] = ':'; tgt[2] = '\\'; tgt[3] = 0;
-if (!DefineDosDeviceW(DDD_RAW_TARGET_PATH, dev, tgt))
- {
- SET_CFLAG(context);
- SET_AX( context, 0x000F ); /* invalid drive */
- }
-}
+/* FIXME: as of today, we don't support logical drive mapping...
+ */
+SET_AL( context, 0 );
break;
case 0x11: /* QUERY GENERIC IOCTL CAPABILITY */
Re: Release plans
Holly Bostick wrote: If you don't want to go by, the bug has been downgraded from 'normal' to 'trivial' (which it rather is), and a suggestion has been made that, rather than writing a patch against the wine sources (and having to maintain it), an einfo should be added to the ebuild telling users to ignore the message from the compilation process. Which seems a quite reasonable solution that I would expect will be implemented. So I'd call that 'off my plate', myself :) . But then again, I've got plenty to do, so Is anyone building wine for Debian anymore? //Jakob deb http://wine.sourceforge.net/apt/ binary/
Re: headless question, and IPC question
Ken Larson wrote: Thanks for the info. Ultimately, my app is a Java app. I am spawning my EXE wrapper around my DLL and talking to it from Java with sockets. So unless I'm missing something, my entire (Java) app can't be a winelib linux app (barring something like gcj which I'm not sure I'm ready for). Maybe crazy, but can't you make a wrapper winelib app which spawns Java? //Jakob
Re: Autoresolving our 554 old UNCONFIRMED bugs
Francois Gouget wrote: On Fri, 30 Sep 2005, Dan Kegel wrote: We have 554 unconfirmed bugs older than 90 days. [...] Detailed proposal, including the text of the message to be sent, are at http://kegel.com/wine/qa/autoresolve.html Note that the second time you run the query you should only close unconfirmed bugs that are more than 104 days old and unchanged (this was ambiguous in your proposal). That's because unconfirmed bugs that are between 90 and 103 days old have not been notified at that point, or have not had their two weeks to react. That comment reads a lot like a unit test. :-D //Jakob
Off-topic, Was: Re: headless question, and IPC question
Alex Villacís Lasso wrote: 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. You can also run a VNC server on the virtual X server. Then you can leave and connect to your session from any client computer, without shutting down your running X programs. regards, Jakob
Re: freedce-win32 - progress!
Luke Kenneth Casson Leighton wrote: 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. That's really great! //Jakob
Re: DDRAW: Fix reference counting
Stefan Dösinger wrote: Hello, In that case, it would be really beneficial with a unit test. Both as documentation and to see what Windows does. Excuse my ignorance, but what exactly is meant with 'unit test'? As far as I've learned, it's a small piece of code which uses this functionality and checks the results. My patch includes such a test: I'm sorry. The test looks excellent. //Jakob
Re: KERNEL: check for NULL in LoadModule16
Andreas Mohr wrote: What about a directory dlls/kernel/tests/win16/ ? (and adding a README mentioning OpenWatcom) Or should it be dlls/kernel/tests16/ instead? Why not a binary win16 checked into CVS to be run by winetest? We only want to test win16 loading, right? regards, Jakob
Re: How to test a win16 application in our test-suite
Steven Edwards wrote: --- Paul Vriens [EMAIL PROTECTED] wrote: I'm busy fixing up version.dll, and I want to create some tests to read resources from win16 applications. I currently have a fixed .exe in my tests directory, but I'd like to create a 16bit .exe (or .dll) during the creation of the tests. OpenWatcom supports Win16 and Win32 apps and it works under Wine. Without a free 16bit compiler I don't see anyway to do it but perhaps we could make a project for Watcom and Winetests. Isn't OpenWatcom open source? Maybe SomeOne T.M. should make a winelib app out of OpenWatcom... :-P //Jakob
Re: Exception Handling with a bad ESP
Glenn Wurster wrote: of new engine. If someone is indeed working on a new GDI engine, than I'd be interested in finding out more and perhaps helping out, although I don't have a lot of time on my hands. Maybe the ReactOS GDI engine could be used for starters. Currently in ReactOS the port of Wine involves building most of the Winecomponents that sit above the core Win32 subsystem of gdi32/user32 and kernel32/ntdll. -- http://www.winehq.com/?interview=14 //Jakob
Re: Exception Handling with a bad ESP
Felix Nawothnig wrote: Dimi Paun wrote: We need to get rid of that seperation - either the DIB should be stored fully on X side (which would require to add some features to X) or fully on Wine side (by implementing a GDI renderer in Wine). You can't have it fully on the X side, since you need direct memory access Direct memory access can be done using X11 SHM, no? Sharing code with ReactOS is easier if it's not done in the X server. //jakob
Re: Today's winetest build?
Paul Millar wrote: On Monday 18 Jul 2005 18:42, Paul Vriens wrote: On Mon, 2005-07-18 at 19:15, Paul Millar wrote: I've noticed that the test site has no mention of today's cron-build of winetest. all seems well. You just have to wait till people wake up, download the latest winetest and run them interactively :-). Ta Paul, that makes sense. So, that leads me to the follow-on question: is it possible to configure winrash to run automatically? Only on Win95/98/ME. regards, Jakob
Re: Today's winetest build?
Robert Shearman wrote: Only on Win95/98/ME. I thought we'd fixed the problems with running it as a service on NT so that it could again be run automatically? Not as far as i know. It was recommended to mark the winrash service as allowed to interact with desktop or some such. It didn't help though. //Jakob
Re: [x11drv] d3d stencil support
Adam D. Moss wrote:
Hi!
Oliver Stieber wrote:
+if (visual == NULL) {
+/* fallback to a 1 bit stencil (opengl states that at least
1 bit of stencil must be provided for on of the available
configurations) */
+WARN(Failed to get a visual with at least 8 bits of
stencil\n);
+int dblBuf2[] =
{GLX_RGBA,GLX_DEPTH_SIZE,16,GLX_STENCIL_SIZE,1,GLX_DOUBLEBUFFER,None};
+
+wine_tsx11_lock();
+visual = pglXChooseVisual(display, DefaultScreen(display),
dblBuf2);
+wine_tsx11_unlock();
+if (visual == NULL) {
+/* This should only happen if we cannot fidn a match
with a depth size 16 */
+FIXME(Failed to find a suitable visual\n);
+}
+}
It's always nice to have a fallback, but in real life I've
never seen PC hardware (even back to the 90s) which supports
a 1-bit stencil buffer and not a 8-bit stencil buffer, so
this may be over-redundant. (Would be interested in hearing
of any consumer hardware which only does a 1-bit stencil.)
Sun ELC. Not exactly consumer hardware though.
regards,
Jakob
Re: Wine on x86 OS/X
This could be the beginning of something beautiful. Steven Edwards wrote: Hi All, So what are everyone's thoughts on doing it? If there are any darwine people lurking I am interested in knowning if any of you are registered developers and will be getting a copy of the preview release and evaluation hardware. Thanks Steven __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: CPU Emulation
Andreas Mohr wrote: Hi, On Tue, Jun 07, 2005 at 10:54:14PM +1000, Robert Lunnon wrote: Has any consideration been given to hooking a CPU emulation into wine to allow non x86 derivative CPUs execute native Windows binaries. For example it aught to be possible to hook qmu into the wine loader. Would this make a good Google Summer of Code project ? You even dare asking this question only one day after non-x86 CPUs have officially been declared extinct!? qemu is already able to run x86 Windows programs on non-x86 CPUs, with the Wine package that's distributed on the qemu website already. Not sure whether integrating qemu directly would help a lot... Hmm, probably yes, since the whole Win32 API part would be done natively, but there's still the whole x86 program part remaining for translation. All graphics and sound would be running natively. Look at Darwine project, they are the closest to this goal. (Still far away though.) regards, Jakob
Re: WineHQ css; binfmt Mono wine
Dimi Paun wrote: This is just wasted effort. They will probably get close, but will never be good enough. They just fail to understand that. Nevertheless, a lot of effort will be wasted, and we as a community will be years behind providing a good solution. Sigh. Not to mention that we (the Wine project) lost a huge contributor. If only a fraction of that effort would have been put into improving the controls say, we would have been in a much better place. I really think we need to put more effort in addressing this properly. Hear, hear! //Jakob
Re: Wine Wiki Status
Can you post the Balmer image someplace else on the wiki for us to see? Can you email it me? :-) Dimitrie O. Paun wrote: A few things: 1. We've been attacked Wed by one or two idiots from Slashdot. They kept replacing the content of the front page with some silly Balmer images :) Not a big deal, since MoinMoin makes it a snap to revert to an older version. However, this episode forced me to at least require that you sign up before you can edit a page. This is probably a good idea anyway, I hope people agree. 2. I've placed the modifications to the code on the Wine CVS repository at SourceForge in the 'wiki' module. Please feel free to check it out and send in patches (sending them to [EMAIL PROTECTED] with a subject prefix of 'Wiki:' is fine, or directly to me if you prefer). 3. Mike is right, the namespacing stuff if not a good idea. I'll try to get rid of it, I'm going to try to rename the page, but first I have to enable the feature. If not, I'll just simply recreate them. As always, you comments, suggestions and complaints are most welcome.
Re: Commercial support
Tom Wickline wrote: On 5/5/05, Jakob Eriksson [EMAIL PROTECTED] wrote: So, Are you saying I'm a Nazi for putting what you would consider a high price tag on a listing? All I'm saying is the referral by No. It was Andreas Mohr who first made the reference to the Third Reich. I just pointed out that we now have made it to the Godwin point... Well if you want to consider me as a Nazi for standing up and saying that a listing is worth more than what you consider as being fair then I guess ill have to be called such names. No... the Godwin reference is used on Usenet to cool a discussion before it goes into flaming mode. So if I offended you, or Andreas, or anyone else I'm deeply sorry. To go back to the original discussion, I agree that there should be _something_ holding back the free loaders. Not sure exactly what, so I'm monitoring the Commercial support thread to see what the consensus ends up as. regards, Jakob
Re: Commercial support
Andreas Mohr wrote: Hi, On Wed, May 04, 2005 at 02:57:17PM +0200, Boaz Harrosh wrote: Tom Wickline wrote: Here is my proposal... Must I shoot myself now or can I do it next week? :) . Indeed. I had the impression that the fascist Drittes Reich was long gone, but upon reading those lines... I invoke Godwins law. As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one.
Re: New program: getsffile
Maybe I'm being thick, but why do you need to change winrash for that? Chris Morgan wrote: It would be a useful feature to have. I'm still hoping someone will come along and take over winrash development. That hasn't happened yet. I'm not sure when I'd get a change to put such a feature in unless someone else wants to help out. Chris On Wednesday 04 May 2005 7:48 pm, Brian Vincent wrote: On 01 May 2005 17:12:50 -0400, Vincent Béron [EMAIL PROTECTED] wrote: New program in programs/getsffile (Get Sourceforge File). It downloads a file from Sourceforge download section, finding a suitable mirror by itself. I think this same problem came up with winetest and winrash. Perhaps this could be incorporated into winrash for upgrades? Also, as Dimi pointed out at WineConf, we need to change the DocumentRoot for test.winehq.org to point one level lower to where http://test.winehq.org/data/ currently is. We're still collecting data from winrash clients, so that's cool. -Brian
Re: Commercial support
Tom Wickline wrote: On 5/5/05, Jakob Eriksson [EMAIL PROTECTED] wrote: I invoke Godwins law. As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one. So, Are you saying I'm a Nazi for putting what you would consider a high price tag on a listing? All I'm saying is the referral by No. It was Andreas Mohr who first made the reference to the Third Reich. I just pointed out that we now have made it to the Godwin point... regards, Jakob
Still more fun?
Has anybody else thought of using DLLs (like ReactOS' dlls) as a compatibility layer to different Windows versions? I.e. when you distribute your Windows app, you also throw in a bunch of DLLs that implement lots of functionality you aren't sure exists on your target otherwise. (Windows 2003 functionality on Windows XP, 2000 and NT for instance.) It would be a way to avoid upgrading Windows. This would be good for developers, users and the Open Source community. The longer it takes for Microsoft to shove out a new version of their OS, the more time Open Source has to infiltrate. :-) I first had the idea when a program of mine refused to run on Windows 95 when it was compiled with Visual C++ .NET. It needed some XP functionality in a DLL not present on Windows 95. Well, I created a dll with the same name and distributed it with my program. //Jakob
Fun projects
Wasn't there talk about making DLLs for use in Windows, to export a native Windows desktop to an X11 server? //Jakob
Alexandre is back!
Send in more patches, everybody! :-)
Re: fyi your wine forum post
Ah come on... :-) Come back soon. It's unstable but it's fun. (On the other hand, if you wait long enough for Wine 1.0 to arrive it will actually be stable once you return.) [EMAIL PROTECTED] wrote: I would gladly share the fix if I had one. Since wine is inherently unstable with very little support I cant even be bothered to waste my time looking for now. It broke and I get told off for even asking why. I will go and work on some more worth while part of my system. As and when I come back to this and work out why simply rebuilding wine blows out my basic working config I will be sure to let you know. However I had better make sure I do not post here or I shall get shot down in flames for misusing the mailing list. Hope you dont get in trouble for repling. ;) On Sat, 09 Apr 2005 11:40:31 +0200, Joseph Black [EMAIL PROTECTED] wrote: While reading in the forum: Subject: Re: user broken ? Date: Thu, 7 Apr 2005 15:02:49 +0200 Warning: the specified Windows directory Lc:\\windows is not accessible. Warning: the specified System directory Lc:\\windows\\system is not .. Hi, glad you asked the question - I wondered how you test using cvs. I read on the wiki about regression testing but hesitated to try myself. Could you share what was the fix? did you need to re-install wine? I would like to add it to the wiki under troubleshooting... Link: http://wiki.jswindle.com/index.php/Wine_Developer_Regression_Testing Kind regards Joseph Black user of wine for years, but never of cvs. ps. unless you wish otherwise, I can attribute your name as the source of the fix..
Re: crypt32: CryptProtectData/CryptUnprotectData take 2
Kees Cook wrote: On Tue, Apr 05, 2005 at 02:32:11PM +0900, Mike McCormack wrote: The new patch looks good. I should have mentioned before that writing a test case will help your patch be accepted. Did you have any test code about that you could turn into a test case for your newly implemented functions? Sure, I can write something. I'll look around for docs on how to run tests -- I didn't find that when I looked around this morning. Also: I realize I should provide full documentation for the actual Windows API calls themselves. I documented everything BUT those. :) What's the convention for the number after the API name? I've seen some with numbers, and some with just an @ sign? Copied from a post yesterday: Thomas Kho mentioned that http://www.geekymedia.com/twiki/bin/view.cgi/WineDev/AddingMakefile was helpful to him. Since the webmaster there says he's taking down that wiki soon, here's a copy for posterity. -- snip -- Topic: AddingMakefile (as part of a new Wine test) Follow the example of the lzexpand test patch: http://www.winehq.com/hypermail/wine-patches/2004/11/0182.html Basic steps. (you'll have to chmod mod most of the files to 644 before you can edit them) 1. In your tests directory, look over wine/dlls/lzexpand/Makefile.in and wine/dlls/lzexpand/tests/Makefile.in 2. Now look at the Makefile.in in your dll directory. Copy it into your tests dir and change the list of .c files to your test .c file 3. Edit the Makefile.in file in your dll directory to add a subdirs line (see lzexpand/Makefile.in for an example) 4. In your wine directory, chmod 644 configure.ac 5. Edit configure.ac, find your dll directory in the AC_CONFIG_FILES and then add the path to your tests directory after it. 6. In your wine directory, run autoconf. Make sure you have 2.53 installed (autoconf --version). 7. Run configure. Your Makefile should be listed at the end now. -- snip -- -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: WineConf Agenda
Dimitrie O. Paun wrote: On Sun, Apr 03, 2005 at 08:57:58PM +1000, Andrew Tridgell wrote: In each case I will be trying to encourage methods which can store the full NTFS semantics, rather than limiting ourselves to only the things that fit natually in posix filesystems. I'm guessing we will have some lively discussion on whether this is a worthwhile aim :-) Speaking of which, both Samba and Wine suffer from the lack of support of cases-insensitivness in the kernel. Now, I'm not suggesting that we should push for that (I'm aware of the past discussions on LKML, and I must agree with Linus), but we should push for *something* that's acceptable and helps us solve the negative lookups a bit faster than a full directory listing every time. Linux 2.6 has an API to monitor directory changes right? We could have our own directory list hash in RAM. //Jakob
Re: WineConf Agenda
Brian Vincent wrote: I think a full agenda would be about 11 items. If you would like to present something let me know - there's definitely space available. If you've been wondering, There's a neat project I'd like to do if I could only get a few more people interested, well, this is the perfect time to bring it up. If there's something strategic to Wine development, this is a great time to discuss it. I don't know if I can find the time to prepare a proper presentation, but if I do, I'd like talk about and get some input from you on the subject of testing. 1) I want the conformance tests done faster. (I have a clear idea how.) 2) What's almost never been brought up on wine-devel is the unit testing in the XP sense. 1 has been discussed on wine-devel quite a bit, so I'll skip it in this mail. regarding 2: CXTest is like application testing. This is good, high-level testing. The conformance tests test the Windows API. But in the case of a complicated API (and Windows is complicated) maybe we need to test the smaller units behind the API. So, the conformance tests often are somewhere between application testing and unit testing. Can we have an infrastructure for running unit tests of small units of code private to the implementation? I.e. these tests, we could call them private tests, would not run on Windows, but during build of Wine. Would it be acceptable to just include extra test code in the implementation c file, surrounded by #ifdef COMPILE_PRIVATE_TESTS ? regards, Jakob
Re: [dlls/msi/*] Strncpy elimination.
Good thing you sent these patches. I was just thinking, should I dig in? :-) Peter Berg Larsen wrote: I have been checking the usage of strncpy, replacing where apropriate with a memcpy or lstrcpyn[AW]. The first raw diff was 100kb, so there is bound to be one or two slips. These are the first batch which I found to be obvious, correct, and didnt need a special comment. Note with correct I mean if there was a \0 bug before then it still there. Changelog: Janitorial Task: Check the usage of strncpy/strncpyW. Index: dlls/msi/action.c === RCS file: /home/wine/wine/dlls/msi/action.c,v retrieving revision 1.104 diff -u -r1.104 action.c --- dlls/msi/action.c 24 Mar 2005 21:01:38 - 1.104 +++ dlls/msi/action.c 26 Mar 2005 09:40:49 - @@ -922,7 +922,7 @@ while (*ptr == ' ') ptr++; len = ptr2-ptr; prop = HeapAlloc(GetProcessHeap(),0,(len+1)*sizeof(WCHAR)); -strncpyW(prop,ptr,len); +memcpy(prop,ptr,len*sizeof(WCHAR)); prop[len]=0; ptr2++; @@ -942,7 +942,7 @@ len -= 2; } val = HeapAlloc(GetProcessHeap(),0,(len+1)*sizeof(WCHAR)); -strncpyW(val,ptr2,len); +memcpy(val,ptr2,len*sizeof(WCHAR)); val[len] = 0; if (strlenW(prop) 0) Index: dlls/msi/dialog.c === RCS file: /home/wine/wine/dlls/msi/dialog.c,v retrieving revision 1.9 diff -u -r1.9 dialog.c --- dlls/msi/dialog.c 24 Mar 2005 15:09:31 - 1.9 +++ dlls/msi/dialog.c 26 Mar 2005 09:40:51 - @@ -131,7 +131,7 @@ ret = HeapAlloc( GetProcessHeap(), 0, len*sizeof(WCHAR) ); if( !ret ) return ret; -strncpyW( ret, p, len ); +memcpy( ret, p, len*sizeof(WCHAR) ); ret[len-1] = 0; return ret; } Index: dlls/msi/format.c === RCS file: /home/wine/wine/dlls/msi/format.c,v retrieving revision 1.8 diff -u -r1.8 format.c --- dlls/msi/format.c 16 Mar 2005 11:31:35 - 1.8 +++ dlls/msi/format.c 26 Mar 2005 09:40:51 - @@ -252,7 +252,7 @@ *key = HeapAlloc(GetProcessHeap(),0,i*sizeof(WCHAR)); /* do not have the [] in the key */ i -= 1; -strncpyW(*key,(*mark)[1],i); +memcpy(*key,(*mark)[1],i*sizeof(WCHAR)); (*key)[i] = 0; TRACE(Found Key %s\n,debugstr_w(*key));
Re: saving winrash
Robert Shearman wrote: Chris Morgan wrote: I have already sent links to documents on MSDN that state how to make a service run on an interactive desktop. As some of the tests are a little distracting graphically, we should probably do the dialog as you suggest. I guess this is really up to the people running the test machines. If the source to winrash was in the Wine tree I would already have fixed it by now. The source has been available on Sourceforge since the project started. Patches welcome :-) Ah, ok. I've never seen a link to the project. Here's a patch that should fix the creating of a service so that it appears on an interactive window station. Ohhh! This is interesting! Does this mean the service will have a desktop to interact with? regards, Jakob
Re: lostwages/templates/en contributing.template j ...
I submitted a patch for all casts I could find with that little grep: find . -name *.[ch] | xargs egrep \) *Heap(Re)?Alloc Jeremy Newman wrote: ChangeSet ID: 16817 CVSROOT:/opt/cvs-commit Module name:lostwages Changes by: [EMAIL PROTECTED] 2005/03/23 08:56:08 Modified files: templates/en : contributing.template janitorial.template resources.template sending_patches.template status.template Log message: Mike McCormack [EMAIL PROTECTED] * suggest janitoral project * other updates and W3 fixes Patch: http://cvs.winehq.org/patch.py?id=16817 Old revision New revision Changes Path 1.24 1.25 +3 -3 lostwages/templates/en/contributing.template 1.73 1.74 +17 -7 lostwages/templates/en/janitorial.template 1.11 1.12 +1 -1 lostwages/templates/en/resources.template 1.11 1.12 +2 -0 lostwages/templates/en/sending_patches.template 1.33 1.34 +1 -1 lostwages/templates/en/status.template
Re: Attempt to make buttons themed
Frank Richter wrote: On 22.03.2005 15:12, Dmitry Timoshkov wrote: It creates circular dependencies and an impossibility to correctly start up Wine. Imagine for a moment that ntdll depends on foo.dll which in turn imports kernel32. Maybe that can be worked around by having user32.dll load uxtheme.dll lazily... This way, when uxtheme.dll is loaded, user32.dll should be loaded and useable by uxtheme.dll. If for some reason uxtheme can't be loaded, no problem either, you just don't get theming. Apparently, Wine does handle that circularity quite well. I guess as long as you don't call uxtheme code from the user32 DLL init code and/or vice versa things should work. +1
Re: KERNEL: PeekNamedPipe must check for zero-length buffer as well as for NULL buffer
Alex Villacis Lasso wrote: Changelog: * PeekNamedPipe now checks both for a NULL buffer and a zero-length buffer before trying to recv() from the pipe Could you write a regression test? regards, Jakob
Re: Another one from last night: fix for dlls/kernel/tests/time.c on Windows 98
Alexandre Julliard wrote: Jakob Eriksson [EMAIL PROTECTED] writes: +/* Windows 98 is a bit broken around these parts, it doesn't return FALSE as it should. */ +/* If the resulting time is about 1 AD, I consider the result invalid. */ +ret = DosDateTimeToFileTime(0,0,ft); +years = ((unsigned)ft.dwHighDateTime * 120) / 24 / 365; That formula doesn't seem right to me. Could you please explain what you are doing here? I may be totally long but this is what I figured: the low parts unit is 10 nanoseconds. So one full dwLowDateTime is 2^32 10 nanoseconds, which is 120 hours. I guess one dwHighDateTime is 2^32 dwLowHighDateTimes, ie 120 hours. So multiply dwHighDateTime by 120 to get hours, divide by 24 to get days and divide that by 365 to get years. The epoch of ft began january the first 1601, so it's not really 1 AD, more like 8400 AD. Or maybe I got things very wrong. Or maybe we shouldn't test this particular corner case at all. As you said before, if it differs so wildly between different Windows versions, probably no real application depends on the behaviour. I just did this trick to ignore obvious bogus values from Windows 98, and doing so with an air of credibility. ;-) Would you accept a patch along the style of: if (ft.dwHighDateTime 0) then ignore_stuff();
Regression in file tests
Between http://cvs.winehq.org/cvsweb/wine/dlls/kernel/tests/file.c#rev1.46 http://test.winehq.org/data/200502231000/ and http://test.winehq.org/data/200503041000/ http://cvs.winehq.org/cvsweb/wine/dlls/kernel/tests/file.c#rev1.48 we have more about 50 more failed test results. What happened? regards, Jakob
Re: dlls/advapi32/tests/security.c - Bugfix in test!
Jakob Eriksson wrote: Alexandre Julliard wrote: Jakob Eriksson [EMAIL PROTECTED] writes: --- dlls/advapi32/tests/security.c14 Mar 2005 17:20:58 - 1.12 +++ dlls/advapi32/tests/security.c16 Mar 2005 09:32:28 - @@ -289,8 +289,8 @@ luid.LowPart = i; cchName = sizeof(buf); ret = pLookupPrivilegeNameA(NULL, luid, buf, cchName); -ok( ret GetLastError() != ERROR_NO_SUCH_PRIVILEGE, - LookupPrivilegeNameA(0.%ld) failed: %ld\n, i, GetLastError()); +if (GetLastError() != ERROR_NO_SUCH_PRIVILEGE) +ok( ret, LookupPrivilegeNameA(0.%ld) failed: %ld\n, i, GetLastError()); It doesn't really make sense to check the last error if the function succeeded. True. Don't know what I was thinking. Now I know. If the error was ERROR_NO_SUCH_PRIVILEGE, it's ok, we don't care. Move on. NT4 has this behaviour. If it isn't, but ret is 0, AKA LookupPrivilegeName() failed, I wan't to know exactly what the error was. It's a trace. So I think the patch is valid, there is method to the madness. regards, Jakob
Re: dlls/advapi32/tests/security.c - Bugfix in test!
Alexandre Julliard wrote: Jakob Eriksson [EMAIL PROTECTED] writes: --- dlls/advapi32/tests/security.c 14 Mar 2005 17:20:58 - 1.12 +++ dlls/advapi32/tests/security.c 16 Mar 2005 09:32:28 - @@ -289,8 +289,8 @@ luid.LowPart = i; cchName = sizeof(buf); ret = pLookupPrivilegeNameA(NULL, luid, buf, cchName); -ok( ret GetLastError() != ERROR_NO_SUCH_PRIVILEGE, - LookupPrivilegeNameA(0.%ld) failed: %ld\n, i, GetLastError()); + if (GetLastError() != ERROR_NO_SUCH_PRIVILEGE) +ok( ret, LookupPrivilegeNameA(0.%ld) failed: %ld\n, i, GetLastError()); It doesn't really make sense to check the last error if the function succeeded. True. Don't know what I was thinking. regards, Jakob
Wineconf Agenda
Brian Vincent wrote: I PS - still looking for ideas for the agenda, if you have any, let me know. Also let me know if you'd like to present something. Apart from all of Wine, I'm always interested in the conformance testing. I believe it's crucial in speeding up Wines' development. For each bug found, it is often a good idea to write an automatic regression test. Maybe we can extend on the winetest.exe infrastructure. I would like to see testing done in realtime - we now have a turnaround of maybe 3-4 days for a test developer like myself. I do a tiny, tiny patch, and then wait 3-4 days to see how it behaves on 6 platforms. What I would like to see: a cluster of Windows machines with different versions, all waiting eagerly for a small test.exe to appear. A dispatcher receives tests and then distributes it to waiting Windows machines. As soon as machine has run a test, it is rebooted. Preferrably from a clean vmware image. Mockup example: [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ make testgrid_file i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o file.cross.o file.c file.c:1: warning: -fPIC ignored for target (all code is position independent) i586-mingw32msvc-gcc alloc.cross.o atom.cross.o change.cross.o codepage.cross.o comm.cross.o console.cross.o directory.cross.o drive.cross.o environ.cross.o file.cross.o format_msg.cross.o generated.cross.o heap.cross.o locale.cross.o module.cross.o mailslot.cross.o path.cross.o pipe.cross.o process.cross.o profile.cross.o thread.cross.o time.cross.o timer.cross.o virtual.cross.o testlist.cross.o -o kernel32_crosstest.exe -lkernel32 i586-mingw32msvc-strip kernel32_crosstest.exe upx kernel32_crosstest.exe gpg --sign kernel32_crosstest.exe kernel32_crosstest.sig tar -cf kernel32_crosstest.tar kernel32_crosstest.exe kernel32_crosstest.sig wget http://testgrid.winehq.org/gridtest.cgi --post-file=kernel32_crosstest.tar --output-document=testgrid_file.txt [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ cat testgrid_file.txt Windows 2000 begin: file.c:1384: Test failed: DeleteFileA: error 3 file: 487732 tests executed, 0 marked as todo, 1 failure. End Windows 2000. Windows 98 begin: file.c:804: Test failed: MoveFileA: unexpected error 3 file.c:1384: Test failed: DeleteFileA: error 3 file: 487732 tests executed, 0 marked as todo, 2 failures. End Windows 98. Windows XP begin: file: 487732 tests executed, 0 marked as todo, 0 failures. End Windows XP. Windows NT4 begin: file: 487732 tests executed, 0 marked as todo, 0 failures. End Windows NT4. [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ [EMAIL PROTECTED]:~/src/wine/dlls/kernel/tests$ regards, Jakob
Re: SHELL32: use structure defined in standard headers for advertised shortcut info
Mike Hearn wrote: On Wed, 16 Mar 2005 12:12:47 +0900, Mike McCormack wrote: We only implement the first 4. Some of those are only needed by Explorer/the shell though, I doubt it's necessary to implement them to run the apps (unless you want to run Explorer of course :) Yes, probably, but what about the Explorer replacements like Directory Opus and Total Commander, anybody ran those in Wine? regards, Jakob
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
Paul Millar wrote: On Thursday 17 March 2005 10:33, Jakob Eriksson wrote: Apart from all of Wine, I'm always interested in the conformance testing. I believe it's crucial in speeding up Wines' development. For each bug found, it is often a good idea to write an automatic regression test. Yes, although that's a rather weary job, which no one enjoys doing :^/ I do! Maybe I have a condition, but I really love doing it! :-) There's three issues here: Yes. o fast(er) update of CVS (or whatever filestore we're using). This would need either: * a super-charged Alexandre ;) or * a separate CVS tree in which developers can edit the wine/dlls/*/tests/ directory, This makes sense. Winetest could actually be a separate project. I'm not saying it should be, mind you, just that conformance testing is interesting not only for Wine, but for Windows developers in general. So a separate CVS tree makes a great deal of sense, IMHO. Wine could import snapshots of the tests for its' conformance testing. This could speed up test development considerably, I imagine. or * give up on centralised/distributed testing architecture and switch to a personal testing environment. o fast(er) build of winetest.exe I originally argued for async. winetests and went as far as implementing this as part of WRT, so in principles this is already done. WRT worked based on the email notification of CVS updates. Builds, with minor changes, doesn't take long (using ccache), so you're probably looking 10-20 minutes turn around, with whatever delay the test-clients introduce. Though, without fixing the first issue, this doesn't help us much. o fast(er) running, through vmware platforms. Sure, this can be done, but its a distributed model, so everyone can chip in. Shouldn't be too difficult to achieve this. Sounds like fun, doesn't it? Test servers could register in the cluster worldwide. (Although I originally imagined a very centralized solution with a big server running vmware images.) Just my 2-c worth :) Are you coming to wineconf? regards, Jakob
wineconf agenda
Brian Vincent wrote: PS - still looking for ideas for the agenda, if you have any, let me know. Also let me know if you'd like to present something. Will anyone demo CXtest? I think it would be great. http://www.cxtest.org/ regards, Jakob
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
Ivan Leo Puoti wrote: Jakob Eriksson wrote: Maybe one could script something up so that a commit to tests CVS would not be *possible* without a confirmed test pass on Windows 95, NT, 2000 and XP. That would be very hard to do and mostly pointless for drivers. Sometimes hard is worthwile. At least to me. regards, Jakob
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
Paul Millar wrote: On Thursday 17 March 2005 11:51, Jakob Eriksson wrote: Paul Millar wrote: [writing tests]'s a rather weary job, which no one enjoys doing :^/ I do! Maybe I have a condition, but I really love doing it! :-) Long may that continue! Thanks, I hope so too! :-) Only my day job and things like planning a marriage stops me from digging deep into Wine testing. [..] I'd tread careful here: this isn't a panacea. Yes, its fairly easy to *say* OK, we just merge in the new tests, but would merging the snapshots really be a trivial job? If it is non-trivial, then Alexandre would front at least some of it and I suspect making more work for Alexandre is the last thing anyone (including Alexandre :^) would want. Ouch. Of course, should have thought of that. Maybe we need a patch penguin? regards, Jakob
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
Paul Millar wrote: On Thursday 17 March 2005 11:54, Jakob Eriksson wrote: Maybe one could script something up so that a commit to tests CVS would not be *possible* without a confirmed test pass on Windows 95, NT, 2000 and XP. That'd be the best thing since sliced bread. CVS supports doing some server-side validation tests before accepting a commit, so it could be done; but I don't think this would be nice. CVS is a mechanism for sharing code: its not really a testing framework. I didn't mean exactly on the CVS level. When Alexandre commits any patch, he first checks that the code still passes regression tests. I want something similar for the test patches. Maybe like this: the testing dispatcher signs a working patch* with GPG. (Or no GPG. Just set a flag somewhere. Details are not important.) Alexandre will see this flag when saving a patch from [EMAIL PROTECTED] and know that the patch is OK as far as the test grid is concerned. It could be as non-intrusive as this: the test dispatcher monitors the [EMAIL PROTECTED] for patches. As soon as it sees a patch it recognises and knows it has tested, it sends a mail to wine-patches akin to: The patch with CRC32 so-and-so posted by him or her, named so-and-so is hereby verified by me, the Wine Regression Grid Tester. ** or The patch with CRC32 so-and-so posted by him or her, named so-and-so failed under the following versions of Windows; bla bla blah, with the following error message: blah blah bla some more. Truthfully yours, the Wine Regression Grid Tester. ** Then it's up to Alexandre if he wants to commit a test which the grid tester has rejected, or for which there is no confirmation. If you don't like the idea of a program spamming wine-patches, it could be separate list, or a webpage with a copy of wine-patches, with different messages colour-codes updated as they get tested by the grid tester. * A working patch is a patch that has been tested and found working on Win 95, 98, ME, NT4, 2000 and XP. ** Could we call it WineGrind? :-) For the testing framework, I'd say what we have just now is fine. It lives outside (and on top of) CVS. Having broken tests is OK, provided they're fixed within a suitable time-scale [*]. Actually, I think having broken tests is not OK. It not only goes against my zealotry for Extreme Programming, it's also very annoying when I have _no_clue_ how to fix a broken test and the author is missing or don't want to touch the code with a ten foot stick. (just my 2c-worth again) Cheers, Paul [*] -- Of course, what is the suitable time-scale? who's willing to make sure things get fixed? Exactly, I feel rage everytime I see those red and yellow boxes at http://test.winehq.org/data/ ;-) regards, Jakob
Re: Enhancing winetest infrastructure [WAS: Wineconf agenda]
C. Scott Ananian wrote: On Thu, 17 Mar 2005, Jakob Eriksson wrote: Ouch. Of course, should have thought of that. Maybe we need a patch penguin? CVS actually handles 'vendor branches' fairly nicely. It should be possible for Jakob (or whoever else decides to be the 'test penguin') to maintain his own 'testing' CVS tree, with rapid development, etc, and periodically resync his own tree to canonical Wine CVS (using the vendor branch functionality) and then create large-ish 'tests-only' chunks from that to throw at Alexandre once in a while. There really shouldn't be much reason for Alexandre to reject patches that touch tests only; after all, if the tests pass on windows, they should pass on wine, no matter how evil they look. (Well, within reason.) That's MHO, at least. If I understand correctly, the primary reason for the 'testing' CVS is just to manage distribution of proposed tests to a server farm of test-runners; which is slightly different from the purpose of the mainline CVS tree. [Also -- a decoupled 'testing' CVS like I describe above can be implemented by the motivated folks w/o Alexandre's involvement at all, which permits judgements to be postponed until we've got some evidence of usefulness.] Yes. And I think I can implement most of even the more elaborate schemes without initially disturbing Alexandre or anyone else. As you say, until we get more evidence of usefulness. In this vein -- where *is* the current testing infrastructre located? I'm pretty new to Wine, and I couldn't find any links from winehq. [These should probably be added, or made more visible if they do exist, especially if the goal is to encourage test submission with patch submission.] http://test.winehq.org/data/ regards, Jakob
