Re: Request for winetesting volunteers
Chris Morgan [EMAIL PROTECTED] writes: the winetest results are sent back to winehq and can be accessed via http://test.winehq.org/data/ Pretty formatting of the results is coming soon ;-) Do you mean somebody's already working on it or that I should do it eventually? I'm back from the summer school but the examination period started here, so I can do some work again. It would even make more sense now that the dust settled. Have you perhaps got concrete ideas? It would be interesting to hear the experience of people using/working from the reports. What's missing, what should be easier? Anyway, thanks for the good work, guys! -- Feri.
Re: Request for winetesting volunteers
On Sat, May 29, 2004 at 09:22:02AM +0200, Ferenc Wagner wrote: work again. It would even make more sense now that the dust settled. Have you perhaps got concrete ideas? So here is what's left to do: 1. Finish the metadata-in-winetest patch 2. Arrange the reports on WineHQ 3. Maybe add script signing/checking to winrash/service.cgi (this is optional, and just a nice-to-have ATM). I'm sure you know precisely what's required for (1), so I'll focus on (2). For that, I was thinking we need a page (http://www.winehq.org/site/status_testing) that is organized into two sections (just like our home page, with About Wine/Latest News). The first section (let's call this Wine Testing) would contain a short description of our testing framework, what it does, how you can sign up to become a tester, pointers to where the tests can be downloaded from, etc. This section is obviously hand crafted. The second section (call it Test Reports) would contain links to the various reports generated by dissect/gather. This section would me automatically generated. Ideally the section would contain the current and the previous month (in the form of a calendar, as reported cal(1)), with the applicable days being links to the reports. At the bottom of the section we should have a link to a page listing all historical reports (again if possible in the same cal(1) format). Looking at this, it now seems better if we arrange these two sections one besides the other, like About Wine and Weekly Newsletters on our home page. Namely, Wine Testing will be in the middle, while Test Reports will be a narrow section to the right of the page, with the month listed one below the other in decressing order (and BTW, we could display more than 2 months at a time). How does this sound? -- Dimi.
Re: wine/ loader/main.c loader/glibc.c loader/Make ...
Am Freitag, 28. Mai 2004 23:59 schrieb Mike Hearn: On Fri, 28 May 2004 15:59:23 -0500, Alexandre Julliard wrote: Log message: Initial version of the Wine preloader, used to reserve memory areas at startup. Based on the work of Mike McCormack. [snip] If you observe any odd breakage please let us know. keep on truckin' -mike Hello, i don't know if it is releated to his patch, but wine does not longer start wineserver on startup. My second last cvs update was 14h (~7:30 PM UTC) ago. This build did not exhibit the problem. wine GetAcceptLanguagesA.exe wine: could not exec wineserver If i start wineserver -p before wine it works as expected. My system is SuSE Linux 9.0 Most packages are uptodate but not the kernel rpm -qa k_athlon k_athlon-2.4.21-202 I will do regression testing in the evening if it is required. Bye Stefan
Re: Print thread ID in 16-bit snoop traces in the noargs case
On Fri May 28 23:42:14 BST 2004, you wrote: Mike Hearn [EMAIL PROTECTED] Print thread ID in 16-bit snoop traces in the noargs case Too late: http://cvs.winehq.org/patch.py?id=12478 Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Upcoming breakage warning
On Fri, 21 May 2004 12:58 am, Francois Gouget wrote: On Thu, 20 May 2004, Mike Hearn wrote: [...] This is no longer true. According to a Red Hat kernel engineer, you can use setarch i386 wine to switch it back to the 3/1 split while we fix it in the Wine code. Don't we have the same problem with the 3/1 split? If I remember correctly we can get into trouble if anything gets loaded above the 2G mark, depends on the application. As one who has been bitten by this for several years I can say that many (Most) windows apps dont care where their pointers point. Simply changing ADDRESS_SPACE_LIMIT does actually work in many cases and making this configurable will make wine usable in these environment even if it breaks some naughty applications that depend on the 3G/1G split!! From my recollection this limit is only tested for heap allocation which is specifically provided by and anonymous mmap, presumably for performance purposes. The proposed solution for this has been to prevent mmap from allocating over the 3GB mark by reserving any free space over that limit with a chain of mmap calls. At least under Solaris there would appear to be two other nicer ways to achieve the same result. 1. Allocate the windows heap with a call to libc malloc which at least under Solaris maps memory from the stack top upward in memory. 2. For each mmap call locate a suitable unmapped memory area and then mmap FIXED that area, a technique already used successfully in the Solaris specific mmap code. Of course none of this will prevent DSOs being loaded above the top of memory but. from the wine codebase only the heap seems to be at issue. For what it's worth I can't see Microsoft retaining this architecture since the windows split is not likely to be the same into the future for example with AMD64 and probably was different even for Alpha. I also acknowledge that Alexandre and I disagree on this particular point. Bob
Re: Print thread ID in 16-bit snoop traces in the noargs case
On Sat, 2004-05-29 at 11:49 +0200, Rein Klazes wrote: Too late: http://cvs.winehq.org/patch.py?id=12478 Haha :) Golden rule of Wine hacking: before writing a patch, update! OK, well at least we didn't duplicate anything hard
Re: EnumDateFormats patch
Alexandre Julliard wrote: Wililam [EMAIL PROTECTED] writes: Here is the ChangeLog entry: * dlls/kernel/lcformat.c William Lahti [EMAIL PROTECTED] - Implemented the EnumDateFormatsW function and vastly improved upon the EnumDateFormatsA function. This stuff clearly needs to be stored as data in the nls resource files, not in the code. The original EnumDateFormatsA function had the information in the code. There was simply much less. If I knew how to store *ALL* posible combination in the NLS files rather than the default, I would gladly implement them.
Tainted code in User32?
Hello this line: However, disassembling NT implementation (WIN32K.SYS) reveals that. in http://source.winehq.org/source/windows/win.c#L845 was introduced in to winehq by the following patch: http://cvs.winehq.com/cvsweb/wine/windows/win.c.diff?r1=1.61r2=1.62 Does this not violate a clean rooming the implementation? The ReactOS code is a derived work of the Wine code in the case and if soon then we have to remove it. Thanks Steven __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/
Re: Tainted code in User32?
However, disassembling NT implementation (WIN32K.SYS) reveals that. ... Does this not violate a clean rooming the implementation? The ReactOS code is a derived work of the Wine code in the case and if soon then we have to remove it. Whoa! Slow down there John Wayne! Disassembly is another healthy part of reverse engineering. And without reverse engineering, you wouldn't have the beautiful thing known as WINE here before you. There were no algorithms lifted from the Windows code, just the discovery of some undocumented functionality.
broken mingw build
This patch
http://cvs.winehq.org/patch.py?id=12495
seems to have broken the mingw build, currently getting
i386-mingw32msvc-gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__
-D_REENTRANT -Wall -pipe -fno-strength-reduce -mpreferred-stack-boundary=2
-fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c
{standard input}: Assembler messages:
{standard input}:124: Error: unknown pseudo-op: `.previous'
{standard input}:135: Error: unknown pseudo-op: `.previous'
{standard input}:145: Error: unknown pseudo-op: `.previous'
{standard input}:155: Error: unknown pseudo-op: `.previous'
{standard input}:165: Error: unknown pseudo-op: `.previous'
make[2]: *** [interlocked.o] Error 1
