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

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

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

project David?
by Rein Klazes April 23, 2004

April 23, 2004

Hi, Somehow, we are doing something far to complicated: http://www.specopslabs.com/david.htm Rein. -- Rein Klazes rklazes(a)xs4all.nl

13 18

Google's cachze link update
by PETREOLLE Sylvain April 23, 2004

April 23, 2004

Hello, The following change makes the google page unavailable here. why would you change it since it still works ? Patch: http://cvs.winehq.org/patch.py?id=12121 Old revision New revision Changes Path 1.2 1.3 +1 -1 lostwages/news/2004040701.xml - (23 April 2004 - <a href="http://66.102.7.104/search?q=cache:sDglkGiMh7sJ:www-106.ibm.com/develo perworks/linux/library/l-wine/%3Fca%3Ddgr-lnxw11FineWine">Google's cache</a> still has a copy, but it's been removed from IBM's website.) + (23 April 2004 - <a href="http://www.google.com/search?q=cache:sDglkGiMh7sJ:www-106.ibm.com/deve loperworks/linux/library/l-wine/%3Fca%3Ddgr-lnxw11FineWine Cordialement, PETREOLLE Sylvain #DMIT/DATO/PSI/OPS (exploit at gefco dot fr ) +33 (0)1 49 05 29 29 "1+1=3" Bernard Werber ---------------------------------------------------------------------------- Ce message ainsi que toutes pièces jointes (le "message") sont confidentiels et sont exclusivement destinés à l'usage de la personne à laquelle ils sont adressés. Tout point de vue ou toute opinion contenus dans ce message expriment la pensée personnelle de leur auteur et ne représentent pas nécessairement la position des sociétés du Groupe GEFCO. Si vous n'êtes pas la personne à laquelle ce message est destiné, veuillez noter que vous avez reçu cet e-mail par erreur et qu'il vous est strictement interdit d'utiliser, de diffuser, de transférer, d'imprimer ou de copier ce message. Si vous avez reçu ce message par erreur, merci de contacter la personne qui vous l'a adressé et de l'effacer immédiatement. Les sociétés du Groupe GEFCO déclinent toute responsabilité en cas d'altération, de modification, d'édition, de diffusion sans autorisation de ce message ou en cas d'affection de ce message par un virus. This message and any attachments (the "message") are confidential and intended solely for the use of the individual to whom they are addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the GEFCO Group of Companies. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this message is strictly prohibited. If you have received this message in error please contact the sender and delete the message immediately. The GEFCO Group of Companies shall not be liable for the message if altered, changed, falsified, edited, diffused without authorization or affected by any virus. ----------------------------------------------------------------------------

1 0

Problem with GetVolumeInformation
by Chris McKenzie April 23, 2004

April 23, 2004

The refers to the 2004-03-09 ChangeLog, specifically: * dlls/kernel/Makefile.in, dlls/kernel/volume.c, dlls/ntdll/file.c, documentation/samples/config, documentation/wine.conf.man, files/drive.c, include/drive.h, include/winnt.h: Reimplemented GetVolumeInformation and SetVolumeLabel; volume label and serial number are now stored in the filesystem instead of in the config file (partly based on a patch by Eric Pouech). GetVolumeInformation's new implementation has 2 problems: 1. For software that was previously registered with a "made up" serial number via the "serial=" directive in the config file, the software (for me Altera MaxPlus) will no refuse to run claiming a change in serial. 2. If the function fails to claim a serial number (What actually _did_ happen with me) it will fall back on *serial=0. In my opinion this does not seem reasonable. I propose two options for wineconfig. First, one that says UseConfigSerial = [Y/N] Which will use the serial number in the config file and ignore the one on disk (This is useful for people that registered their software before the new function implementation) And the second option will be to reinstate the serial= for the drive descriptions. This should be the fallback serial number if the function fails, instead of the value *serial=0. I made a quick hack to return the value that I needed - however, I have not dealt with the kernel or the wine code extensively so I cannot put for a patch that does this at this time. However, I think this is a much more sensible design decision. Thank you. Sincerely, Christopher J. McKenzie cjm(a)ucdavis.edu

2 1

MinGW --mno-align-double
by Dimitrie O. Paun April 23, 2004

April 23, 2004

