April 2004 - Wine-devel - list.winehq.org

winetest: build & publishing
by Dimitrie O. Paun 24 Apr '04

24 Apr '04

Hi folks, I've checked the build this morning on SF, and it looks beautiful! So let's review the possible problems still outstanding: 1. Build Info Feri want to move that in the resources, with good reason. This will probably affect you very little, but needs to be done. We can still keep it in the .zip file (it is tiny) as it's a lot easier accessible for others. However, if we do that, the file will need to use DOS line ends, as this file will probably be viewed by folks on Windows boxes. Anyway, from your point of view it will probably mean a 'unix2dos' and a 'cp' before the build. 2. Uploading to SF This works nice now, but I'm afraid it may not when we have more than one person doing it. Namely, a release needs to be created, will that not fail if it already exists? Can we check that? If that's a problem, how are we going to deal with it? Kevin, can you please try to see if what happens if you upload two files (with differents sfutils invocations) into the same release? 3. Downloading from SF I just realized there is a time delay for the uploads to be propagated to the mirrors. What URL are we going to use for downloading? How long are we going to allow for the propagation to happen? Anyone has experience with this? 4. Release lifetime It would be nice to have the "WineTest Files" package visible on SF. I have made it so for testing purposes now. However, it will become ugly soon, because we don't hide the old releases. We can hide the entire package, and that would solve the ugliness problem, but it would be much nicer to have an automatic way of hiding old releases, and having just the latest releases visible. Can we maybe modify the sfutils to do this for us? We are very close on this front. I'm very happy with the state of things right now, I hope we can resolve these in a few days. -- Dimi.

5 6

Re: FILEDLG_MapOfnStructA bug?
by Dmitry Timoshkov 24 Apr '04

24 Apr '04

"Francois Gouget" <fgouget(a)free.fr> wrote: > -static char defaultopen[]="Open File"; > -static char defaultsave[]="Save as"; > > /*********************************************************************** > * FileDlg_Init [internal] > @@ -970,9 +968,13 @@ > if (ofnA->lpstrTitle) > str = ofnA->lpstrTitle; > else > + { > /* Allocates default title (FIXME : get it from resource) */ > + static const char* defaultopen="Open File"; > + static const char* defaultsave="Save as"; Don't you really want to leave it as a static const array of characters as before and not a static const pointer? Same for your next patch. -- Dmitry.

1 0

Re: Fix for test of CreateFileMapping in dlls/kernel/tests/file.c
by Stefan Leichter 24 Apr '04

24 Apr '04

Am Samstag, 24. April 2004 00:54 schrieb Jakob Eriksson: > From a run of winetest 20040423 on Windows XP: > > file.c:1075: Test failed: mapping should succeed > file.c:1077: Test failed: can't close mapping handle > file: 487696 tests executed, 0 marked as todo, 2 failures. > > > > Seems CreateFileMapping has some seriously strange behaviour. > I tested some more how XP behaves and produced a patch based on that. > > > regards, > Jakob Hello Jakob, + *handle = CreateFile(filename, GENERIC_READ|GENERIC_WRITE, 0, 0, + CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); + if (handle != INVALID_HANDLE_VALUE) { do you have to test the pointer not the value ? Bye Stefan

2 1

Window management protocol extensions
by Mike Hearn 24 Apr '04

24 Apr '04

The latest WM problems caused by Metacity preventing windows from being moved offscreen prompted to raise the issue of having a Wine specific extension to the NETWM (EWMH) protocol into which we can easily add whatever semantics we need to map win32 windowing to X windowing more easily. The idea would be that we have a new property/set of properties we can mark windows with, _NET_WM_WINDOWS_EMULATION for instance, and standards compliant window managers will take note and not do things that break us. Short of actually doing all our own window management, this is probably the best way to fix the obscure bugs caused by different interpretations WMs have of what various hints mean. The current NETWM border hints are semantic not presentational, so we cannot rely on particular intepretations. The MWM hints are even worse - they are apparently undocumented, and most modern WM authors consider them deprecated. Thanks to their undocumentedness, WMs vary in their interpretation of these too: http://bugs.kde.org/show_bug.cgi?id=73294 So, I'd like to start gathering ideas on what sort of things we'd like to have in the NETWM spec, seeing as how many WMs conform to it these days. First up is a way to ensure the WM doesn't attempt to keep the window onscreen of course :) Other things we probably want are related to border styles, an absolutely crystal-clear no-wriggling-possible equivalent to PPosition as apparently the wording of the ICCCM allows WM authors to ignore this if they want. We might also want to look at where we use unmanaged windows and see if we can replace them with the use of managed windows+hints. We can probably hack around the lack of these things for now, but being able to use these hints where possible will probably keep a lot of us from going grey-haired early :) thanks -mike

2 2

Re: Fix for test of CreateFileMapping in dlls/kernel/tests/file.c
by Jakob Eriksson 24 Apr '04

24 Apr '04

