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

winetest: build & publishing
by Dimitrie O. Paun April 24, 2004

April 24, 2004

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 April 24, 2004

April 24, 2004

"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 April 24, 2004

April 24, 2004

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

Re: Fix for test of CreateFileMapping in dlls/kernel/tests/file.c
by Jakob Eriksson April 24, 2004

April 24, 2004

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 April 24, 2004

April 24, 2004

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 April 24, 2004

April 24, 2004

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 April 24, 2004

April 24, 2004

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 April 23, 2004

April 23, 2004

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 April 23, 2004

April 23, 2004

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

Re: Re: winetest: build & publishing
by chmorgan＠charter.net April 23, 2004

April 23, 2004

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> > Date: 2004/04/23 Fri PM 02:24:17 EDT > To: "Dimitrie O. Paun" <dimi(a)intelliware.ca> > CC: Wine Development <wine-devel(a)winehq.org>, > Paul Millar <paulm(a)astro.gla.ac.uk>, Kevin Koltzau <kevin(a)plop.org>, > Ferenc Wagner <wferi(a)afavant.elte.hu> > Subject: Re: winetest: build & publishing > > Dimitrie O. Paun wrote: > > > 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? > > > > > > 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. > > regards, > Jakob > > > >

1 0