======= From: Hans Leidekker <hans(a)it.vu.nl> To: wine-devel(a)winehq.com <wine-devel(a)winehq.com> On Saturday 27 March 2004 02:20, Dmitry Timoshkov wrote: > generated.c:542: Test failed: TYPE_ALIGNMENT(*(LPWIN32_STREAM_ID)0) == 8 > (expected 4) generated: 842 tests executed, 0 marked as todo, 1 failure. > * NOTE: the same test compiled by cl.exe (MS compiler) works as expected, > * so that's most likely a gcc bug. (gcc version 3.3.1 (cygming special)) Same here (GCC 3.2.3 (mingw special 20030504-1)). It appears that this compiler defaults to --malign-double. When I specify --mno-align-double the test succeeds. ======= Alexandre, can we add this flag to our makefiles? If so, I can produce a patch... -- Dimi.

3 2

Re: Winetest: outstanding issues (BUILDING)
by Dimitrie O. Paun April 23, 2004

April 23, 2004

> From: Paul Millar <paulm(a)astro.gla.ac.uk> > One way this could work is if the general format for the BUILD_ID is > YYYYMMDDhhmm [ "-" <tag> [ "-" <tag> ] ...] > where <tag> is any metadata keyword that must not include a "-" Right, I have reached the exact same conclusion over lunch myself. So here is a fresh round of specifications: BUILDING (Paul & Kevin) ----------------------- A.The build process will produce 2 files: <name> <name>.sig where: <name>: the file being published <name>.sig: the GPG signature B. Naming <program>-<build>-<publisher>-<tools>[-<misc>].<ext> where: <program>: program name (i.e. "winetest", "winrash") <build>: build ID (for winetest, it's YYYYMMDDhhmm) <publisher>: publisher ID (i.e. "paul", "kevin") <tools>: tool chain used (i.e. "mingw", "msvc") <mic>: any other information the publisher wishes this can be used to support different builds for the same <build>, say with different flags, patches, etc. <ext>: appropriate extension (i.e. "zip", "exe") C. Publishing After the files have been successfully uploaded to the server (for winetest, this will be sf.net) a publish event will be sent to WineHQ, with the following form: http://test.winehq.org/service?publish=true&url=<url> where: <url>: is the URL to the <name> D. Winetest specific information - <program> = "winetest" - <publisher> = "paul" or "kevin" - <tools> = "mingw" (but a msvc would be good too) - <ext> = "zip" - nightly build will use sources as of 5AM EST - the <build> will use same time converted to UTC so it will mosty be YYYYMMDD1000, but it may be different when daylight-savings is in effect - you should use cvs co -D "YYYY-MM-DD 5:00 EST" to check out the code, and use date -u +%Y%m%d%H%D -d "YYYY-MM-DD 5:00 EST" to generate the <build> (I may have the format wrong, I don't have a reference handy) - the .zip file contains two files: winetest.exe: the object of this exercise winetest.info: metadata information about the build, as the tools that where used, special flags, mentions any special patches, etc. The information in here will not be automatically parsed, but rather is intended to help the developers debug problems. NOTE: should we include all the metadata present in <name> is the names of the .exe and .info? I would personally like to, in order to avoid any possible confusion on the tester's box. OK, did I miss anything? I will shotly send emails describing the other stages, I did not include them here, since this email is getting a bit long. The good thing is that there are no changes to Chris' winrash, there are a few changes (trivial) to winetest.exe, and dissect&gather, and some to service.cgi. But I'll cover those in my next emails. -- Dimi.

4 4

Microsoft: "We'd have been dead a long time ago without the Windows APIs"
by Mike Hearn April 23, 2004

April 23, 2004

http://news.zdnet.co.uk/0,39020330,39152686,00.htm At least they're honest about it - I especially love this quote: In the commission's report, Contorer's email was also blunt about Microsoft's shortcomings. "It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO [total cost of ownership], our lack of a sexy vision at times, and many other difficulties ... Customers constantly evaluate other desktop platforms, [but] it would be so much work to move over that they hope we just improve Windows rather than force them to move. In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago." Higher TCO huh? D'oh! thanks -mike

1 0

Re: project David? (Rein Klazes)
by Kevin F. Quinn April 23, 2004

April 23, 2004

