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

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

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