Jakob Eriksson wrote: > > From a run of winetest 20040423 on Windows XP: > > file.c:1075: Test failed: mapping should succeed > file.c:1077: Test failed: can't close mapping handle > file: 487696 tests executed, 0 marked as todo, 2 failures. > > > > Seems CreateFileMapping has some seriously strange behaviour. > I tested some more how XP behaves and produced a patch based on that. But I just installed Windows 95 and it fails very much under that platform: will have to think more about that... file.c:58: Test failed: couldn't create file "testfile.xxx" (err=32) file.c:105: Test failed: couldn't create file "testfile.xxx" (err=32) file.c:180: Test failed: couldn't create file "testfile.xxx" (err=32) file.c:204: Test failed: couldn't create file "testfile.xxx" (err=32) file.c:319: Test failed: couldn't create file "testfile.xxx" (err=32) file.c:354: Test failed: couldn't create file "testfile.xxx" (err=32) file.c:394: Test failed: couldn't create file "testfile.xxx" (err=32) file.c:441: Test failed: couldn't create file "testfile.xxx" (err=32) file.c:683: Test failed: DeleteFileA("nul") returned ret=0 error=5 file.c:893: Test failed: couldn't create file "testfile.xxx" (err=32) file.c:982: Test failed: couldn't create file "testfile.xxx" (err=32) file.c:1077: Test failed: Map is already created, for some reason we should be able to remap now... file.c:1081: Test failed: can't close mapping handle file.c:1086: Test failed: We should still be able to map! file.c:1087: Test failed: can't close mapping handle file.c:1088: Test failed: can't close file handle file.c:1097: Test failed: not ERROR_FILE_INVALID file.c:1108: Test failed: mapping should fail file.c:1110: Test failed: can't close file handle file.c:1111: Test failed: DeleteFile failed after map file.c:1118: Test failed: open testfile.xxx failed file.c:1120: Test failed: expected type disk got 0 file: 76 tests executed, 0 marked as todo, 22 failures.

1 0

graphical Linux
by Lonnie Cumberland 24 Apr '04

24 Apr '04

Hello All, I am going to work on a project that will rely heavily on OpenGL and Wine. I wanted to get some of your opinions on which Linux distribution has the easiest setup and install for dealing with OpenGL and Wine. I will make a fresh install of the best latest version and build on it. did try Mandrake once but the OpenGL did not seem to work with my NVIDIA GeForce FX 5200 Any suggestions would be greatly appreciated. Lonnie __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

4 3

DirectPlay
by Ryan Underwood 24 Apr '04

24 Apr '04

I have seen some mentions of work on DirectPlay. Who is currently working on this, and what are the implementation plans? I am mainly curious if it is planned to be network compatible with the same programs running on Windows. There could be some drawback to this, because the old versions of DirectPlay are not NAT friendly. So in the case of Wine, if the user is running a program that uses an old version of DirectPlay (i.e. the DX6 version), perhaps we could give them the choice to maintain compatibility with Windows clients (and thus be subject to NAT issues), or to use a more robust WINE-only version instead, perhaps an identical protocol to the one that would be implemented to support the later more robust versions of DirectPlay. -- Ryan Underwood, <nemesis(a)icequake.net>

3 2

winetest: dissect & gather
by Dimitrie O. Paun 24 Apr '04

24 Apr '04

Hi Feri, Here is a list of things that I see as potential problems: (I haven't checked the code, so they may already be handled) 1. Multiple builds For a given BUILD_ID, we can have reports comming from different builds now, that is from different winetest-*.exe. That means a much of URLs, etc. 2. Multiple reports For a given BUILD_ID, we may get multiple reports from the same client (same Tag). This is because of (1), we can ask each client to run not one, but a bunch of the available tests (this is very useful, say we have each client run a mingw build, and a msvc build). 3. Build Info This is a minor issue, and we can safely ignore it for now, but maybe we can provide a little icon beside each URL that we list in (1), that would popup a window and display the Build Info. 4. Template Not a biggie, but maybe we can transform the generated report into a template so that it integrates nicely with the rest of the site (menu to the left, etc). Jer, what do we need to do to achive that? I think it should be very easy, but... -- Dimi.

4 8

Re: Winetest: outstanding issues (SERVING)
by Dimitrie O. Paun 24 Apr '04

24 Apr '04

And the thrist and last installment: SERVING (Brian) --------------- What we need to support: -- multiple publishers -- multiple files for the same build for each publisher -- various distribution policies What we need to do: -- maintain a pool of releases as described in my previous mail. This is a map/hastable keyd by the published filename. -- persist this to disk, in case of server crash, load it from disk on startup. -- currently we use <program>/url.mask to get to the url mask. We need to add the publisher info in there, so this will need to change to: <publisher>/<program>/url.mask Similar for the other files. -- the rest remains unchanaged, as Brian correctly mentioned. We can have different distribution policies: pick a random file, send all files, etc. Given that we have few published files, and tests are short, I suggest we send them all. So what we have to do is to add a loop around most of the script generation: for file in pool: generate script commands to download it and run it It looks like there aren't that many changes after all. -- Dimi.

3 3

Re: winetest: build & publishing
by Jakob Eriksson 23 Apr '04

23 Apr '04

Okay, but am I missing the point? winetest.exe is already self-extracting in itself... regards, Jakob chmorgan(a)charter.net wrote: > Lately I've been doing a lot of installer building with the NSIS > installer(http://nsis.sf.net). We could easily package winetest as a > self-extracting and executing installer that was transparent to the > user. The installer would simply extract the actual winetest.exe to > windows/temp, start it up and wait until it completed before exiting. > This should be transparent to winrash as well. > > Chris > > > > >> From: Jakob Eriksson <jakov(a)vmlinux.org> >> >> Can you also upload the exe? >> >> Ferenc touched this issue slightly - if we want to point (maybe very >> novice) users >> to a way to contribute to Wine - commandline option may be hard to >> understand. >> A zipped file can also be an obstacle. >> It's very neat just to click "open" on an exe compared to unpacking a >> zip. >> >> >

1 0