- Wine-Devel - list.winehq.org

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

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