A couple of statements on their web site: "One of the problems of the MS Windows OS is that it is subject to crash applications and itself. While studying the Microsoft Windows OS, we found the design flaw that causes this problem." _the_ design flaw? Marketing hype. It seems from later statements that they're talking about Microsoft's decision to relocate large sections of previously user-land code into the kernel (in particular, GDI), much commented on when NT went from 3.51 to 4.0. Later on, when comparing themselves to WINE, they state: "SpecOpS Labs believes, that [WINE] suffers from a major architectural flaw, which requires a major rewrite of the WINE code. The WINE project had been too faithful in reverse engineering the Windows Environment Subsystem, that it also inherited the architectural flaws in Windows. Among these flaws is when a problem is experienced by an application running in a Window, it can crash the whole operating system, causing it to either hang or reboot. " I think I'm right in saying an application using WINE _cannot_ crash the kernel, any more than any other user-land app. Also, from what I understand, it is _not_ WINE policy to re-implement Win32 bug-for-bug (since Microsoft do fix bugs, this is sensible). It looks like their project is on the search for large-scale funding. Assuming they can't distribute WINE code (good ol' GPL), they have a lot of work to do. Their "architecture" basically means full Win32 API implementation, with what looks like a priviledged kernel component ("WACS Driver") to interface to priviledged objects in the kernel. Incidentally, that kernel component better be rock-solid or they _will_ be able to kill the kernel from Windows apps in their subsystem... They do claim to have a "prototype" - I would guess that's either a modified WINE, or if newly written only implements a very small subset of the Win32 API. It will be interesting to see how quickly they get product to market, and when they do to see how much WINE code is used (which will need object-code comparisons, of course). One of their headline comments is: "David is not a reinvention of the wheel. It takes the best of breed pieces from previous attempts to simulate the Windows Subsystem, and integrates them into a single product." We shall see. There's a lot of "validation" garbage on the site, which to my mind isn't worth the paper it isn't printed on. It could well be they'll just raise loads of cash, then later crash and burn when they realise quite how much effort they need to spend to reimplement everything - or maybe when they realise they'll be violating the GPL if they lift WINE code. Kev.

1 0

Re: Re: i810 audio fixes 1/2
by chmorgan＠charter.net April 22, 2004

April 22, 2004

>like "play this wave file". The major remaining drawback >is latency; >click on button in app, hear sound 2 seconds later when >scheduler This is why we have sound servers like jack. Any delay is likely due to not having a fully callback based architecture in the app. >Maybe a better thing to do is rewrite arts/esd library >interfaces to >omit the daemons altogether. That way the daemons can go >away, but the >existing applications can be trivially migrated. I've heard that arts is being phased out from kde use in the near future. I'm not sure what might replace it though. Chris

6 7

Re: wine/include winternl.h
by Lionel Ulmer April 22, 2004

April 22, 2004

On Wed, Apr 21, 2004 at 05:21:36PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 12085 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2004/04/21 17:21:36 > > Modified files: > include : winternl.h > > Log message: > Mike McCormack <mike(a)codeweavers.com> > * add some values to the SYSTEM_INFORMATION_CLASS enumeration > > *************** > wint-sys-debug.diff (text/plain) > > Index: include/winternl.h > =================================================================== > RCS file: /home/wine/wine/include/winternl.h,v > retrieving revision 1.74 > diff -u -r1.74 winternl.h > --- include/winternl.h 16 Apr 2004 05:00:46 -0000 1.74 > +++ include/winternl.h 19 Apr 2004 06:57:43 -0000 > @@ -442,9 +442,36 @@ > SystemCacheInformation, (...) > > Patch: http://cvs.winehq.org/patch.py?id=12085 > > Old revision New revision Changes Path > 1.77 1.78 +33 -1 wine/include/winternl.h > Is this a VERY verbose Changelog or the new way to see the patch in the commit log :-) ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 1

Winetest publishers
by Dimitrie O. Paun April 22, 2004

April 22, 2004

Hi Brian, A few more thoughts on the multiple publisher idea, and what we need to do on the server side. So, let's assume we have a number publishers out there. On server side we need to: 1. Maintain a pool of published winetest.exe's 2. Implement policy to serve from that pool (on a poll even) 1. The pool The pool will have to be maintained in a persistent manner to survive server reboots. It needs to get saved in a file. It should be managed as such: When a publish event happen we do: - check that the publisher id exists in publishers.txt file (1) - reject the event if not - check that it's really the publisher who publishes (2) - reject if not - check that the new BUILD_ID is >= than the current BUILD_ID - reject if not - if greater, reset the pool - add the published test to the pool - return 'OK' NOTES: (1) I suggest this format for publishers.txt <publisher-id>:<publisher-base-url> (2) We need to check that someone doesn't want to polute the pool. I suggest checking for the existance of: <publisher-base-url>/<published-file> 2. The Policy The sky's the limit. For now, we can just pick one at random from the pool. -- Dimi.

2 1

Invalid curdrive and curdir
by jeffl April 22, 2004

April 22, 2004

All, I am tracking a problem where an install program with an exception trying to access 0x00000000 memory. I have tracked the problem down to files/drive.c in DRIVE_GetCurrentDirectory where dos_cwd contains 0 and is used in ret = strlenW(dos_cwd) + 3; /* length of WHOLE current directory */ It seems that DRIVE_GetCurrentDrive returns a value greater than MAX_DOS_DRIVES (25) and then return DOSDrives[drive].dos_cwd; where dos_cwd=0; pTask->curdrive and pTask->curdir appear not to be set or invalid. Now it seems that a check for null ptr in DRIVE_GetCurrentDirectory is order ie. UINT ret; LPCWSTR dos_cwd = DRIVE_GetDosCwd( DRIVE_GetCurrentDrive() ); static const WCHAR driveA_rootW[] = {'A',':','\\',0}; if (dos_cwd == 0) { ERR("dos_cwd returned 0 instead of pointer to current working directory\n"); dos_cwd = "\0"; /* make a valid string for strlenW */ } ret = strlenW(dos_cwd) + 3; /* length of WHOLE current directory */ if (ret >= buflen) return ret + 1; but what would be a good value for dos_cwd? I am interested in what causes the pTask->curdrive to be greater than 25 and curdir to be set to ???????? as shown below. Wine-dbg>p *pTask {hNext=0, ss_sp=0, nEvents=0, priority=0, unused1=0, hSelf=4143, hPrevInstance=0, unused2=0, ctrlword8087=0, flags=16, error_mode=0, version=1024, hInstance=0, hModule=0, hQueue=4199, hParent=0, signal_flags=0, sighandler=0x00000000, userhandler=0x00000000, discardhandler=0x00000000, int0=0x00000000, int2=0x00000000, int4=0x00000000, int6=0x00000000, int7=0x00000000, int3e=0x00000000, int75=0x00000000, compat_flags=0, unused4="", teb=0x4002f000, unused5="", hPDB=4151, dta=272040064, curdrive=254, curdir="????????", nCmdShow=1, hYieldTo=0, dlls_to_init=0, hCSAlias=4167, thunks={0, 21584, 0, 8, 16, 0, 0, 0, 24, 0, 0, 0, 32, 0, 0, 0, 40, 0, 0, 0, 48, 0, 0, 0, 56, 0, 0, 0, 0, 0, 0, 0}, module_name="", magic=17492, hEvent=0x0000000c, pdb={int20=8397, nextParagraph=0, reserved1=0, dispatcher="?", savedint22=0x00000000, savedint23=0x00000000, savedint24=0x00000000, parentPSP=0, fileHandles="????????????????????", environment=4159, saveStack=0, nbFiles=20, fileHandlesPtr=272039960, hFileHandles=0, reserved3={0, 0, 0, ...}, ...}...} Wine-dbg> Jeff Latimer

1 0

Anyone working on WSALookupServiceBegin() and WSALookupServiceNext?
by Robbert Xerox April 22, 2004

April 22, 2004

Simple question : is anyone working on WSALookupServiceBegin() and WSALookupServiceNext() in winsock? ____________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html

1 0

richedit - anybody trying to do it ?
by Krzysztof Foltman April 22, 2004

April 22, 2004

Hi, Just out of curiosity: is anyone already actively developing a (supposedly) fully featured richedit control ? The current version looks like a plain editor combined with RTF reader... -- Chris

5 5

speed up oleaut32: vartest
by Chris Morgan April 21, 2004

April 21, 2004

*dlls/oleaut32/tests/vartest.c: Chris Morgan<cmorgan(a)alum.wpi.edu> Skip over most of the unused variant types to speed up the variant tests. This look like a reasonable way to speed up the variant tests without losing testing functionality? Chris

1 1

RE: Fix for GetFileTime API - Incorrect Modified/Last access Time .
by Krishna Murthy April 21, 2004

April 21, 2004

We have Team Developer Product for MS Windows which has its own language and in the process of verifying on Wine. Few of test cases working on Windows are failing in Wine. Hence I have submitted this patch. Yes, since Pre-1970 times are not going to work on Unix anyway we could release note this in our product. Thanks for your input on this. Krishna -----Original Message----- From: Alexandre Julliard [mailto:julliard(a)winehq.org] Sent: Wednesday, April 21, 2004 6:16 PM To: Krishna Murthy Cc: wine-devel(a)winehq.org Subject: Re: Fix for GetFileTime API - Incorrect Modified/Last access Time. Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > Change of argument type DWORD to LONGLONG of function > RtlSecondsSince1970ToTime() and RtlSecondsSince1980ToTime() to accept > negative values. These are Windows APIs, you cannot simply change their arguments, we have to be compatible. Pre-1970 times are not going to work right on Unix anyway; what do you need them for? -- Alexandre Julliard julliard(a)winehq.org

1 0

winetest oddity - oleaut32: VarTest
by Chris Morgan April 21, 2004

April 21, 2004

I've been looking at vartest, specifically to speed it up since the tests I added for VarMod() are the cause of its current excessive length. Something appears to be a bit different with mingw compiled tests vs. MSVC compiled tests. Under wine these tests run just fine, three fixmes popup. I get two failures when running the oleaut32 vartest on my XP machine. This is compiled with vc6sp5+processor pack. Running the mingw compiled test from Paul Millar, http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-20040421-100…, there are thousands of failures for the same test. Anyone have a clue what might be causing this? One thing that came to mind was that there are int64's used in the ole code, the test won't compile cleanly under vc6 without the processor pack. Maybe mingw is messing up the int64's? Chris

1 0

Re: Fix for GetFileTime API - Incorrect Modified/Last access Time.
by Alexandre Julliard April 21, 2004

April 21, 2004

Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > Change of argument type DWORD to LONGLONG of function > RtlSecondsSince1970ToTime() and RtlSecondsSince1980ToTime() to accept > negative values. These are Windows APIs, you cannot simply change their arguments, we have to be compatible. Pre-1970 times are not going to work right on Unix anyway; what do you need them for? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Wine detect patch (ignore previous whitespace patch)
by Ferenc Wagner April 21, 2004

April 21, 2004

Jakob Eriksson <jakov(a)vmlinux.org> writes: > (Sorry about the linespace noise after print_version(), > emacs seems to change stuff behind my back when I save.) Hi Jakob, You'd better educate Emacs about your ways, otherwise all your patches will be full of whitespace changes making them very hard to review. The indentation isn't consistent, but if you want to fix this, do so in a separate patch, please! > + static const TCHAR wine[128] = {"Wine"}; I think we could use static const char wine[] = "Wine"; instead. No wide characters in winetest for now. But see below! > + if (running_on_wine ()) { /* Make a an obvious signature for Wine */ > + ext = 1; > + > + ver.dwMajorVersion = 1; > + ver.dwMinorVersion = 1; > + ver.dwBuildNumber = 1; > + ver.dwPlatformId = 1; > + strncpy (ver.szCSDVersion, wine, sizeof (wine)); > + } > + I think we can do better. A single line like xprintf (" bRunningUnderWine=%d\n", running_under_wine ()); as the first line of print_version() would do a perfect job without masking anything else. -- Feri.

2 1

Re: Winetest results uploaded... where?
by Ivan Leo Murray-Smith April 21, 2004

April 21, 2004

On http://test.winehq.org/data/200404192305/ the "next build" and "previous build" buttons are broken. I get a error message, saying "You don't have permission to access /site on this server." Ivan.

4 12

Re: White-space patch for programs/winetest/main.c
by Alexandre Julliard April 21, 2004

April 21, 2004

Jakob Eriksson <jakov(a)vmlinux.org> writes: > This is also an example of how the file can store its indent > preference in a comment. > > I will run this when I'm done editing the file: > FILENAME=main.c && `grep indent $FILENAME` $FILENAME I don't think that's a good idea at all. It would require everybody to do that every time they make a change to that file, otherwise there will be plenty of spurious whitespace changes and conflicts. Please don't do that. -- Alexandre Julliard julliard(a)winehq.org

2 2