- wine-devel - winehq.org

Re: Remove debugmsg from guides
by Dimitrie O. Paun 25 Apr '04

25 Apr '04

On Sun, 25 Apr 2004, Ivan Leo Murray-Smith wrote: > Please let me know if something isn't OK. A few points: -- I find the change confusing. There's no WINEDEBUG channel. I think most should just change from debugmsg -> debug -- Please provide only one .diff file. Multiple diffs are not necessary, and makes reviewing and applying so much more difficult. -- It would be nice if the diff would be either inlined or attached as text/plain. Inlining is prefered, this way people can quote easily when replying. -- Dimi.

1 0

Re: Remove debugmsg from guides
by Eric Pouech 25 Apr '04

25 Apr '04

Ivan Leo Murray-Smith a écrit : > With this all unneeded references to debugmsg should be gone. Just one note, in > debugger.sgml I found this > [MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 957636538 > "Auto"=dword:00000001 > "Debugger"="winedbg --debugmsg -all %ld %ld" > As I don't know what it's meant to be now, I've left it, if it should change, > let me know. > Please let me know if something isn't OK. > > Ivan. this should be changed into "Debugger"="winedbg %ld %ld" (the issue is that the debugger will be inheriting the parent's debug channel, while this setting was turning off all debugging channels from debugger itself). A+

1 0

Re: PATCH: silence strict aliasing in dlls/opengl32
by Lionel Ulmer 25 Apr '04

25 Apr '04

> Not sure how to regenerate the opemngl_ext.c file. You need the extension registry CVS (you can find it here http://oss.sgi.com/projects/ogl-sample/ - no idea where the exact CVS informations are). After, do 'make_opengl PATH_TO_EXTENSION_DIR 1.2' where PATH_TO_EXTENSION_DIR points to the '<OGL-SAMPLE-ROOT>/main/doc/registry/specs/' directory). Anyway, if it can wait, it will be updated the next time I generate the file. Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

dlls/d3d8/shader.c
by Marcus Meissner 25 Apr '04

25 Apr '04

Hi, I was just fixing this code, but I wonder why floorf(s0->w) is overwritten right next with tmp_f = powf(2.0f, s0->w); What is the right version? Ciao, Marcus void vshader_expp(D3DSHADERVECTOR* d, D3DSHADERVECTOR* s0) { float tmp_f = floorf(s0->w); DWORD tmp_d = 0; tmp_f = powf(2.0f, s0->w); tmp_d = *((DWORD*) &tmp_f) & 0xFFFFFF00;

2 1

Bad string handling in PRINTDLG_UpdatePrintDlg?
by Francois Gouget 24 Apr '04

24 Apr '04

In PRINTDLG_UpdatePrintDlgA() in dlls/commdlg/printdlg.c we do: ... LPPRINTER_INFO_2A pi = PrintStructures->lpPrinterInfo; ... pi->pPortName = "FILE:"; And in PRINTDLG_UpdatePrintDlgW() we do: ... LPPRINTER_INFO_2W pi = PrintStructures->lpPrinterInfo; ... static WCHAR file[] = {'F','I','L','E',':',0}; pi->pPortName = file; ... Now in gcc all string literals are read-only, even if you declare them as char* foo="bar", *foo='\0' will cause a segfault. So in the Ansi version we point pPortName to a read-only string. But if the application gets hold of that pointer we have no garantee that it won't expect to be able to modify that string: pPortName is an LPSTR. (this is a case where -Wwrite-strings will complain) And in the Unicode case we point pPortName to a static writable buffer. But in this case if the application writes in our buffer its contents is going to be messed up forever. However I don't know this code at all. So I'm asking, shoudln't we make a copy of these strings? Which also raises the ugly issue of later freeing the corresponding memory buffer... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

1 0

Idea to fight spam
by Ivan Leo Murray-Smith 24 Apr '04

24 Apr '04

What about having a link to this page somewhere on winehq? Maybe on the mailing lists page? http://www.hostedscripts.com/scripts/antispam.html Ivan.

2 1

Re: Docu: mention piping for debugmsgs
by Ferenc Wagner 24 Apr '04

24 Apr '04

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > Make people know how to reduce log size, using pipes. Hi Andi! Two notes: 1. The --debugmsg option is deprecated, people should use the WINEDEBUG environmental variable instead. 2. Won't the pipe block until you read from it, then give you all the data ever written? -- Feri.

1 0

winetest: build & publishing
by Dimitrie O. Paun 24 Apr '04

24 Apr '04

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 24 Apr '04

24 Apr '04

"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 24 Apr '04

24 Apr '04

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

Window management protocol extensions
by Mike Hearn 24 Apr '04

24 Apr '04

The latest WM problems caused by Metacity preventing windows from being moved offscreen prompted to raise the issue of having a Wine specific extension to the NETWM (EWMH) protocol into which we can easily add whatever semantics we need to map win32 windowing to X windowing more easily. The idea would be that we have a new property/set of properties we can mark windows with, _NET_WM_WINDOWS_EMULATION for instance, and standards compliant window managers will take note and not do things that break us. Short of actually doing all our own window management, this is probably the best way to fix the obscure bugs caused by different interpretations WMs have of what various hints mean. The current NETWM border hints are semantic not presentational, so we cannot rely on particular intepretations. The MWM hints are even worse - they are apparently undocumented, and most modern WM authors consider them deprecated. Thanks to their undocumentedness, WMs vary in their interpretation of these too: http://bugs.kde.org/show_bug.cgi?id=73294 So, I'd like to start gathering ideas on what sort of things we'd like to have in the NETWM spec, seeing as how many WMs conform to it these days. First up is a way to ensure the WM doesn't attempt to keep the window onscreen of course :) Other things we probably want are related to border styles, an absolutely crystal-clear no-wriggling-possible equivalent to PPosition as apparently the wording of the ICCCM allows WM authors to ignore this if they want. We might also want to look at where we use unmanaged windows and see if we can replace them with the use of managed windows+hints. We can probably hack around the lack of these things for now, but being able to use these hints where possible will probably keep a lot of us from going grey-haired early :) thanks -mike

2 2

Re: Fix for test of CreateFileMapping in dlls/kernel/tests/file.c
by Jakob Eriksson 24 Apr '04

24 Apr '04

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 24 Apr '04

24 Apr '04

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 24 Apr '04

24 Apr '04

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 24 Apr '04

24 Apr '04

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 23 Apr '04

23 Apr '04

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 23 Apr '04

23 Apr '04

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 23 Apr '04

23 Apr '04

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 23 Apr '04

23 Apr '04

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 23 Apr '04

23 Apr '04

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 23 Apr '04

23 Apr '04

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 23 Apr '04

23 Apr '04

======= 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

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

23 Apr '04

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 23 Apr '04

23 Apr '04

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 23 Apr '04

23 Apr '04

>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: Winetest: outstanding issues (BUILDING)
by Dimitrie O. Paun 22 Apr '04

22 Apr '04

> 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

Re: wine/include winternl.h
by Lionel Ulmer 22 Apr '04

22 Apr '04

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 22 Apr '04

22 Apr '04

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 22 Apr '04

22 Apr '04

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 22 Apr '04

22 Apr '04

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 22 Apr '04

22 Apr '04

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 22 Apr '04

22 Apr '04

*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 22 Apr '04

22 Apr '04

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@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 22 Apr '04

22 Apr '04

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 22 Apr '04

22 Apr '04

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 21 Apr '04

21 Apr '04

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 21 Apr '04

21 Apr '04

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 21 Apr '04

21 Apr '04

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

i810 audio fixes 1/2
by Roderick Colenbrander 21 Apr '04

21 Apr '04

Hi, This is the first of two patches that will fix some problems on soundcards using the i810 audio codec. The main probem with this soundcard is that it only supports a frequency of 48kHz in 16bit stereo mode. This first patch to dsound queries if the card supports 16bit and if so it uses it, else it uses 8bit. Further it also detects if the card supports stereo or not. The patch was inspired by one from transgaming to rewind but that patch did a bit the opposite (defaulting to 8bit ..). Roderick Colenbrander

8 18

Re: Widl: Conditionals, Dotted Versions, Handles
by Robert Shearman 21 Apr '04

21 Apr '04

>>> Ove Kaaven <ovek(a)arcticnet.no> 04/19/04 22:50 PM >>> man, 19.04.2004 kl. 17.03 skrev Robert Shearman: > > > Doesn't the "version" rule already handle this? > > > > It would appear not. The 'version' type is declared > as a number further up > > It's declared that the rule *returns* a number, you mean. The actual > rule is defined as > > version: > aNUM { $$ = MAKELONG($1, 0); } > | aNUM '.' aNUM { $$ = MAKELONG($1, $3); } > ; > > Now if this somehow returns 0, then you need to fix that rule, not add > another rule which makes a version of e.g. "1.2.3.4" valid syntax (but > still return a wrong result). Ok, I missed that before. I suspect it doesn't work properly because it correctly matches aNUM and attempts to convert it to a number and succeeds (but returning 0). We should re-arrange that rule so that the dotted version matches first and falls back to the second version if there is no '.'. However, I doubt I will have the time to resend that patch for a while. Rob

1 0

winetest reporting http://test.winehq.org/data/200404192305/
by Jakob Eriksson 21 Apr '04

21 Apr '04

First of all, the report on http://test.winehq.org/data/200404192305/ is VERY pretty. Almost get misty eyed here. ;-) Things are coming along very nicely. Anyway, I am curious what happens if I run winetest.exe in Wine. Will it get reported accurately as Wine, or will it get misrepresented in for instance the XP column? regards, Jakob

4 7

Serial and pread
by Izak Burger 21 Apr '04

21 Apr '04

Hello, I'm currently debugging a problem with serial comms over wine, and I see that when a serial device is opened (in server/serial.c) the serial_get_info function returns a type of FD_TYPE_DEFAULT, which in turn causes the serial device to be read from and written to with pread and pwrite in dlls/ntdll/file.c. Will this even work? I mean, how can you write or read to a serial port while using an offset? In any case, I changed the code to return FD_TYPE_SOCKET instead ( I thought a serial port is probably a lot more like a socket than it is a file) and now I get some activity on the serial port (before there was nothing), but it still does not work as it should. Not to worry, I just wanted to ask if all the trouble people were having with async serial comms might not be related to this? Any ideas greatly appreciated. regards, Izak

3 7

20040408 on freebsd4.9
by eternal 21 Apr '04

21 Apr '04

hello all... been stumped on this one for about a week now... been on the wine-users list trying to get this worked out, and mr. pfeifer was even nice enough to lend some advice that yeilded some build progress, but it (wine) seems to hate the idea of running on my puter... here's the info...: tyan tiger 100 dual p3-850 512MB ECC ati radeon 8500LE FreeBSD4.9-RELEASE and below is the output from env (initial login as vertigo, startx, open console, su root, env): USER=vertigo MAIL=/var/mail/vertigo OLDPWD=/home/vertigo HOME=/root GTK_RC_FILES=/usr/X11R6/etc/gtk/gtkrc:/home/vertigo/.gtkrc-1.2-gnome2 PAGER=more ENV=/home/vertigo/.shrc COLORTERM=gnome-terminal LOGNAME=vertigo WINDOWID=25165870 TERM=xterm BLOCKSIZE=K GNOME_DESKTOP_SESSION_ID=Default SESSION_MANAGER=local/eTernaL.null.org:/tmp/.ICE-unix/620 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin DISPLAY=:0.0 DESKTOP_STARTUP_ID= XAUTHORITY=/home/vertigo/.Xauthority SHELL=/bin/csh PWD=/home/vertigo/winecvs EDITOR=vi HOSTTYPE=FreeBSD VENDOR=intel OSTYPE=FreeBSD MACHTYPE=i386 SHLVL=1 GROUP=wheel CC=/usr/local/bin/gcc33 LD_LIBRARY_PATH=/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.3.1 first off, i get all the recent wine packages from cvs, i save it at /home/vertigo/winecvs, and again at /home/vertigo/winebackup. cd winecvs as vertigo, ./tools/wineinstall returns "not found". ls -la tools shows that is there... su root, check env (hence it's inclusion above), ./configure && make depend run fine. from past experience, i do the following make > winemake.txt after about 2700 lines of output, make stops with: rm -f winepath && ln -s ../../tools/winewrapper winepath /usr/local/bin/gcc33 -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o gui.o gui.c /usr/local/bin/gcc33 -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o main.o main.c /usr/local/bin/gcc33 -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o send.o send.c /usr/local/bin/gcc33 -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o util.o util.c ../../tools/winebuild/winebuild -o winetest.exe.dbg.c --debug -C. gui.c main.c send.c util.c /usr/local/bin/gcc33 -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o winetest.exe.dbg.o winetest.exe.dbg.c ../../tools/bin2res -f -o wine.ico ./gui.rc ./maketest ../.. advapi32_test.exe$(DLLEXT) comctl32_test.exe$(DLLEXT) gdi32_test.exe$(DLLEXT) kernel32_test.exe$(DLLEXT) msvcrt_test.exe$(DLLEXT) netapi32_test.exe$(DLLEXT) ntdll_test.exe$(DLLEXT) oleaut32_test.exe$(DLLEXT) rpcrt4_test.exe$(DLLEXT) shell32_test.exe$(DLLEXT) shlwapi_test.exe$(DLLEXT) urlmon_test.exe$(DLLEXT) user32_test.exe$(DLLEXT) wininet_test.exe$(DLLEXT) winmm_test.exe$(DLLEXT) winspool.drv_test.exe$(DLLEXT) ws2_32_test.exe$(DLLEXT) > winetest.rc || ( rm -f winetest.rc && exit 1 ) cp ../../dlls/advapi32/tests/advapi32_test.exe.so advapi32_test.exe.so && strip advapi32_test.exe.so cp ../../dlls/comctl32/tests/comctl32_test.exe.so comctl32_test.exe.so && strip comctl32_test.exe.so cp ../../dlls/gdi/tests/gdi32_test.exe.so gdi32_test.exe.so && strip gdi32_test.exe.so cp ../../dlls/kernel/tests/kernel32_test.exe.so kernel32_test.exe.so && strip kernel32_test.exe.so cp ../../dlls/msvcrt/tests/msvcrt_test.exe.so msvcrt_test.exe.so && strip msvcrt_test.exe.so cp ../../dlls/netapi32/tests/netapi32_test.exe.so netapi32_test.exe.so && strip netapi32_test.exe.so cp ../../dlls/ntdll/tests/ntdll_test.exe.so ntdll_test.exe.so && strip ntdll_test.exe.so cp ../../dlls/oleaut32/tests/oleaut32_test.exe.so oleaut32_test.exe.so && strip oleaut32_test.exe.so cp ../../dlls/rpcrt4/tests/rpcrt4_test.exe.so rpcrt4_test.exe.so && strip rpcrt4_test.exe.so cp ../../dlls/shell32/tests/shell32_test.exe.so shell32_test.exe.so && strip shell32_test.exe.so cp ../../dlls/shlwapi/tests/shlwapi_test.exe.so shlwapi_test.exe.so && strip shlwapi_test.exe.so cp ../../dlls/urlmon/tests/urlmon_test.exe.so urlmon_test.exe.so && strip urlmon_test.exe.so cp ../../dlls/user/tests/user32_test.exe.so user32_test.exe.so && strip user32_test.exe.so cp ../../dlls/wininet/tests/wininet_test.exe.so wininet_test.exe.so && strip wininet_test.exe.so cp ../../dlls/winmm/tests/winmm_test.exe.so winmm_test.exe.so && strip winmm_test.exe.so cp ../../dlls/winspool/tests/winspool.drv_test.exe.so winspool.drv_test.exe.so && strip winspool.drv_test.exe.so cp ../../dlls/winsock/tests/ws2_32_test.exe.so ws2_32_test.exe.so && strip ws2_32_test.exe.so LD_LIBRARY_PATH="../../libs/unicode:$LD_LIBRARY_PATH" ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -fogui.res gui.rc *** Error code 1 Stop in /usr/home/vertigo/winecvs/programs/winetest. *** Error code 1 Stop in /usr/home/vertigo/winecvs/programs. *** Error code 1 Stop in /usr/home/vertigo/winecvs. -------------------------------------------------- at this point, i'm at a loss... i've made sure that the kernel had all the options that wine wants, because i did them when i set smp and apic_io... if anyone out there can help me out with this, it would be much appreciated. thanks in advance. shaun

1 0

EM_UNDO message handling for single line edit controls
by Santosh Siddheshwar 21 Apr '04

21 Apr '04

Hi, I think there is a defect in the handling of EM_UNDO message for single line edit controls. If you go by what MSDN says this message should always return TRUE. But in EDIT_EM_Undo method (controls/edit.c) we are checking whether the style of the edit control is Read Only and returning FALSE if it is Read Only. My question is why should a read only edit control not be allowed to handle WM_PASTE, EM_UNDO and similar messages? Regards Santosh Siddheshwar ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

Re: winetest: timeout & no consoles
by Dimitrie O. Paun 21 Apr '04

21 Apr '04

On April 19, 2004 6:27 pm, Ferenc Wagner wrote: > - force a 2-minute timeout on individual tests. Nice. I hope it's not too short. Does dissect & gather correctly recognize (and reflect on the HTML page) these timeouts? I'd be nice (and important :)) to know about them. -- Dimi.

2 2

Strnage fff-by-one error
by Dimitrie O. Paun 20 Apr '04

20 Apr '04

Folks, This is weird one. The Winelib build of AbiWord exposes an off-by-one error. However, the Win32 build of AbiWord works perfectly (without this very problem) under Wine/ReactOS/Windows. AbiWord builds flawlessly under Winelib, not even a warning, so my guess one of our constants is off by one. The bug must appear in their code while building it, since our code to execute the Winelib app and the Win32 app is byte for byte identical. I've attached a few screenshots to demonstrate what happens when you open a menu/dialog/etc and then you close it. Namely, the invalidation (or rather painting) is off by one at right & bottom of the invalidated rectangle. -- Dimi.

4 4

Re: RFH: winetest testing
by Mehmet YASAR 20 Apr '04

20 Apr '04

> 4. Programme stops on "user32:input" (the progressbar is at about 90%) Sorry, I made a mistake. I thought tests stopped on "user32:input" whereas there were running. After waiting I see a timeout error and a dialog box asking to send data to server.

1 0

Re: Replace winedefault.reg with wine.inf in README, README.it and PACKAGING
by Lionel Ulmer 20 Apr '04

20 Apr '04

On Tue, Apr 20, 2004 at 09:14:28PM +0200, Ivan Leo Murray-Smith wrote: > As in subject. > License: LGPL * An initial set of registry entries. The current Wine standard is to use the regedit tool against - the 'winedefault.reg' file to generate a default registry. + the 'wine.ing' file to generate a default registry. The current preferred method of configuring/installing It's not 'use the regedit tool against...' but the 'rundll32 tool'. Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

DateTimeCtrl doesn't select a new date
by Felipe W Damasio (Elipse Software) 20 Apr '04

20 Apr '04

Greetings, Whe using CDateTimeCtrl and selecting a new date on that calendar thing, the date isn't selected and the widnow isn't closed. In fact, there's no way I can close that window, except closing the program. Attached is a little app Cesar Mello <cesar(a)elipse.com.br> wrote to show this problem. Also attached is the Windows' binary for testing purposes. Tested with the latest wine. Please let me know if I can provide any more info to help this fixed. Thanks in advance, Felipe

3 4

Re: wine/programs/winetest main.c Makefile.in
by Ferenc Wagner 20 Apr '04

20 Apr '04

Alexandre Julliard <julliard(a)winehq.org> writes: > ChangeSet ID: 12069 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2004/04/19 23:00:07 > > Log message: > Ferenc Wagner <wferi(a)afavant.elte.hu> > - Change to console mode so that winetest runs under WinRash. > - Move from spawnvp() to CreateProcess(). > - Force a 2-minute timeout on individual tests. > > Patch: http://cvs.winehq.org/patch.py?id=12069 Hi Alexandre, Is there a forcing reason to have oldstdout initialized to -1 besides playing safe? Not that I object it, just want to avoid grave errors in the future. -- Feri.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel