Re: wine users forum registration issue
Hi, On Tue, Oct 21, 2008 at 11:37:22AM -0400, [EMAIL PROTECTED] wrote: > Hi-- > > I'm a new user of linux and wine and was looking for some help with a > database program that ALMOST runs. I found an entry on the forum with a > problem > similar to mine and wanted to comment, so I decided to register. > Unfortunately, > I was unable to get the sign-in page to recognize the characters I typed in. > I tried several times, including case-matching and entering numbers on the > number pad. In fact, I attempted it enough times to be ruled out as having > tried too often. Is there an end-run to joining the forum or some magic > insider > voodoo in place to keep fogeys like me out? (Because I could USE some voodoo > at this point with my database!) Any help would be appreciated. Thanks for your input! This is now about the 30th time (no, REALLY, this __IS__ the 30th time, or possibly even 50th!) that someone has severe issues with WineHQ forum registration, in the last 12 or so months. Could someone _please_ finally do something practical about it? Doing severe cross-posting to make sure this does get noticed, thanks. (I should be doing entirely different things ATM, but I simply cannot let this huge usability and mailbox clogging issue linger any longer, thus I'm escalating it, sorry) Thanks, Andreas Mohr
Re: Vacations
Hi, On Fri, Jan 26, 2007 at 03:38:26PM +0100, Alexandre Julliard wrote: > Now all I need is some snow... Nothing easier than that, just get back to Europe, we're drowning in it... ;) (well, Germany at least, and I'm not even sure how long this rather sizeable amount of snow will actually last) Andreas
Re: Questions concering an application I maintain
Hi, On Fri, Jan 19, 2007 at 02:12:49PM -0800, Duane Clark wrote: > Jacob Alberty wrote: > >What method is best to watch the api interaction going on in my > >application so I can see if wine is returning any weirdness that > >it shouldnt (do normal windows api spy programs work under wine?). > > SPY++, at least older versions, work fine under Wine. He most likely isn't talking about a message spy (i.e. SPY++), but about API tracers. apispy32 (IIRC) was one of the better API tracers on Windows. On Wine you just use WINEDEBUG=+relay and be done with it (unless you need further channels for specific Windows subsystems). Andreas Mohr
Re: wine kills X
Hi, On Fri, Jan 12, 2007 at 02:04:21PM +1000, Edward Savage wrote: > Also I've had a number of odd problems with directx and wine over the last > two weeks. Including a very strange one where the second time I run the > application it's speed is slower than an ant in the range of 0.7fps instead > of the normal 10fps - furthermore it's ability to grab data seems to also be > slowed. This is all while using the same resources that the application > does at full speed. I'm forced to restart my xserver every time I wish to > play it (which is twice a day) and if I don't I can kill X or even lock up > my system. Though I've been unable to work out the cause beyond 'it's > probably some thing to do with the nvidia driver'. If some one could offer > a some debugging advice on what I should be looking for it'd be very nice. Run a diff on glxinfo and xdpyinfo logs from before and after running that app? Maybe something changes, and this might hint at the problem. /var/log/Xorg.0.log doesn't display anything relevant either, I assume? Andreas Mohr
Re: wine kills X
Hi, On Sun, Jan 07, 2007 at 10:38:22AM +0100, Stefan Leichter wrote: > NVIDIA GPU GeForce4 Ti 4200 (with NVIDIA driver version 1.0-9631) > Debian Etch > > Last system modification was an update of the debian system with the availabe > patches on 05.01.2007. This is most probably the root of the problem. > > Can someone please give me an idea how to fix this problem Did you try running with OSS nvidia driver to isolate whether it's possibly an nvidia issue? And try running Wine in synchronous mode, plus more X11 related logging, to find out which call exactly causes the crash. Andreas Mohr
Re: are trace timestamps possible?
Hi, On Sat, Jan 06, 2007 at 08:46:22AM -0500, Robert Reif wrote: > Is there a way to get a time stamp in trace output kind of like we do > now for thread id? Maybe some (not so?) clever piping trick? Just create a script which detects newlines and adds a timestamp before the next line, that should be doable somehow. Obviously timing here may be less reliable than with built-in timestamps, and this unreliability might just be enough to kill your Windows Media Player tracing efforts. Andreas
ppviewer.exe MSI failure (PowerPoint 2k3): HowTo assemble a lynch mob?
Hi all, http://www.microsoft.com/downloads/details.aspx?familyid=428D5727-43AB-4F24-90B7-A94784AF71A4&displaylang=en failed to install with some nice MSI failures when I tried it last week on a current Wine version (Ubuntu package 0.9.28, I think). Does that mean that I'm entitled to assemble a capable lynch mob for the guys who were supposed to fix any and all MSI installer issues at CodeWeavers? ;) IMHO ppviewer.exe is important since those people who receive some scripted PowerPoint file (yes, that's even some "games"!) won't have much luck with OpenOffice Impress, so they're fully dependant on getting ppviewer.exe to work. Andreas Mohr
Re: ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION
Hi, On Sun, Dec 31, 2006 at 05:28:23PM +0800, Dmitry Timoshkov wrote: > Hello, > > Running RedAlert demo spits a lot of FIXMEs about converting errno 29 > (ESPIPE) to STATUS_UNSUCCESSFUL. In Linux /usr/include/asm/errno.h has > a comment /* Illegal seek */ for ESPIPE, so STATUS_ILLEGAL_FUNCTION seems > to be the best choice. > > Changelog: > ntdll: Map ESPIPE to STATUS_ILLEGAL_FUNCTION. The STATUS_ILLEGAL_FUNCTION name was rather misleading to me since it doesn't indicate at all that it's supposed to be pipe-related (however it's within the numeric range of many other pipe status codes!). So, given that this is mainly a pipe status code after all I'd say that's the best we can achieve right now. Of course, what really matters is what the receiving Win32 side *usually* expects after we encountered ESPIPE, and this might turn out to differ from your conversion ;). (is there any indication that RedAlert checks for a specific status code??) Andreas Mohr
Re: adding a data point to ALSA vs Wine sound discussion
Hi, On Tue, Dec 26, 2006 at 03:41:56AM +0100, Molle Bestefich wrote: > Adding a data point to the ALSA and Wine sound discussion. That data point unfortunately doesn't contain the ALSA version number, thus it's almost useless ;) Andreas Mohr
Re: WineLib porting project for small Windows application
Hi, On Fri, Dec 22, 2006 at 03:34:26PM -0500, Eric Rhodes wrote: > Hi Wine developers, > > My name is Eric Rhodes and I work for Schmap, Inc. (www.schmap.com). > > I'm posting this message to find out if any of you would be > interested in working with us on a Mac "porting" project for a small > Windows application (using Wine). A full project description is set > forth below. Since you mention that it is a "small" application it may be suitable to simply do a direct cross-platform port (Mac, Linux, Windows, handheld, others) via wxWidgets (just in case you haven't considered that yet). However this would be quite easy only in case of the app being written in MFC, since wxWidgets is *very* similar to MFC (it's very similar to the point of merely requiring a scripted API name string replacement in several code areas!) and thus other Win32 programming methods (raw Win32, Borland, ...) would face more issues during porting. Having said that I'm quite sure that a WineLib port is less of a pain than having to touch the whole source code in a wx port, and development work should be at least as comfortable, and due to source code availability you should be able to directly interface with Mac OS functionality on WineLib, too. Thank you very much for your offer/query, it's very much appreciated to have these kinds of queries on this list! Yours sincerely, Andreas Mohr
Re: wineshelllink: Use FreeDesktop standard to create Wine menu structure.
Hi, On Sat, Nov 25, 2006 at 07:55:38AM -0800, Dan Kegel wrote: > >[We can't just check the scripts into the wine source tree > > and require their installation.] > > Why not? If they save effort and work well, let's do it. Yes please. If they save tons of efforts via the Oh So Ugly mechanism of standardization then let's just do it. I'm tired of the non-standard behaviour of too many Linux distros. Let's forcefully change that for the better. I'd say it's fair to slightly penalize those who don't comply. Besides, xdg-utils happens to already be installed on my Debian testing box: # dpkg -l|grep xdg-utils ii xdg-utils 1.0-1 Desktop integration utilities from freedeskt Most likely that happened due to some Recommended: or Suggested: line (I'm adding most recommended packages to my install/upgrade list). I certainly didn't explicitly do it because I heard of this cool package... Andreas Mohr
Re: Looking for programmator to complete Direct3D 9.0c with GLSL in the Wine
Hi, On Wed, Nov 22, 2006 at 11:53:22AM +0100, Mirek wrote: > The aim is to prepare all apps below working under the Windows on Nvidia > GF 6XXX series, with at least 50% of speed in WinXP. There is not needed > sound after merging those patches in cvs main head. I offer 1 000 Euro > or 1 200 dollars for this work. WOW. Now that's a remarkable amount of personal involvement. Would be nice to have many more people (e.g. those who don't feel like programming things but still want to contribute somehow) offering such dedication towards getting their personal goals in various OSS projects reached. Thanks, and let's hope someone knowledgeable will follow up on this offer, Andreas Mohr
Re: Propability that application X works in wine
Hi, On Tue, Oct 24, 2006 at 11:05:10PM +0200, Stefan Dösinger wrote: > Any ideas about that? One factor in the probability calculation would be the number of Google hits for the application name (the more common, the better debugged it must be), i.e. your popularity factor. Another one would be measuring the amount of APIs used by the program and its libraries (use winedump?). Andreas Mohr
Re: Governance revisited (Wineconf report)
Hi, On Wed, Sep 20, 2006 at 08:52:45PM -0600, Vitaliy Margolen wrote: > Dr J A Gow wrote: > > How to capture these 'lost' contributions is a difficult issue. Maybe a > > centralized repository for patches could be maintained separate from the > > main > > Wine tree and with a very loose method of acceptance (maybe just ensure > > that it > > is clearly indicated what the patch is for and what version it can be > > applied > > to). This way it would be very easy for a contributor to place a patch > > somewhere > > where it is easily accessed by the community. A developer with more time > > who is > > interested in it may pick it up and clean it up for inclusion in the tree, > > but > > at least the patch is available for others to use, saving re-invention of > > the wheel. > > > Why reinvent the wheel? If such people can spend their time chasing down the > problem > and developing a fix for it, they sure can open a bug in bugzilla, describe > theproblem > and attach a patch they made. How more simple can it be? > > No patches lost, no extra places to look for. And all the information > describing the > problem. Everything in one place. And exactly this information should probably be stated in the wine-patches subscription welcome mail. "If for some reason the Wine patches you submit fail to get applied, then we'd appreciate you taking the effort of submitting your current patch as a new item at bugzilla to help us track your work properly until it's fully applied." Or, for improved visibility, even state this in the footer of every wine-patches mail sent (probably bad idea, though). Oh, and a DNS alias (or preferrably forwarder) bugzilla.winehq.org might be useful (after all it's quite common to have that site name, see e.g. bugzilla.kernel.org or bugzilla.mozilla.org etc.). Andreas -- GNU/Linux. It's not the software that's free, it's you.
Re: RFC: wine ASIO driver available for testing
Hi, On Thu, Aug 31, 2006 at 11:14:56PM -0400, Robert Reif wrote: > I just uploaded a simple wine ASIO driver to > http://bugs.winehq.org/show_bug.cgi?id=2161 for testing and feedback. Are you sure that those limited recipients were sufficient? (I don't think anyone here ever does a lot of ASIO app stuff) Might want to include http://linuxaudio.org/en/contact.html and http://ladspavst.linuxaudio.org/ people, too... Thanks for all your work on audio!! Andreas
Re: missing link??
Hi, On Sun, Aug 27, 2006 at 05:00:45PM +0200, Sabine Rode wrote: > Hallo, my tough guys, > it seems to be an miising link?? > I am newbie at ubuntu 6.06 instaöllled with the amd64 kernel > whenn i add my /etc/apt/sources.list with the both links > > deb http://wine.budgetdedicated.com/apt dapper main > and > > deb-src http://wine.budgetdedicated.com/apt dapper main > > i gwet both 404 errors. > > what is wrong? > your link or my issue? > > best regards > > sabine > germany 64bit support by Wine has been troublesome at least relatively recently (Wine, being used to run 32bit apps, additionally needs 32bit system libraries installed on the system and needs to be run in a chroot). Due to this possibly WineHQ simply doesn't offer Wine packages for a 64bit system - yet fails to do this properly :-P Please see also http://wiki.winehq.org/WineOn64bit or Google searches to find more info about current 64bit support status. (sorry, I'm not up-to-date any more on all matters of current Wine development due to working on other projects now). What's the exact status of 64bit support, anyone? [CC'd wd] Andreas Mohr
Re: FEAR Combat
Hi, On Wed, Aug 23, 2006 at 10:04:01PM -0500, EA Durbin wrote: > Also I've read that managed directx .dlls are supposed to be installed in > the global assembly cache folder (C:\WINDOWS\assembly\GAC), but wine > doesn't implement assemblies yet (Sxs.dll) as outlined in bug 5965. What you wanted to say is that due to Wine not implementing assemblies and/or the GAC directory not existing yet possibly the game installer doesn't install these DLLs yet, right? Could someone verify whether this is the case? (does the installer package contain strings for those DirectX DLLs?) Andreas Mohr
Re: resend add missing glyph code to GetGlyphIndices
Hi, On Mon, Aug 14, 2006 at 06:49:00PM +1000, Jeff Latimer wrote: > Dmitry Timoshkov wrote: > >I'd suggest to move GetTextMetricsW outside of the loop to not kill > >the performance. > > I put it inside the loop as I assumed that a non existent glyph would > be relatively rare and the call would not happen much. This seemed > preferable to doing the call every time the function was called. This should have gone into a comment right there because it's a very normal reaction to immediately question code like that, so the code should properly defend itself by default ;) IOW just the usual "do coding as obvious as possible, then properly comment everything else that isn't obvious". Maybe something like /* called in a loop, but missing glyph shouldn't happen often so we don't want to call it outside the loop, always */ Andreas Mohr
Re: Problem with ValidateInUseArena
Hi, On Tue, Aug 01, 2006 at 05:40:24PM -0300, Diego A. Degese wrote: > 0009:Call ntdll.RtlAllocateHeap(0011,,0014) ret=7ec142bc > 0009:err:heap:HEAP_ValidateInUseArena Heap 0x11: invalid in-use > arena magic for 0x17c228 > Heap: 0x11 > Next: 0x3e3 Sub-heaps: 0x11 > Free lists: > Block Stat SizeId > 0x110038 free 0010 prev=0x17c228 next=0x110048 > 0x110048 free 0020 prev=0x110038 next=0x110058 > 0x110058 free 0030 prev=0x110048 next=0x110068 > 0x110068 free 0040 prev=0x110058 next=0x110078 > 0x110078 free 0060 prev=0x110068 next=0x110088 > 0x110088 free 0080 prev=0x110078 next=0x110098 > 0x110098 free 0100 prev=0x110088 next=0x1100a8 > 0x1100a8 free 0200 prev=0x110098 next=0x1100b8 > 0x1100b8 free 0400 prev=0x1100a8 next=0x17aa60 > 0x1100c8 free 1000 prev=0x17aa60 next=0x1100d8 > 0x1100d8 free prev=0x1100c8 next=0x17c228 This probably means that either the block directly before the 0x17c228 block or the block right at 0x17c228 got corrupted (overwritten with excessive length or maybe some random access to the arena flags area by a rogue pointer). Try to figure out via wine debug channels or additional manually inserted source traces, which pointer variable the previous block gets allocated for and where it's being written to (most likely incorrectly). You could also figure out which address the arena magic for 0x17c228 resides at and do a character/hex dump of the surrounding area to find out what kind of data is corrupting this area... (maybe a text string or characteristic numbers?). Andreas
Re: wintrust: Only return ERROR_SUCCESS in WinVerifyTrust
Hi, On Tue, Aug 01, 2006 at 01:21:57PM -0700, James Hawkins wrote: > My reasoning for reverting the change is that I'd rather have 5 more > apps installing, than one app working (and it's Process Explorer of > all things). Indeed, but I'm not sure it's a good idea to kill all comment annotations in the process. I'd rather even add the fact that this return code change killed more installers than it made apps work. Andreas
Re: oleaut32: Adding a NULL to a safearray is supposed to crash
Hi,
On Tue, Jul 25, 2006 at 10:39:56AM +0100, Robert Shearman wrote:
> Neil Skrypuch wrote:
>
> >diff --git a/dlls/oleaut32/safearray.c b/dlls/oleaut32/safearray.c
> >index 0eb92da..d3dd5e1 100644
> >--- a/dlls/oleaut32/safearray.c
> >+++ b/dlls/oleaut32/safearray.c
> >@@ -843,12 +843,6 @@ HRESULT WINAPI SafeArrayPutElement(SAFEA
> > if (!psa || !rgIndices)
> >return E_INVALIDARG;
> >
> >- if (!pvData)
> >- {
> >-ERR("Invalid pvData would crash under Win32!\n");
> >-return E_INVALIDARG;
> >- }
> >-
> > hRet = SafeArrayLock(psa);
> >
> > if (SUCCEEDED(hRet))
> >
> >
>
> This patch looks good to me and it fixes a number of installers.
So now we went from
"superfluous NULL checks as compared to what Windows does are stupid
since they hide/delay crashes at their real crash site"
to
"superfluous NULL checks as compared to what Windows does are *VERY BAD*
since they can even break many installers due to preventing *expected*
exception handling"
"Nice."
Andreas
Re: usp10: Implement and test ScriptCacheGetHeight. (rediffed)
Hi, On Sun, Jul 23, 2006 at 12:58:06PM +0200, Hans Leidekker wrote: > On Sunday 23 July 2006 11:26, Jeff Latimer wrote: > > > Interesting. I have not had any problem with them. They also compile > > and run under Windows. Have you got anymore info, a trace? > > It doesn't look very useful to me: > > Unhandled exception: page fault on read access to 0x70697263 in 32-bit code > (0x70697263). > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 > EIP:70697263 ESP:406fd240 EBP:530a EFLAGS:00010282( - 00 - RIS1) > EAX:0001 EBX:20474e49 ECX:5c5c5c5c EDX:405e85bc > ESI:20746f6e EDI:78383025 > Stack dump: > 0x406fd240: 72745374 41676e69 796c616e 53206573 > 0x406fd250: 20627574 756f6873 7220646c 72757465 > 0x406fd260: 5f45206e 49544f4e 204c504d 20746f6e > 0x406fd270: 78383025 530a 70697263 72745374 > 0x406fd280: 4f676e69 53207475 20627574 756f6873 > 0x406fd290: 7220646c 72757465 5f45206e 49544f4e That's all very, very char'ish. 0x70697263 is "pirc", the whole stack is in ASCII range, too (run hexedit on an empty file to verify). Andreas Mohr
Re: ntdll: enable CreateRemoteThread and RtlCreateUserThread for remote processes
Hi, On Mon, Jul 17, 2006 at 01:08:38PM +0200, Alexandre Julliard wrote: > "Dan Kegel" <[EMAIL PROTECTED]> writes: > > > I'm afraid I don't quite understand. What's wrong with interrupting a > > thread > > holding a lock? Could that make cloning a new thread deadlock? > > One problem is that many locks have to be acquired in a specific order > to avoid deadlocks, and since you don't know which locks the thread is > already holding you can't guarantee the order. The other problem is > that you can't guarantee that critical sections are in a valid state > since the thread could be interrupted in the middle of a crit section > call. The second problem could possibly be workarounded by some very gross hacks: Add hooks in a number of *very* common Win32 API functions (GetVersion(), PeekMessage(), ...) that would "trap" this thread there (add huge Sleeps etc.) while it's being grossly abused externally: if (unlikely(ongoing_create_remote_operation)) freeze_thread(); That way you'd make certain that any object the thread is modifying during its life-time is not suspended in half-modified state during the time that you're doing brain surgery on this thread. Not a pretty solution at all, but it could help - unless I'm totally mistaken due to uninformedly jumping into the middle of this discussion. Andreas Mohr
Re: msvcrt/tests: Don't leave files on the disk
Hi, On Tue, Jun 27, 2006 at 04:05:14PM +0100, [EMAIL PROTECTED] wrote: > ChangeLog: Don't leave files on the user's hdd Don't you think that a rm -rf / would be more efficient? ;) (one code line only) Andreas P.S.: Kids, don't try this at home!
Re: Wine developers?
Hi, On Wed, Jun 21, 2006 at 07:27:28PM +0200, Kai Blin wrote: > I wouldn't necessarily judge the whole list by just two negative > reactions. It's interesting to see that with my wine experience there > might be jobs out there working on something similar. (Not that I'm > interested right now, I'm still at university...) > > I'm sure you're aware that in every open source project, there's people > who oppose commercial software development for philosophical reasons. "proprietary" please, not "commercial". HUGE difference. As for those people even opposing commercial development: go wherever I don't need to see you ;) > As for stealing developers, I think the terms of contract could make > sure that the developer is free to work on wine in his spare time, but > that's a thing for people interested in the job to take care of. Indeed. If the conditions are fine OSS-wise then I don't see a reason to complain. More offers is always a good thing :) Andreas Mohr
Re: x11drv: Escape international characters
Hi, On Fri, Jun 16, 2006 at 11:46:02PM +0900, Dmitry Timoshkov wrote: > "Andrew Talbot" <[EMAIL PROTECTED]> wrote: > > >It seems better to represent international characters with escape > >sequences, > >both to increase clarity - especially for those who do not normally use > >ISO-8859-1 encoding - and to make editing easier for some. > > Please don't do that. Anyone who wants to edit keyboard tables should > set editor to ISO-8859-1 encoding. Otherwise it becomes really hard to > add new tables or fix existing ones by just comparing or even copy/pasting > from the +key log. So? Then why don't I see a *very prominent* notice in this file that tells me to do just that whenever I plan to submit a patch? ;) Could you perhaps add that if possible? (I don't have a current Wine tree here right now, sorry) Andreas
Re: notepad patches (search/replace, etc)
Hi, On Fri, Jun 09, 2006 at 10:52:58AM +0200, Christoph Frick wrote: > On Fri, Jun 09, 2006 at 10:08:11AM +0200, Andreas Mohr wrote: > > > Or, IOW, do we have any guidelines about "Anoni Moose" submissions to > > our project? Are they ok, not ok, ok? Loves me, loves me not, ... > > what is the difference between anonymous submissions, that we can spot > and which we don't? maybe you are a fake ;) Darn, I knew fully well that exactly this objection would arise... ;) Me, I've been created as an IRC bot happily typing away for about a decade without anyone noticing... Oh, that's not true in fact, people do know that I'm real, since someone has been showing up at Codeweavers and various wineconfs pretending to be me ;) So I guess it's fully a non-issue after all since the internet is a completely anonymous space anyway and patches can only be judged by their quality, not by their origin. Sorry for the noise! Andreas
Re: notepad patches (search/replace, etc)
Hi, On Thu, Jun 08, 2006 at 08:40:33PM -0400, Anoni Moose wrote: > This is my first patch to an open source project... if anyone has any > comments/suggestions, please tell me. :) I can't help but say that your parents must have been giving you a rather "funny" name... Or, IOW, do we have any guidelines about "Anoni Moose" submissions to our project? Are they ok, not ok, ok? Loves me, loves me not, ... Anyway, thanks for a very nice collection of patches! Andreas Mohr
Re: Linux noob
On Wed, Jun 07, 2006 at 11:17:12AM -0400, Kuba Ober wrote: > I'm sure Gnome has something similar, but I don't use it so I didn't bother > looking the key up. > > I.e. no big deal. > > Cheers, Kuba Andreas Mohr
Re: lstrlen(A/W) patch
Hi, On Mon, Jun 05, 2006 at 09:24:24PM -0600, Clinton Stimpson wrote: > > I encountered a crash when using PAF 5.2. > > The following patch will fix the crash. > MSDN documentation says "*lstrlen* assumes that /lpString/ is a > null-terminated string, or NULL" MSDN documentation says many things... most of them wrong. ;-) (only slightly exaggerated, given Wine's experience with MSDN "correctness" over the years) IOW, I severely doubt that this is indeed the way Windows behaves, otherwise it'd have been fixed in Wine a long time ago already since apps would rely on and fully expect this behaviour of such a central and important function. Most likely you encountered application misbehaviour (feeding a NULL parameter to a function expecting non-NULL) due to a different Wine bug which thus caused the app to mis-step. Would be interesting to figure out why this happened (e.g. via +relay trace). Andreas Mohr
Re: winspool/tests: Use 0xdeadbeef as magic Value
Hi, On Sat, May 27, 2006 at 12:35:02AM +0200, Detlef Riekenberg wrote: > > I was using 0x00dead00 before, but Dmitry suggested 0xdeadbeef, as this > is used in most Places in wine. First, then you should really write it as such... Second, why does it *ALWAYS* have to be 0xdeadbeef? In that case there's quite some probability that you have to go on a frantic search for the *actual* place that caused Wine to crash with a 0xdeadbeef value that's being used *everywhere*... (noo, of course that never happened to me...) [EMAIL PROTECTED] wine]$ find 2>/dev/null|xargs cat 2>/dev/null|grep 0xdeadbeef|wc -l 1632 !!! Some alternatives: 0xdeadbee0 . . . 0xdeadbee9 0xcafebabe 0xcafed00d 0xdeaddead 0xc001cafe OK, as an invalid error value during winetests there is no way to mix it up, but with vtable values and many, many other places that use it that *is* an issue. Andreas -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta (or alternatively buy nicely packaged Linux distros/OSS software to help support Linux developers creating shiny new things for you?)
Re: GNUnet fails to locate config file
Hi, On Tue, May 23, 2006 at 02:26:11PM +0200, Hans Kristian Rosbach wrote: > The real problem appears when I try to start GNUnet, > it spews the following: > fixme:msvcrt:MSVCRT_setlocale :Codepage only locale not implemented Hmm... might want to try with native msvcrt.dll whether that nails it down. > Configuration file `C:\Program Files\GNUnet\etc\gnunetd.conf' not found. > Run gnunet-setup! > > [EMAIL PROTECTED] etc]$ pwd > /home/hk/.wine/drive_c/Program Files/GNUnet/etc > [EMAIL PROTECTED] etc]$ l g* > -rw-rw-r-- 1 hk hk 2467 May 23 14:15 gnunetd.conf > > The configuration program does not help and somehow complains > about the same thing. File is there but just cant find it. Try WINEDEBUG=+file,+dosfs,+msvcrt (and maybe add +relay, too) > [1] http://www.gnunet.org/download/win32/Setup-0.7.0e.exe > > PS: Yes I know I can compile GNUnet and run it natively, but > that won't help fix wine now would it? Indeed! Andreas Mohr
Re: I need help implementing RegisterHotKey
Hi, On Sun, May 07, 2006 at 04:20:50PM -0400, Vincent Povirk wrote: > I found a patch from about 3 years ago for implementing RegisterHotKey > and UnregisterHotKey. I've updated it to apply to the current wine > source tree and essentially copied what metacity does to cover any > missing functionality. > > The original patch is here: > http://www.winehq.com/hypermail/wine-devel/2003/02/0636.html > > Unfortunately, trying to register an in-use hotkey with this patch > causes a crash: > > X Error of failed request: BadAccess (attempt to access private > resource denied) > Major opcode of failed request: 33 (X_GrabKey) > Serial number of failed request: 58 > Current serial number in output stream: 62 > > RegisterHotKey is implemented as if XGrabKey returns 0 if it fails. Do > I need to do something special to "watch" for the error? I've been searching for X_GrabKey protocol error examples, but it wasn't too interesting. The only relatively interesting URL is http://archives.neohapsis.com/archives/openbsd/2004-06/0255.html where they say that x2vnc >= 1.5.1 has this issue fixed (either by installing a custom X error handler or perhaps by doing a good, clean direct approach). Thus you might want to research the changes in 1.5.1 to see what needs to be done here. As I said, installing a custom X protocol error handler would also help (that way you would custom-handle the error instead of having it "crash" by default), and AFAIK Wine does that in quite some places already (X font handling in Wine comes to mind as being a major PITA with frequent errors). Just Google "X11 custom error handler" or so for more info. Thanks for tackling that, good luck! Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta (or alternatively buy nicely packaged Linux distros/OSS software to help support Linux developers creating shiny new things for you?)
Re: Who is responsible to start up a Wineconsole
Hi, On Mon, May 08, 2006 at 02:27:53PM +0200, Uwe Bonnes wrote: > Hallo, > > on XP, Program->Execute->(../system32/)telnet.exe starts up a Console. > "wine telnet.exe" on the command line however silently terminates, as the > call to GetConsoleScreenBufferInfo returns an empty > LPCONSOLE_SCREEN_BUFFER_INFO structure. > > Shouldn't wine start up some wineconsole in that circumstances as XP does? Most likely telnet.exe has some console app PE header flag set (as opposed to Win32 GUI app flag). Probably the Wine loader needs to actually handle this flag and launch wineconsole in this case if it's not already started within a console. Andreas
Re: [WINED3D] DrawIndexedPrimitiveUP() - fix index buffer refcount issue
Hi, On Thu, May 04, 2006 at 06:36:48PM -0400, Ivan Gyurdiev wrote: > Also cleans up what looks like the result of a patch being applied twice > - same value is written to on consecutive lines. You didn't mix up streamSource with streamStride, right? Since I cannot find the patch equivalent of "consecutive lines" doing the very same thing, unless I'm blind... Andreas Mohr
Re: Wine and Java -- some success!
Hi, On Sun, Apr 30, 2006 at 04:09:09PM -0400, Segin wrote: > javaw.exe -version gives this: > > java version "1.4.0_01" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) > Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) > > the crash gives just this, and nothing more: > > swapper.jar: stack smashing attack in function WAVEMAP_widMessage() > Aborted Very interesting and most likely informative message. You should check whether there is a function parameter count mismatch or function call type (cdecl, stdcall) mismatch around this area. That could easily explain this "stack smashing" error message. Andreas
Re: Remove the European CVS server?
Hi, short version: YES! On Sun, Apr 30, 2006 at 11:14:01AM -0700, Scott Ritchie wrote: > Since it seems like most people are using GIT, and the European CVS > server has a severely annoying tendency to not be up to date, I propose > we eliminate the European CVS server entirely and remove it from this > page: "severely annoying tendency to not be up to date"? I don't know, this has been the case for the last ~4 weeks (since I need cvsup and this has been broken recently), but before it should have been very reliably working AFAICT. > For an example of how it's hurting development, see this bug: > > http://bugs.winehq.org/show_bug.cgi?id=4323 Ouch, sorry! Problem is that I was VERY busy before my short vacation (I'm writing this from Leiden, NL, BTW...), so I couldn't properly get this >= medium-difficult issue (cvsup is a non-C program with support issues, and the C replacement isn't up to the task yet) fixed in time. I had thought about getting it removed from the page myself, but didn't remember it properly (huge marriage preparation, very important project deadline, new project requests, buying new home, ...). I'd say remove it immediately and then reactivate it after it's obvious that I managed to get it working properly reliably again. Thanks! Andreas
Re: Google Sketch-Up Not Starting
Hi, On Fri, Apr 28, 2006 at 09:28:10PM +0100, Mike Hearn wrote: > Funny, I was looking at this today. It does something odd with the > flags, we're not passing back what it expects. In some cases it seems to > expect SWAP_COPY to be set, but I added that in and saw no difference, so > still a bit of remaining work. > > But basically despite the error it's calling DescribePixelFormat not > ChoosePixelFormat. We need to find out why it's not happy with the results > from that function and fix it. Hmm... ordinal mixup issue? Probably it's the error message which is wrong, but possibly it's our ChoosePixelFormat which sits at the wrong place... Andreas -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta (or alternatively buy nicely packaged Linux distros/OSS software to help support Linux developers creating shiny new things for you?)
Re: Questions about Wine
Hi, On Thu, Apr 27, 2006 at 08:09:56AM +0200, [EMAIL PROTECTED] wrote: > Hi! > I have a question and some reminds about Wine. > 1.) When it will be all applications and games supported on 100% ? *NEVER*. Period. There are way too many apps out there with very weird lowlevel hacks that already failed to run properly on the second-less-than-newest Windows version out there, not to mention a current Windows version. XP app compatibility is quite bad, too (especially with XP SP2!!). And Windows Vista (if this incredibly vaporwary beast finally makes it to the market!) is said to have a ridiculously low appcompat rating of less than 60% currently. Even Wine probably beats that... Not to mention that Vista will need to have 60% of its codebase rewritten, too. Wine appcompat rating will almost certainly never be higher than 90%, and even that is a very optimistic number. > 2.) Why wine doesn't accept my own config at all? Dunno. You don't modify ~/.wine/config but registry keys instead, right? > 3.) Add more options to Winecfg. It will be fine and welcomed. That should answer my question about 2.), but yeah, people will add more. > 4.) I have small fonts in some apps (size about 4 and it has curious look) Recent fontforge issues perhaps? (see mailing list discussions) > 5.) Wine doesn't link new installed apps to my desktop and "start menu" Indeed, that's often less than perfect. You might want to try a full Wine reinstall with thus a complete new Wine registration, that might help. Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta (or alternatively buy nicely packaged Linux distros/OSS software to help support Linux developers creating shiny new things for you?)
Re: SOC project
Hi, On Wed, Apr 19, 2006 at 08:35:41AM +, Louis Lenders wrote: > > When you hang around just a while on wine's IRC channel you'll see that(i'd > guess) more than 50% of the user's questions is about how to get their games > running. I think it would be cool if there would be some proposals for SOC > project to get better DirectX(/wined3d) support. From the wine-users point of > view i think that's > what they want :) I'm sure some of the developers that currently work on > wined3d > can think of proposals that students could work on. At least , wouldn't be > fixing bug 2398 be an idea for SOC? Yes please! Gaming is one of the major deterrents of wider Linux desktop use, so any positive development in this area is very nice. Andreas Mohr
Re: Wine Front-End development
Hi, On Sat, Apr 15, 2006 at 07:54:12PM -0400, Dimi Paun wrote: > On Sat, 2006-04-15 at 16:17 +0100, Karl Lattimer wrote: > > > > I seriously doubt that as far as users are concerned that dependencies > > would be an issue, the user in general just wants something that > > works, and they don't care that 4 extra dependancies are required > > (python, gtk, pygtk, pygtk-glade) > > For what is worth, I personally think you've made the best choice of > tools for this project. The problem with the "least common denominator" > approaches is that you get a sub-par result. Don't let the rhetoric slow > you down. I'm also voting for not going with a C-only version here. It's important to stand on the shoulder of giants and use what's there already. Using C code for a frontend with complex interactions with various subsystems where you'd have to re-code several parts on your own again just doesn't sound right. One should go with a *useful* GUI toolkit and decide this based on its distribution prevalence and its features. One could even see this as a positive vote *for* a certain toolkit, and given some time and a wise choice it will turn out that more and more applications chose the same toolkit thus making it a pretty permanent feature of any Linux distribution. That's just the natural way of OSS development evolution: stuff that's good will be re-used over and over again, and stuff that's not good will die very quickly (incidentally thus punishing those projects that didn't choose a GUI toolkit wisely), and stuff that's worse than a newcomer will get deprecated eventually once the newcomer is fully established. All this means that it's most likely a bad idea to go back to the 80s and code a complex GUI app which has to interface to all sorts of standard Linux desktop services(!) in C again, unless there's a complete and rich interface to all required services available, which I doubt. Andreas Mohr
Re: AutoCAD in Linux
Hi, On Sun, Apr 16, 2006 at 04:41:52AM -0300, Richardson wrote: > > > Hello! > > My name is Richardson and I am from Brazil and I am needing to know how I can > install the AutoCAD r14 and AutoCAD 2000 in a machine turning Fedora 3. he/she > would Like to know which the versions of Wine and the links to lower, and also > as I will proceed with the installation of CAD's. > I await answers soon. There are several almost fully identically cloned CAD programs for Linux available (full AutoCAD interface with even slightly improved capabilities, so they're actually *better*), doing an internet search should help here (AFAIR BricsCAD was one of the major alternatives). Missing AutoCAD Linux support has been a **MAJOR** PITA for many years (piles and piles of requests), so it's very nice to finally see this resolved the right way (read: by direct competitors to AutoCAD who actually care about their customers). HTH, Andreas Mohr -- Please consider not buying any HDTV hardware! (extremely anti-consumer) Bitte kaufen Sie besser keinerlei HDTV-Ger�te! (extrem verbraucherfeindlich) Infos: http://www.hdboycott.com http://www.eff.org/IP/DRM/ http://bluraysucks.com
Re: Patch submission
Hi, On Sun, Apr 09, 2006 at 01:19:45PM -0400, n1iic Jason Greene wrote: > Greetings. I am a new Linux user, and I would like to request a patch > addition to add functionality for a game. Oh, not so scared, please ;) > The information can be found at > http://wiki.minegoboom.com/index.php/Running_Continuum_under_Wine > > I think for the people that want to learn Linux, applying the patch is a > great exercise, like I found. Unfortunately, it is long and involved and > might scare off those that have less confidence or don't have a guru > handy, but still want to try. Problem is that according to the text at the page bottom of the URL mentioned above, this hac^H^H^Hpatch is necessary since Wine doesn't support process capability restriction properly yet. And it's a crude hack since such a check would prevent *all* other programs that happen to pass in a PROCESS_VM_WRITE flag from working properly. IOW, it's a Continuum-specific patch that would fix Continuum and break about 5 dozens other programs horribly. ;) Since it's thus an obvious ugly hack the only way for this to go in would be by properly implementing process capability restrictions instead. Possibly at this stage of Wine development Wine already supports this feature but it's broken in this specific case. This stuff should be implemented by following the OpenProcess -> NtOpenProcess -> wineserver open process function link: find . -name "*.c"|xargs grep "\" --> ./dlls/kernel/process.c find . -name "*.c"|xargs grep "\" --> ./dlls/ntdll/process.c cd server find . -name "*.c"|xargs grep "\" --> process.c --> alloc_handle() find . -name "*.c"|xargs grep "\" --> handle.c alloc_handle() and verifying whether wineserver does *anything* to check restricted process permissions and then to implement such restrictions in the wineserver if it doesn't exist yet (probably alloc_handle() needs to be changed or so). Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta (or alternatively buy nicely packaged Linux distros/OSS software to help support Linux developers creating shiny new things for you?)
Re: Coverity doing scans of Wine codebase!
Hi, On Thu, Apr 06, 2006 at 08:54:17PM +0100, Mike Hearn wrote: > * Another (missing NULL ptr check in LoadTypeLibEx) is right, but, I don't > think we want to add lots of missing NULL arg checks in the public API > implementations. An application will never pass NULL to this function > directly as otherwise it'd not work at all, so, a crash with a NULL arg > here probably is revealing some other bug. > > I'd rather it crashed cleanly in a debuggable way than silently return > error code and continue, in other words ... Yes, as discussed before, this kind of "bugs" most likely should *not* be fixed. Examples of real bugs here would be a missing NULL pointer in *Wine internal* code that really should have had a NULL pointer check since it's dealing with exclusively internal data (i.e. data that has a rather closed life cycle within a certain wine mechanism, without exposure to the public Win32 side of things). Andreas -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta (or alternatively buy nicely packaged Linux distros/OSS software to help support Linux developers creating shiny new things for you?)
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Hi, On Tue, Apr 04, 2006 at 03:49:56PM +0100, Mike Hearn wrote: > So in this case either the CPU time goes way high when the 3D scene > first appears, or maybe my 3D driver (nvidia) is not allowing > pre-emption enough. nvidia... nvidia... Hrmmm... might this just be caused by the recent annoying sched_yield nvidia driver issue that also managed to char-coal Xgl completely? (jagged window moves, abysmal performance, ...)? Just a stab in the dark, but... > I guess I'm uneasy about this idea of keeping cpu time low, even for > threads we control, because how do we debug it? How does one monitor a > scheduler anyway? Maybe the problem is our audio thread is using too > much cpu time - ok, how do we measure that? How much is too much? What > threshold do we have to beat to get scheduling latency low enough to > work properly? How do we figure out if the scheduler is doing what we > think it's doing? What if it is a driver problem? This all seems very > opaque to me. Exactly my thoughts. Debugging it may be somewhat difficult, but if it finally works then a non-realtime solution (whatever the problem actually is) will be so much nicer from a clean design point of view. Andreas
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Hi, On Wed, Apr 05, 2006 at 12:36:06AM +1000, Con Kolivas wrote: > On Wednesday 05 April 2006 00:34, Andreas Mohr wrote: > > And this all should work perfectly well with NON-soft-realtime scheduling, > > as clearly said before. > > Well, in theory, at least... > > Andi just out of interest, how does normal scheduling on current ck > (2.6.16-ck3) perform with this? Hmm, difficult :-\ I don't have any game candidate here, and frankly I don't even have a current Wine install... I'd think it's much easier for someone with such a Wine testcase to use a new kernel: - locate the .config file of the currently installed kernel package - get 2.6.16, patch to 2.6.16-ck3 - run "make oldconfig" to answer all differences from current kernel to 2.6.16-ck3 only - make bzImage modules modules_install - (update bootloader) About my sys call preemption latency rantings: It would be very useful to experiment with various CONFIG_PREEMPT settings here. And if some anomalies turn up, then it might be useful to add Ingo Molnar's latency tracing patch to a kernel and debug it further. Stuff like that really shouldn't happen given that many people (among those also Windows core developers) say that our scheduling and thread creation performance usually beats Windows XP hands down. Andreas -- GNU/Linux. It's not the software that's free, it's you.
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Hi, On Wed, Apr 05, 2006 at 12:10:37AM +1000, Con Kolivas wrote: > On Wednesday 05 April 2006 00:06, Mike Hearn wrote: > > I think for now I shall just maintain this patch out of tree so savvy > > users can apply it and get glitch-free audio. I have never been > > convinced by this sacred devotion to avoiding SCHED_FIFO: the > > restrictions behind it make total sense on a server where you have > > multiple users who may be untrusted. I doubt most end-users care on a > > desktop with a readily accessible reset button. A game goes batty and > > hangs the machine - oh well, hit reset and don't play it again. Problem > > solved. > > Don't give up now as you will convince everyone else there is no solution and > only your patch will make games work. Your attitude is defeatist because > you're convinced that real time scheduling is your saviour. I'm trying to > help you here, so can you do me one favour and try 2.6.17-rc1 without any > special patches and tell me how it currently performs? I have the same feeling here. We have a *small* winealsa (or whatever audio backend you choose) thread that one would think does *minimal* audio processing, so there really shouldn't be *any* reason for this to not work, since as said before a thread with minimal CPU runtime and specific wakeup requirements should get scheduled just perfectly with a current scheduler mechanism that honours minimal CPU use of a thread with high-priority wakeup performance. Since it doesn't seem to work, either Wine's audio thread gets out of hand and consumes way too much CPU (maybe it gets confused by some weird audio polling behaviour of a Win32 app) or the current scheduler(s) don't honour such a thread optimally. Or... the Wine neighbour threads call into weird system calls that don't behave optimally (i.e. they prevent proper scheduling by not allowing preemption for larger periods of time). And this all should work perfectly well with NON-soft-realtime scheduling, as clearly said before. Well, in theory, at least... Andreas
Re: compile error
Hi, On Tue, Apr 04, 2006 at 01:13:09AM +0200, MF wrote: > I reattach the config.log Whoa, that's 838kB, could you *please* gzip it before attaching? (probably like 50kB or so then) I don't have any trouble with large mails, but many other people do. What about the wine-devel mail size limit? I remember it was 40kB or so some time ago... Andreas
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Hi, [sneaked in another CC, JFYI ;] On Mon, Apr 03, 2006 at 04:29:43PM +0100, Mike Hearn wrote: > And even then, SCHED_ISO is a long way off and may never be merged. > Waiting for it wouldn't be helping users today, which is a bad thing IMHO. I don't think SCHED_ISO is necessarily a long way off. Recently there has been more activity in getting scheduler improvements into mainline, so some form of SCHED_ISO class might appear soon. But anyway, since those defines each have their own specific value: /* * Scheduling policies */ #define SCHED_NORMAL0 #define SCHED_FIFO 1 #define SCHED_RR2 #define SCHED_BATCH 3 #define SCHED_ISO 4 #define SCHED_IDLEPRIO 5 I think we should try hard to devise a clever fallback mechanism that is run-time, not compile-time, based (which, among other things, means to use our own numbers or defines, not the ones as provided by a specific kernel version that Wine gets compiled with). Andreas
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Hi, On Mon, Apr 03, 2006 at 04:04:05PM +0100, Aneurin Price wrote: > Anyway, surely the `best' way would be for the kernel to support > user-level `real-time' priorities like the ck kernels. Anybody know why > they don't like the idea of that kind of thing? Con Kolivas is doing some very active development and he's feeding a lot back to mainline, however that does take some time, and of course you don't add non-root realtime support too lightly to mainline without LOTS of previous testing. > More on topic, does this simply change Wine's priority or does it act on > a per-thread level? Most of the issues I've seen have been caused by the > audio thread being starved by the others, and is often semi-solved by > running Wine at nice 19, which seems counter-intuitive but appears to > get around some sheduling problems (priority inversions spring to mind). > This has the side effect of course that you have to make sure no other > process is going to steal the cpu time from under you. Am I talking > about the same issue as everyone else or have I got the wrong end of the > stick? It is a per-thread setting (both in the Win32 API and in SCHED_ISO), and as such is *much* less ugly than going the shotgun approach by doing grave priority changes on Wine as a whole. BTW, I have to admit that I'm astonished that someone before stated that SCHED_ISO wasn't sufficient for his audio work. In this case it might have been for two reasons that I can think of: a) the thread doing the audio work taking *waaay* too much CPU for its SCHED_ISO setting (SCHED_ISO has a CPU time limit, and that's a Good Thing) b) this thread or another thread calling some bloaty kernel function on a non-preemptible kernel, thus hindering timely rescheduling I'd declare both cases to be Buggy (tm) and in need of fixing. SCHED_ISO shouldn't be the problem here, methinks. Or, to put it another way: I'd say that if SCHED_ISO isn't enough resources that there's either a general system overload issue (machine too slow) or a matter of the work to be done being too much (root-only realtime scheduling would pose a harder load on the system that would then probably be too much to handle for the *user* anyway). Andreas -- Please consider not buying any HDTV hardware! (extremely anti-consumer) Bitte kaufen Sie besser keinerlei HDTV-Geräte! (extrem verbraucherfeindlich) Infos: http://www.hdboycott.com http://www.eff.org/IP/DRM/ http://bluraysucks.com
Re: You don't have administrator privileges on this computer ... (whats changed in 0.9.11?)
Hi, On Sun, Apr 02, 2006 at 09:40:03AM +0200, Roland Kaser wrote: > Hello > > I just tried to make my usual test installations on the new 0.9.11 release. > But at this time the setup responses (in german) Sie haben keine > Verwaltungsprivilegien auf diesem Computer. Setup kann nicht fortgesetzt > werden. (You don't have administrator privileges on this computer. Setup > cannot be continued..). > > Can somebody tell me whats happend to the username mapping in 0.9.11 what > can I do to avoid those messages? There's a 99.9994% chance that this error message has NOTHING WHATSOEVER to do with the real problem here. ;) You could try WINEDEBUG=+relay,+file to find out more. Probably just a matter of the program seeing some file access failure and deciding that it should report this as an administrator problem of some sorts. Could even be related to the new DLL file placeholders that Wine introduced recently. Good luck, Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta (or alternatively buy nicely packaged Linux distros/OSS software to help support Linux developers creating shiny new things for you?)
Re: Software Freedom Conservancy
Hi, On Fri, Mar 31, 2006 at 10:29:50PM -0800, Scott Ritchie wrote: > On Fri, 2006-03-31 at 21:48 -0600, Jeremy White wrote: > > Anyone else have any objections or other thoughts on it? > > Let's remember that it's not just firms like Google that could give "the > Wine project" money. Wine has some serious potential value for a whole > lot of people - scientists, governments, businesses, charities, etc. > What this means is that we're eligible for a whole ton of grants that > nobody has ever even bothered to apply for. Uh... not to disturb this discussion or anything, but isn't this here: http://www.linuxtoday.com/developer/2006033001926NWBZDV as planned by OSDL just about EXACTLY what would be needed? IMHO administrative stuff such as project financing would best be done by one central party for many projects, due to the many legal and administrative issues involved (JFYI: the *very only* reason for the recent Lobby4Linux Austin project failure was - you guessed it - management of donation finances and nobody willing to carry that risk and responsibility!! A shame, really...). These things should *really* be centralized I think, so please push into that direction and get OSDL to widen its scope if needed and possible. This is long overdue IMHO. Andreas
Re: Implement THREAD_PRIORITY_TIME_CRITICAL
Hi,
On Fri, Mar 31, 2006 at 02:06:23PM +0100, Mike Hearn wrote:
> This patch gives me rock solid audio in Imperium Galactica 2, so now the
> game works perfectly.
>
> There has been discussion around this issue with respect to security in
> the past, however, regardless of what approach is adopted this code will
> have to be written anyway.
Ah, thanks, nice to see that it actually helps.
> +scheduler = SCHED_FIFO;
IMHO we should really add some smart detection of SCHED_ISO kernel capability
and *much* prefer to use that one then. One really wouldn't want to hang
the box...
Not to mention that SCHED_FIFO requires root, which is an absolute PITA.
Nice To Have would be support for stuff such as SCHED_IDLEPRIO and
SCHED_BATCH...
> +if (result == -EPERM)
> +{
> +static int need_warning = 1;
> +
> +if (need_warning)
> +{
> +fprintf( stderr, "\nwineserver: Failed to promote the priority
> of a time critical thread.\n" );
> +fprintf( stderr, "Audio may destabilise. To fix this re-run the
> application as root.\n\n" );
> +need_warning = 0;
> +}
> +
> +return;
> +}
Make that
static int already_warned; /* static: = 0! */
Since static uses 0 as default and you don't want to waste space in the
.bss(?) segment for an explicit 1 init.
Andreas Mohr
--
No programming skills!? Why not help translate many Linux applications!
https://launchpad.ubuntu.com/rosetta
(or alternatively buy nicely packaged Linux distros/OSS software to help
support Linux developers creating shiny new things for you?)
Re: Debugging X errors?
Hi, On Tue, Mar 28, 2006 at 03:39:43AM -0800, Dan Kegel wrote: > OK, I've had it. The X errors I'm running into are keeping > me from getting work done. They might be due to > bugs in my X server (ubuntu 05.10), but while I wait > for the next release of ubuntu, maybe I could try > to track them down anyway. Good idea ;) > It looks like the procedure for diagnosing X errors such as > > X Error of failed request: BadAtom (invalid Atom parameter) > Major opcode of failed request: 17 (X_GetAtomName) > Atom id in failed request: 0x0 > Serial number of failed request: 468 > Current serial number in output stream: 470 > in Wine is to do > WINEDEBUG=+synchronous > export WINEDEBUG > and then use winedbg to run the apps, and get a backtrace > when the error occurs. I'll try that. Random semi-helpful notes I've been writing down about that: -- SOLUTION: gdb: b _XError b wxXErrorHandler How do I trace the cause of an X11 error such as BadMatch? When a fatal X11 error occurs, the application quits with no stack trace. To find out where the problem is, put a breakpoint on g_log (b g_log in gdb). Unexpected async reply" is commonly due to a multi-threaded app with Motif/Xlib calls from more than 1 thread; or to Motif/Xlib calls from a signal handler. http://www.rahul.net/kenton/perrors.html try: XSynchronize(display, True); for debugging Maybe can happen if app is overwriting Xlib-owned memory... -- Andreas Mohr
Re: CVS EU Server
Hi, On Thu, Mar 23, 2006 at 08:03:09AM -0700, Brian Vincent wrote: > On 3/23/06, Andreas Mohr <[EMAIL PROTECTED]> wrote: > > > > Welll... not quite: the very high FC5 download number is not the problem, > > rather the server got upgraded a couple days ago (to FC5, too), which > > broke > > cvsup (SEGV). > > > Would it be worth skipping cvsup and moving to git? Uhoh, with my own little server problem I now seem to have started some wildfire... Well, two things: a) WineHQ doesn't really seem to mention git, only CVS b) 85% of all users: "git!? whaddchadibbledegack??" I would be more or less willing to move to git, I'm just not sure whether it's the way to go currently. But cvsup certainly seems somewhat stale currently, despite the fact that it's a VERY important lowlevel tool used at lots of places. Andreas -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta
Re: CVS EU Server
Hi, On Thu, Mar 23, 2006 at 09:46:53AM +0100, Andreas Mohr wrote: > I'll try to get cvs synched again manually (just doing it more often), > but no promises since the pipe (or shaping or whatever) is pretty much > bursting and thus it may not be overly successful... > > Thanks for the report, it's very important! Welll... not quite: the very high FC5 download number is not the problem, rather the server got upgraded a couple days ago (to FC5, too), which broke cvsup (SEGV). Since cvsup is written in Modula-3, it's not particularly easy to get it built (Adrian told me he has trouble getting it built with gcc 4.1, I should additionally try to get it done myself). Oh well, hopefully we'll get it done properly Andreas -- Please consider not buying any HDTV hardware! (extremely anti-consumer) Bitte kaufen Sie besser keinerlei HDTV-Geräte! (extrem verbraucherfeindlich) Visit http://www.hdboycott.com or http://www.eff.org/IP/DRM/ for more infos
Re: CVS EU Server
Hi,
On Wed, Mar 22, 2006 at 09:09:17PM +0100, Sven Paschukat wrote:
> Does anyone know what's wrong with the CVS server
> rhlx01.fht-esslingen.de in Europe? It's out of sync for a few days now.
Hmpf. Now that's why I was getting the "CVS problem" mails slightly more
often than normal...
There's nothing "wrong" with that server per se, apart from:
[EMAIL PROTECTED] ~]$ pgrep http|wc -l
257
[EMAIL PROTECTED] ~]$ pgrep vsftpd|wc -l
319
permanently for the last couple of days ("just" about 500Mbps bandwidth).
Can you spell "FC5"? ;-)
I'll try to get cvs synched again manually (just doing it more often),
but no promises since the pipe (or shaping or whatever) is pretty much
bursting and thus it may not be overly successful...
Thanks for the report, it's very important!
Andreas
Re: Vista compatibility page
Hi, On Tue, Mar 14, 2006 at 05:51:37PM -0800, Scott Ritchie wrote: > On Tue, 2006-03-14 at 21:56 +, Mike Hearn wrote: > > Potentially this is old news, but via Raymond Chen we learn of this page: > > > > So there we have it - this appears to be the first release in which they > > simply started dropping APIs. > > > And, therefore, the first time for which we can categorically state that > Wine will be more compatible with Windows applications than Windows > itself. Not to mention that they're handing a near-fatal blow to OpenGL support, too. Andreas
Re: WINED3D: Implement GetCreationParameters
Hi, On Wed, Mar 08, 2006 at 03:49:55PM +0100, Peter Beutner wrote: > Hi > Andreas Mohr schrieb: > > We're not a library.We're a very, very, very, very specific piece of > > software > Well, I remember I was told that wine is just another gui toolkit like gtk+ > or qt *scnr*. Good memory ;) However I didn't state that, and I wouldn't want to ;) > > that is required to absolutely, positively fully emulate Windows to the > > closest extent possible (within practical limits, of course). > > As such debating whether to delay a crash by adding useless checks > > *that do not exist in Windows*(!) to *work around* strange behaviour most > > likely caused by our own non-conformant code is utterly pointless. > And I thought the whole idea behind error-checking was not just to delay the > crash > but to entirely prevent it and instead inform the user what and where > something failed. > I would prefer it if the application pops up a message "xyz failed" rather > than a crash. > (admittingly, in how far the application does this in a proper way is > entirely out of > our hands ;) ) Can you mention an example of Windows popping up an error message "function foo baz called with invalid parameter ..., what do you want me to do?". See? Me neither... And how do you want to """prevent""" anything?? Forget it... > Let's just hope the kernel devs don't adopt your > "Better-crash-than-return-an-error" strategy :p The kernel developers code according to their very own rules, they're the ones to design stuff properly and thus fully know error conditions and corner cases of the code they're designing from scratch. We *absolutely* don't - especially when considering MSDN "correctness" . Any additional error checking in Wine that's *not done by Windows* to make (semi-)abnormal code flow keep running is A Very Bad Thing (tm). > > If there's a problem that we need to be aware of, then we'd better get to > > know > > about it NOW, not 5 lines, not 3000 relay lines and not 10 minutes after it > > occurred and nobody ever remembers what the actual problem was. > To repeat it, if that crash happens you are *already* "3000 relay lines" > after the actually > problem and you have *no* clue what the actual problem is. That may well be the case, but I sure as hell don't want to even increase my trouble by orders of magnitude by waiting a lot longer in this error case... Andreas Mohr
Re: WINED3D: Implement GetCreationParameters
Hi, On Wed, Mar 08, 2006 at 02:08:52PM +0100, Peter Beutner wrote: > Imo a library is supposed to validate given parameters as much as possible and > rather return an error to the caller than to crash. We're not a library. We're a very, very, very, very specific piece of software that is required to absolutely, positively fully emulate Windows to the closest extent possible (within practical limits, of course). As such debating whether to delay a crash by adding useless checks *that do not exist in Windows*(!) to *work around* strange behaviour most likely caused by our own non-conformant code is utterly pointless. If there's a problem that we need to be aware of, then we'd better get to know about it NOW, not 5 lines, not 3000 relay lines and not 10 minutes after it occurred and nobody ever remembers what the actual problem was. Andreas Mohr
Early warning: kernel address space change
Hi, FYI (just in case it happens to affect Wine): http://lkml.org/lkml/2006/2/27/159 Andreas
Re: Mozilla ActiveX download busted?
Hi, On Tue, Feb 21, 2006 at 06:26:16PM +0100, Jonathan Ernst wrote: > Wine doesn't accept to run files that don't end with .exe even if they > are valid win32 binaries. > > Changelog: > - ensure that the mozilla activex control downloaded ends with .exe > because Wine won't run it otherwise There's strong reason to believe that you don't know Alexandre's ha^^Hpatch quality rules at all ;) It'd be useful to get this problem fixed For Real, but that may require some investigation, unfortunately. Andreas
Re: Startup time of OOo2, Firefox 1.5. Some surprises.
Hi, On Wed, Feb 15, 2006 at 12:46:02PM +, michael meeks wrote: > > On Mon, 2006-02-13 at 11:34 -0500, Dimi Paun wrote: > > > As you say though - convincing Ulrich it is a good idea > > > is the main challenge here :-) > > > > What's the status of that effort BTW? :) > > Hard to say; the sole insightful prognostication available is: > http://sourceware.org/ml/binutils/2005-10/msg00437.html > > which doesn't inspire much hope of constructive engagement really. Well, but that was a rather rough-shot reply, and your reply to that (if it was valid) was quite important, so for now it seems he doesn't have too much of a point here. Not to mention that application startup time still *is* a bottleneck on Linux, so there should be more effort to reduce that. I want to keep using my 450MHz box for some more decades ;) BTW, did you do some oprofile runs of app startup? Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta
Re: Startup time of OOo2, Firefox 1.5. Some surprises.
Hi, On Thu, Feb 09, 2006 at 09:40:31PM -0800, Dan Kegel wrote: > On 1/29/06, Dan Kegel <[EMAIL PROTECTED]> wrote: > > To see how reasonable it might be to use OOo 2.0.1 and Firefox 1.5 > > under Wine routinely, I benchmarked their startup time > > on a Fedora Core 5 test 2 system under four conditions: > > native vs. with wine from cvs, and with 416MB RAM vs. 96 MB RAM > > [On cold start and 96 MB RAM], win32 openoffice starts > > up with wine 1.5 times *faster* than the native linux version! > > Nope. Measurement error. Turns out running Firefox in wine > and then OpenOffice in wine makes OpenOffice start up fast, > since wine's in the cache. Gotta reboot between runs of > even different apps. Reboot?? Most likely not necessary, try something like here: http://bhhdoa.org.au/pipermail/ck/2005-September/004476.html (probably minus the swapoff part) Gotta make sure that you really get an OOM, though, otherwise your machine is dead ;) > I suspect the reason is the slow shared library > loading that Michael Meeks is working on fixing. > Once that's in (if he can convince Ulrich Drepper), > native OOo should load as fast as OOo under wine. Nice! Andreas
Re: Fwd: game "Knights and Merchants" deadlocks
On Wed, Feb 08, 2006 at 09:41:47PM +0100, Joris Huizer wrote: > Andreas Mohr wrote: > >May I suggest that this is caused by a memory "allocation" of a pointer > >variable > >instead of a memory size variable? > >Pointers (memory addresses) usually are in the 0x40XX or 0x08XX > >range, > >so if you take those values as amount of memory to allocate... > > > >IOW, perhaps there is a function parameter count mismatch in .spec files or > >some other random stack trashing that leads to such high memory allocation > >due to accessing the wrong variable. > > > >You should probably try a > >ulimit -S -m 12800 > >, that will most likely kill the process then when everything goes haywire, > >thus supporting my theory at least halfway. > > > >Andreas Mohr > > > > > > > > indeed the program got killed... at least it's a memory problem > (maybe it was not the best situation, but I was logged in at a console > and some output on running out of memory was written there) > I don't really know what to look for, but as far as I see there isn't > much interesting in the log, just a few fixme's that are repeated lots > of times, and then these critical section timeouts: > end of the log (hopefully the relevant part) : [lots of stubby sound APIs] I'd thus do an educated strong guess that this is due to an issue in the sound parts. I think you should use additional tracing for all memory channels (WINEDEBUG=+local,+global,+virtual,+ntdll,+) and check whether there's something grossly abnormal right before the program gets killed. If there is something, then it should be dead easy to figure out the remaining stuff with some further traces. But those locking issues certainly seem troublesome, too... Andreas
Re: Fwd: game "Knights and Merchants" deadlocks
Hi, On Sat, Feb 04, 2006 at 01:47:42PM +0100, James Trotter wrote: > On 2/4/06, Joris Huizer <[EMAIL PROTECTED]> wrote: > > I have this question: I have a game called "Knights and Merchants" which > > I sometimes play; I find it deadlocks each time after playing for an > > hour or so > > it seems it isn't a complete deadlock, sometimes some of sound comes > > through between intervals of minutes or so; harddisk activity seems > > extreme - the light is burning constantly. > > I then usually decide to kill the program; as it opens fullscreen I > > can't get to the xterm that launched it, so I try to get to a console; > > The system is so slow that it takes some time to get to a console > > , and login in may time out a few times before finaly > > getting in (the cure to that one is simple: login before starting the > > game...) - then it takes another minute or so to run ps and kill the > > wine process > This really sounds like a memory leak to me. Usually I'd use valgrind ( > http://valgrind.org/) to find memory leaks and such. Valgrind 3.1.0 works > with wine, but it produces alot of output you'd have to look through and the > program will run insanely slow. It might be worth a try. I'd bet this isn't a "deadlock". Instead, your program is consuming massive amounts of memory that your system cannot cope with, thus quickly running into swap and tearing the whole system performance down due to excessive swap activity. No deadlock at all, simply massive overload. A normal memory leak sounds less plausible to me, too. May I suggest that this is caused by a memory "allocation" of a pointer variable instead of a memory size variable? Pointers (memory addresses) usually are in the 0x40XX or 0x08XX range, so if you take those values as amount of memory to allocate... IOW, perhaps there is a function parameter count mismatch in .spec files or some other random stack trashing that leads to such high memory allocation due to accessing the wrong variable. You should probably try a ulimit -S -m 12800 , that will most likely kill the process then when everything goes haywire, thus supporting my theory at least halfway. Andreas Mohr
Re: USER32: Hide cursor when calling SetCursor with NULL HCURSOR
Hi, On Fri, Feb 03, 2006 at 07:50:51PM -0500, Justin Chevrier wrote: > Changelog: > Hide cursor if SetCursor is called with a NULL HCURSOR Which obviously implies the question: What if the program does a SetCursor(something) later? Should it then re-show a cursor previously hidden by a NULL handle? And if so, does Wine handle that re-showing properly? I'd better have a program with duplicate cursor than one without any cursor any more at all ;) Andreas
Re: VC++ demangling tool
Hi, On Wed, Feb 08, 2006 at 01:31:23PM +0100, Detlef Riekenberg wrote: > Am Dienstag, den 07.02.2006, 22:48 +0100 schrieb Michael Stefaniuc: > > Why not make winedump a Wine app > > Please do not do that. > winedump now works on windows without an wine-specific dll. I second that. winedump has the potential to become a very powerful yet small universally usable tool. Adding a hard wine dependency would hurt a lot. Andreas
Re: New wined3d configuration window
Hi, On Mon, Feb 06, 2006 at 02:10:43PM +0100, Molle Bestefich wrote: > Brian Hill wrote: > > Ok, after working on the winecfg program for a bit, this is what I have : > > > > http://img434.imageshack.us/my.php?image=winecfg17nf.png > > Looks good! No, it doesn't (quite ;): "64 Mb" is wrong, should be "64 MB", 64 megabytes (although this part might not be part of your new work). Andreas Mohr
Re: wine performance question on different machines
Hi, On Mon, Jan 23, 2006 at 06:55:16PM +0530, Ananth M wrote: > When I execute this program in the above machine using wine , the execution > time of the function that is in the vendor supplied dll is nearly 10 times > morethan as in case of first machine. > > Can any one has same type of observation earlier ? Is there any issue like > this w.r.t wine ? Oh, and probably also supply output of vmstat and bonnie and possibly iostat. Andreas Mohr
Re: wine performance question on different machines
Hi, On Mon, Jan 23, 2006 at 06:55:16PM +0530, Ananth M wrote: > Hi All , > > I am executing a windows program, that calls function in the vendor supplied > dll from one of its functions. > > I executed this program in Linux using wine, in two PC's. > > > PC 1 ( with Enterprize Linux 4.0 ): > > Processor : Intel Pentium 4 , 2.80 GHz > Cache Size : 512 KB > RAM : 1 GB > > > Result : > When I execute this program in the above machine using wine , I am > getting the same performance as in windows for the execution of the function > that is in the vendor supplied dll. > > > PC 2 ( with Enterprize Linux 4.0 ): > > Processor : Intel Xeon , with CPU - 2.80 GHz > Cache Size : 1024 KB > RAM : 2 GB > Result : > When I execute this program in the above machine using wine , the execution > time of the function that is in the vendor supplied dll is nearly 10 times > morethan as in case of first machine. > > Can any one has same type of observation earlier ? Is there any issue like > this w.r.t wine ? This is not too much data to do some speculations with. E.g. you don't even mention at all what your vendor function does (is it graphics-bound, CPU-bound, network-bound, ...?). I assume both machines have (almost) exact RHEL4 installation state. Are both using an SMP/SMT-aware kernel? Or one does and the other one doesn't? Also, there may be a severe performance hit if P4 is low-memory only whereas Xeon 2GB might be using 1GB low and 1GB high (high is more expensive since it needs remapping!!). Try changing Linux memory mapping (e.g. try booting with "mem=800M" first). Andreas Mohr
Re: dlls/wined3d/device.c GetCreationParameters
Hi, On Tue, Jan 17, 2006 at 11:16:42AM +0100, Alexandre Julliard wrote: > Aric Cyr <[EMAIL PROTECTED]> writes: > > > Ya, I thought about that after I sent my previous mail as well... an assert > > would probably be more useful for checking "This". I also disagree that > > "This" > > is guaranteed to always be non-NULL. There really is no way you can force > > policy how a user calls the function, so minimally checking (or aborting) on > > NULL is a sane thing to do. It doesn't hurt the code, and catches potential > > usage problems. > > Not checking at all and crashing works just as well to catch problems, > and doesn't hurt performance. There's no reason to add NULL checks > unless there is a Windows app that depends on it. Exactly! "Stupid" NULL pointer checks even actively hurt debugging since in severe cases you may have a function "properly" (*cough*) failing due to a NULL pointer check, but then "unfortunately" you notice the effect of this "properly checked" anomaly "only" 3 layers and 5000 relay log lines later when something almost entirely unrelated really breaks with a SEGV. Have fun wasting the time to trace back those 3 layers to the real offender... Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta
Re: Licensing question
Hi, On Wed, Jan 04, 2006 at 03:29:22PM +, Dominic Wise wrote: > I have a question regarding the use of portions of Wine in a commercial > application. Sorry if this is not the right place to post but I am not > sure who I can directly address this to. np (I don't think wine-users would be an appropriate place for such a specific question) > The application my employer develops is a financial application designed > to work on Win 2K and Win XP, but we have a need for a Win32 function > that is only supported in XP (TzSpecificLocalTimeToSystemTime). We could > write an implementation of this function ourselves for Win 2K but I have > noticed that there is a full implementation in Wine. Are you sure this is the only Win32 API with this exact functionality? There might be a good reason why it's been introduced at such a late date as XP+ only... cd wine; find . -name "*.spec"|xargs grep -i time.*time > Is it permissible to use the source for this function in our > application? If so, what provisions do we need to make with regard to > recognition of Wine and supply of source code to our customers ? Err... no. (at least not directly) While Wine's license (LGPL) allows linking to Wine components, it still carries the same restrictions as the GPL license when it comes to directly integrating such code in closed-source programs. However I think(!) that it's legally valid to gather some "inspirations" from such code if absolutely needed and then write your own implementation of this function, much preferrably by first looking at the code and then, completely isolated, writing your own quite different code. (anybody please correct me NOW if this is fatally incorrect!) But I'm afraid the best way to avoid license violations is to code this function without looking at the (L)GPL'd implementation of this algorithm, if possible. Another way *might* be to ask the original author of this function (see CVS logs) whether he permits you to use his *original*, *unpatched* version of this function. BTW, if you absolutely want to directly use Wine-related code in a commercial (or, to be exact: proprietary) application, then may I direct you to http://de.wikipedia.org/wiki/ReWind ? This is a source tree mostly consisting of the old Wine codebase before the MIT -> LGPL license change. Problem is that rewind is too old to already contain an implementation of TzSpecificLocalTimeToSystemTime(). > I am currently trying to demonstrate the benefits of Open Source > technology to my employer (I have already replaced one proprietary > third-party component in our application with a better Open Source > implementation) and this could really help to move this process along. Nice! (hopefully code that uses a license that's compatible with proprietary applications, though) > Longer-term, I want to try and get the application running on Wine, but > that's another story. ...preferrably by fixing Wine bugs if there are any, instead of adding Wine workarounds to the application. :) Andreas Mohr -- GNU/Linux. It's not the software that's free, it's you.
Re: winecfg: Problems with audio configuration
Hi, On Wed, Jan 04, 2006 at 07:14:02AM -0500, Robert Reif wrote: > Saulius Krasuckas wrote: > > >* On Wed, 4 Jan 2006, Robert Reif wrote: > >>The crash occurs in libartsc.so.0 as shown above. > >> > >> > > > >And why it can't be libartscbackend.so.0 ? > > > > > > > The point is that it is not crashing in winecfg or any wine code at > all. Adding an exception handler to catch a crash in an external > library may work but it's a workaround for a broken external library. > The external library needs to be fixed. Depends. If we are invoking it with "invalid" or "uncommon" parameters, then we do have something to be "fixed" (read: corrected) in Wine. Could that be the case here? However of course the external library ideally should never crash on invalid input, so they also have a bug to be fixed. Andreas Mohr
Re: Typo on download page for debian packages
Hi, On Thu, Dec 22, 2005 at 09:20:47AM +0100, Stefan Munz wrote: > Hi, > > I don't know who who is responsible for maintaining the website, but probably > he will read wine-devel ;-) > > I found a little typo on the download site for the debian packages. The link > to the repository works for me only without the space: > > deb http://wine.sourceforge.net/apt/ binary/ > > should be: > > deb http://wine.sourceforge.net/apt/binary/ This is not true, and further you could even see it from three locations that it's not: this line, the screenshot below, and the second line even further below (and from my own testing which confirmed that it's correct). Let me guess that you're not a Debian user, right? ;-) Andreas
Re: has the LGPL licence fell through ?
Hi, On Wed, Dec 21, 2005 at 07:48:09AM +, Aric Cyr wrote: > Seeing that SpecOps Labs history of ignoring Wine developers extends for more > than a year, then yes I can agree with that. Yup, there has been more silence than anything else. > According to their Partners' page, IBM and Turbolinux and a few others seem to > be footing the bill. I'm sure a well written email to either of those places > would get a real response, and probably apply due pressure on SpecOps Labs. Oh, now that's "interesting". Especially given that IBM's usual stance about Wine is often said to be... umm... let's say "mildly sceptical". But since the "Partners" text already mentions that it is an IBM Philippines cooperation, this seems to imply that the corporation's left hand doesn't know what the right hand is doing (yet! this might change in the future... Hello SpecOpsLabs!). Oh well... Andreas Mohr
Re: Steam Winsock regression
Hi, On Sun, Dec 18, 2005 at 11:51:01PM -0800, James Liggett wrote: > On Sun, 2005-12-18 at 23:50 -0800, Scott Ritchie wrote: > > On Sun, 2005-12-18 at 22:35 -0800, James Liggett wrote: > > > Hi, > > > For a while now I've been noticing a very bad regression in winsock with > > > steam. If I try to view information about a server using the "View game > > > info command," my Internet connection fails completely. Not only that, > > > but sometimes *all* of the machines on my network (both WinXP and Linux) > > > lose their connections as well. I did the usual drudgery and found the > > > offending patch: > > > http://www.winehq.com/pipermail/wine-cvs/2005-November/019293.html > > > > > > Can someone take a look at this one ASAP? Thanks very much! > > > > > > James > > > > Does that make this a security issue? > Maybe for people running Wines older than current CVS (this would > include 0.9.3, it has been fixed in current) Nonetheless, it's a pretty > bad problem, but the next release will include the fix. I don't think Scott meant it that way ;-) Who cares about Wine, here's a change that makes half the machines in the network lose connection randomly, that's much bigger things to worry about potentially than simply non-working Wine socket functionality... Thus one should probably attempt to investigate a bit more. Andreas Mohr
Re: http headers reworking
Hi, On Mon, Dec 12, 2005 at 10:30:48AM -0600, Aric Stewart wrote: > All fixes for Picasa. [...yet again] I'm sure Google will deliver us a fully working Wine reimplementation of IE on a silver tablet in exchange for all that trouble with their almost always nicely non-cross-platform "software", right? ;-) Andreas Mohr
Re: Outreach to windows ISVs
Hi, On Mon, Dec 12, 2005 at 02:55:26AM -0800, Dan Kegel wrote: > On 12/12/05, Andreas Mohr <[EMAIL PROTECTED]> wrote: > > >http://kegel.com/wine/isv/ > > > > Some important missing keywords/topics: "porting", "MFC", "Visual Basic", > > "Unix", "win32", "api", "toolkit". > > Those omissions alone would account for a > 50% internet search failure > > rate, > > I'm sure ;) > > OK, check it now! Muuuch better, thanks! And perhaps also mention wxwidgets.org (high MFC similarity) and Qt (good MFC porting support, AFAIK) somewhere on the sidelines (it's sorta off-topic), for the yet undecided. Andreas Mohr
Re: Outreach to windows ISVs
Hi, On Sun, Dec 11, 2005 at 10:33:00PM -0800, Dan Kegel wrote: > At the Desktop Architects Meeting at OSDL, one of the > big topics was how to make life easier for ISVs that want > to start supporting Linux. So I put together a little page > aimed at Windows ISVs who are interested in supporting > the Linux market using Wine, but aren't quite sure how to go about it. > The page is at >http://kegel.com/wine/isv/ > Comments, anyone? Big Fat Mistake: nothing relevant mentioned on that page. IOW, nobody will find it, and that's a problem since a vendor *needs* to search for such information since he certainly will not know your URL by heart ;) Some important missing keywords/topics: "porting", "MFC", "Visual Basic", "Unix", "win32", "api", "toolkit". Those omissions alone would account for a > 50% internet search failure rate, I'm sure ;) BTW, big thanks for all your Linux Desktop-centric efforts! Andreas Mohr
Re: fixme:font:load_VDMX Failed to retrieve vTable
Hi,
On Fri, Dec 09, 2005 at 10:53:33AM +0100, Curro Amores wrote:
> hi my reports are not well displayed on my access97 app.
>
> fonts are displayed i anora location and separed
> I got this fixme
>
> fixme:font:load_VDMX Failed to retrieve vTable
dlls/gdi/freetype.c:
if(WineEngGetFontData(font, MS_VDMX_TAG, offset, group, 4) != GDI_ERROR) {
USHORT recs;
BYTE startsz, endsz;
BYTE *vTable;
recs = GET_BE_WORD(group);
startsz = group[2];
endsz = group[3];
TRACE("recs=%d startsz=%d endsz=%d\n", recs, startsz, endsz);
vTable = HeapAlloc(GetProcessHeap(), 0, recs * 6);
result = WineEngGetFontData(font, MS_VDMX_TAG, offset + 4, vTable, recs
* 6);
if(result == GDI_ERROR) {
FIXME("Failed to retrieve vTable\n");
goto end;
}
This FIXME is quite confusing and should be fixed, since it's NOT at all
about the "common" vTable term, but instead a VDMX font-related table AFAICS.
Use winedbg, set a breakpoint on load_VDMX(), step through it until the
2nd WineEngGetFontData() (that one is failing!), then step through it
until you know what exactly fails.
Maybe even a simple freetype upgrade might resolve the issue?
(in that case we'd need to know which freetype version is problematic)
Andreas Mohr
--
No programming skills!? Why not help translate many Linux applications!
https://launchpad.ubuntu.com/rosetta
Re: Why Steam fails
Hi, On Mon, Dec 05, 2005 at 09:07:45AM -0500, Kuba Ober wrote: > On Saturday 03 December 2005 15:02, Ivan Gyurdiev wrote: > > I think I'm the only one with that problem... and I can't figure out > > what's wrong :( > > How's your swapfile size? Maybe your system doesn't do overcommits, thus > there > must be enough physical ram + swapfile for all virtual allocations. That'd be > the only thing that I could think of, although whether overcommits can be > disabled and so on I don't know. So I might be just rambling insanely ;-) overcommitting is default and I knew that there was a way top turn it off, so a find /proc -name "*commit*" found: /proc/sys/vm/overcommit_ratio /proc/sys/vm/overcommit_memory Oh wait, it seems it's not default: $ cat /proc/sys/vm/overcommit_memory 0 Andreas Mohr
Re: advpack: Handle dwFlags for DelNode with tests
Hi,
On Thu, Dec 01, 2005 at 02:45:37PM +, James Hawkins wrote:
> On 12/1/05, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> > James Hawkins <[EMAIL PROTECTED]> writes:
> >
> > > +/* Generate a path with wildcard suitable for iterating */
> > > +if (CharPrevA(szFilename, szFilename + iLen) != "\\")
> > > +{
> >
> > I don't think this means what you think it means ;-)
> if the check is what's wrong. Am I missing something?
Yup, you're missing a lot :)
String pointer address comparisons don't really make a lot of sense...
Andreas
Re: Allow to display all builtin Wine video codecs inICCompressorChoose
Hi, On Fri, Nov 25, 2005 at 06:12:03PM +0800, Dmitry Timoshkov wrote: > "Andreas Mohr" <[EMAIL PROTECTED]> wrote: > > > > All the codecs except ir32_32 return dwVersionICM set to ICVERSION > > > (0x0104), > > > so that looks like a common practice. However dwVersion field doesn't look > > > like a reasonably set at all. I decided to follow msrle32 and set to > > > 0x0104 > > > as well. > > Sorry, bad decision IMHO. > > Everything indicates that ICVERSION is always used for dwVersionICM > > only, so you shouldn't give the impression that it could be used for > > dwVersion, too. > > IMHO it's much better to choose an arbitrary value for dwVersion with > > a FIXME comment behind it. > > I don't see how a FIXME could improve Windows drivers behaviour to return > arbitrary values in the dwVersion field. IMHO it's much better to use > a definitive and reasonable one, and ICVERSION qualifies for that. "Definitive" yes, "reasonable" simply NO. (it is not customary to abuse ICVERSION for that, so one shouldn't do it; just doing Google "dwVersion ICVERSION" will make it obvious) Andreas
Re: Allow to display all builtin Wine video codecs in ICCompressorChoose
Hi, On Fri, Nov 25, 2005 at 05:37:00PM +0800, Dmitry Timoshkov wrote: > Hello, > > I've run ICGetInfo test on my XP and got the following results: Oh cool, quite persistent! > All the codecs except ir32_32 return dwVersionICM set to ICVERSION (0x0104), > so that looks like a common practice. However dwVersion field doesn't look > like a reasonably set at all. I decided to follow msrle32 and set to 0x0104 > as well. Sorry, bad decision IMHO. Everything indicates that ICVERSION is always used for dwVersionICM only, so you shouldn't give the impression that it could be used for dwVersion, too. IMHO it's much better to choose an arbitrary value for dwVersion with a FIXME comment behind it. Andreas
Re: Unable to start UTF-8 encoded executable in UTF-8 locale - one line fix included
Hi, On Thu, Nov 24, 2005 at 12:09:06PM -0500, Alex Villacís Lasso wrote: > Changelog: > * Initialize file_exists to 0 at exe load test, prevents mistaking > of UTF-8 encoded exenames as builtins. Isn't that almost *exactly* what mengzhuo li very recently sent? Is it the same place or the same problem in a different part of process.c? > I so wanted to be the first to provide the fix to the Open File > dialog not handling UTF-8, but Michael Jung beat me at it :-/ Uhoh, so my mail is bad news here, I'm afraid ;-\ Andreas Mohr
Re: Allow to display all builtin Wine video codecs inICCompressorChoose
Hi, On Thu, Nov 24, 2005 at 11:29:04PM +0800, Dmitry Timoshkov wrote: > "Andreas Mohr" <[EMAIL PROTECTED]> wrote: > > > On Thu, Nov 24, 2005 at 10:21:26PM +0800, Dmitry Timoshkov wrote: > > > +icinfo->dwVersion = 0x0001; /* Version 1.0 build 0 */ > > > +icinfo->dwVersionICM = 0x0104; /* Version 1.4 build 0 */ > > > > This doesn't really add up. > > If it made complete sense, Version 1.0 build 0 would be 0x0100. > > But then I assume this conflict is for real, no? (we all know why we love > > MS, > > no?) > > I didn't really test what Windows returns in that fileds, just copied > what msrle32 has. If you feel brave enough to test and make a patch go > ahead. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/htm/_win32_icinfo_str.asp says dwVersionICM should be set to ICVERSION, and Google says ICVERSION is defined as 0x0104, and other internet pages directly assign a 0x0104 value. dwVersion appears to be endianness swapped, too: I've seen 0 and 0x00020001 used several times. Andreas
Re: Allow to display all builtin Wine video codecs in ICCompressorChoose
Hi, On Thu, Nov 24, 2005 at 10:21:26PM +0800, Dmitry Timoshkov wrote: > +icinfo->dwVersion = 0x0001; /* Version 1.0 build 0 */ > +icinfo->dwVersionICM = 0x0104; /* Version 1.4 build 0 */ This doesn't really add up. If it made complete sense, Version 1.0 build 0 would be 0x0100. But then I assume this conflict is for real, no? (we all know why we love MS, no?) Andreas
Re: error of double click chinese name txt file in softwares (e.g winefile, WinRAR)
Hi, On Tue, Nov 22, 2005 at 03:02:16PM +0800, mengzhuo li wrote: > ChangeLog: > dlls/kernel/process.c > > limengzhuo [EMAIL PROTECTED] > > fix the error of double clicking chinese name txt file in software (e.g. > winfile). > > it shows the error > wine: cannot open builtin library for L"C:\\windows\\\6d4b\8bd5.txt" Thanks for the patch, but have you actually tested it and verified it to work? The spelling of the variable suggests you haven't... > int i, file_exists; > > +file_exitst = 0; Andreas Mohr
Re: PATCH: long registry lines loading
Hi, On Sun, Nov 20, 2005 at 05:45:13PM +0100, Marcus Meissner wrote: > I have this patch proposal, but I fear it might not fly with Alexandre ;) Not only with Alexandre, I'm afraid ;) Why not follow a dual strategy: use a static buffer for <= MAX_PATH and use a malloc()ed buffer if it exceeds that size? (ok, scrap that, static plus malloc() is a BAD idea:) Or, since the original buffer variable was static anyway, you could just *always* (re-)use an malloc()ed buffer and *grow* it whenever the previous size was to small... I haven't looked too closely at the code, but repeated malloc()/free() in "fast-as-lightning" registry code sounds like a terrible solution that can be easily transformed into something better here, it seems. Andreas
Re: MBR was destroyed
Hi, On Sun, Nov 20, 2005 at 08:49:12AM +0100, seorge wrote: > I've just submitted a bug (3889) about destroyed MBR and Dustin Navea asked > me > to subscribe to this list. Whatever will happen during this discussion (hopefully this problem will get fixed!), you should definitely install a new MBR there and then run a Linux boot CD with something like testdisk or similar (qparted or so?) on it in order to restore a proper partition table in your first HDD sector... Andreas Mohr
Re: What would most aid WINE development?
Hi, On Fri, Nov 18, 2005 at 10:00:22AM +, Aneurin Price wrote: > And on that note: does anybody know of any documentation anywhere for > msvcrt sopen? Particularly, what the different pmode flags mean (I'm > getting 0x01b6)... I've got an old grey folder with MSVCRT API documentation at home (together with tons of other API books ;), *maybe* those extra flags that I cannot find on the net are described in there. I will ask my family to look it up for me this evening. Greetings, Andreas Mohr -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There's nothing user-friendly about learning to read." -Alan Kay
Re: MSVCRT: _tempnam not working with environment variables
Hi, On Tue, Nov 15, 2005 at 04:46:37PM -0600, Phil Lodwick wrote: > ChangeLog: > _tempnam uses the TMP environment variable and does not truncate prefix Your diff file has strange DOS line endings (^M) and thus might fail to get applied by Alexandre. Try dos2unix or unix2dos or so. Thanks for your work! Andreas Mohr
Re: Mac os x on intel machines:---> WINE on Mac os X ??
Hi, On Tue, Nov 15, 2005 at 10:34:14AM +0100, Marc Coevoet wrote: > Since wine is unix/ linux, and runs windows apps, > I suppose it will be possible to run windows apps > on mac os x-intel, without the windows OS. > > Is there somebody aware of this / working on > the project ?? (a port) Google "wine mac intel" or similar would help (in short: "yes"). Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta
Re: GetQueueStatus: unknown flag 0x4000
Hi, On Tue, Nov 15, 2005 at 09:39:48AM +1000, Cihan Altinay wrote: > The program doesn't work with native ole so I can't confirm but after > some debugging it is clear now that ole32.dll is using flags like 0x4000 > and 0x4400. I guess they are 'magic' flags for ole. So they're probably trying to check for OLE related messages there. You could try to run a message spy app on Windows around the time that it does the GetQueueStatus() call with the 0x4000 flag. Maybe you manage to discover which kinds of OLE related messages GetQueueStatus() probably checks for... (then send suspected message types to a window and then run GetQueueStatus() 0x4000 to see whether it triggers) Andreas
Re: error:rpc:RPCRT4_OpenConnection protec msnmsgr not supported
Hi, (disregarding the issue in Subject) On Tue, Nov 15, 2005 at 09:35:30AM +0100, Curro Amores wrote: > hi, im trying to execute an application with access 97 and i get this error > I have replaced ole32.dll built-in with win98 version. That's not enough. You really need oleaut32, too: > fixme:ole:MSFT_ReadValue BSTR length = -1? > fixme:ole:ITypeInfo_fnAddressOfMember (0x7e7abc00) stub! But someone should really either implement this or tell me how to do it (I failed to find out how, in a reasonable time frame). Andreas
Re: privileged instruction in 32-bit code
Hi, On Fri, Nov 11, 2005 at 10:36:24AM +0100, Marcus Meissner wrote: > > (gdb) disassemble bar > > Dump of assembler code for function bar: > > 0x080495a0 : movaps %xmm0,(%ecx) > > 0x080495a3 : shufps $0xa,%xmm3,%xmm2 > > 0x080495a7 : add$0x90,%eax > > 0x080495ac :decl 0x4c(%esp) > > 0x080495b0 :movaps %xmm1,0x10(%ecx) > > 0x080495b4 :shufps $0x9d,%xmm3,%xmm2 > > 0x080495b8 :mov%edi,0x88(%esp) > > 0x080495bf :mov0x64(%esp),%edi > > 0x080495c3 :movaps %xmm2,0x20(%ecx) > > 0x080495c7 :jne0x80491b6 > > > > I'm now fairly sure it's failing on the first movaps command. Unless > > someone can direct me differently, I'm going to start looking at why > > that command is showing up as 'privileged'. > > Does your machine support SSE2 instructions? I guess this is the problem. Thinking that stuff a bit further: I'd guess that an app usually knows when to use SSE2 and when not to use it (since it'd most likely crash the same way on Windows if it was wrong!). IOW, do we have an issue with some SystemInfo API indicating that we *have* an SSE2 CPU here when we actually have not, and thus the program chooses to switch to the improper code path? Andreas -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta
Re: [winternl.h]Add missing header file
Hi, On Thu, Nov 10, 2005 at 06:29:41PM +0100, Süt? Gergely wrote: > ChangeLog: >Add a missing stdarg.h includes. > > This is my first patch please check it! :) Call me stupid, but where exactly do you see Wine's stdarg.h header file implementation? I don't see nothing anywhere... ;) (except in some weird Windows SDK maybe) Andreas
Re: A small bounty for fixing a bug
Hi, On Wed, Nov 09, 2005 at 11:12:03PM +0100, Willie Sippel wrote: > I'm sorry if a request like that is not allowed/ wanted, I couldn't find any > info regarding bounties on bugfixes. No, I'd say if anything, then the OSS area should see *more* bounties, certainly not less! (I cannot even remember the last Wine bug bounty...) Thank you for your contribution towards improving the Open Source ecosystem! Andreas Mohr
Re: Small CVS-Update-Script
Hi, On Wed, Nov 09, 2005 at 10:18:42PM +0100, Christian Lachner wrote: > OK, this is version 3.5 which is mainly an Bugfix-Update to version 0.3. For such a colorful and monstrous script it's "interesting" to see that it doesn't even support our CVS mirror server out of the box... (which should be MUCH faster at least for European users, BTW) Andreas Mohr
