Re: [X11DRV] Fix crash on bad fonts...
On Sat, Jul 05, 2003 at 12:37:04PM +0200, Lionel Ulmer wrote:
> Hi all,
>
> It seems that a lot of people out there are still using the 'old' core fonts
> rendering path for fonts (maybe one familiar with 'wineinstall' should have
> it print a help message telling people to install the MS core fonts in their
> Windows/Fonts directory).
>
> As seen on bug 1555 (http://bugs.winehq.com/show_bug.cgi?id=1555), the call
> generating the X11 error is 'XLoadQueryFont'. So let's protect this with our
> own X11 error mechanism as we do for DGA2 for example and do as if the
> loading of the font failed.
>
> This was not tested yet as I did not find an user who 1) had built Wine
> himself and 2) had the font issue. But well, according to 1555, it should
> work :-)
>
> Changelog:
> - do not have Wine crash when trying to load bad fonts
>
> --
>Lionel Ulmer - http://www.bbrox.org/
> Index: graphics/x11drv/xfont.c
> ===
> RCS file: /home/wine/wine/graphics/x11drv/xfont.c,v
> retrieving revision 1.114
> diff -u -r1.114 xfont.c
> --- graphics/x11drv/xfont.c 18 Jun 2003 19:45:22 - 1.114
> +++ graphics/x11drv/xfont.c 5 Jul 2003 10:31:32 -
> @@ -2014,6 +2014,11 @@
> *
> * Build font metrics from X font
> */
> +static int XLoadQueryFont_ErrorHandler(Display *dpy, XErrorEvent *event, void *arg)
> +{
> +return 1;
> +}
Why not print a user message here that such and such font might be broken?
Andreas Mohr
Re: spelling/typo fixes ect. -- lostwages
On Fri, Jul 04, 2003 at 12:47:21AM -0400, Tom Wickline wrote:
>
> Hi,
>
> Happy 4th :)
>
> Changelog
>
> 1) spelling/typo fixes 2) missilanious fixes
If you decide to do 1), then it might be useful to also do that for 2)
at the same time...
Or should this be the militarian form of miscellaneous? :-))
("missilanious wrong coordinates were used to bomb the site")
Anyway, thanks for your janitorial work! It's an important task!
Andreas Mohr
Re: QueryPerformanceFrequency bugfix
Hi, On Sun, Jun 29, 2003 at 04:05:04PM +0100, Mike Hearn wrote: > This patch stops the demo of Settlers 4 crashing at startup. > > ChangeLog: > Add some traces > A Mhz is 1000Hz, not 10 Wha!? First, it's 100, which is one zero more than what you wrote (and what the code used: +100.0). Second, one MHz *IS* 100Hz. So there are two possibilities: a) the code should calculate the result in units of kHz (then your observation would be correct) b) you are (completely? ;) wrong Andreas Mohr
Re: dmusic: framework for file loading
On Sun, Jun 22, 2003 at 03:12:43PM +0200, Rok Mandeljc wrote: > As I've mentioned, we'll need a function for loading chunks from dmusic > files. I tried to write one, and here's result; it's not very nice, but > it works (sort of). > At the time being, it only "loads" and displays data > (--debugmsg=+dmfile for debug and --debugmsg=+dmfiledat for the display > of data). I couldn't make it load data into IDirectMusic*Impl > interfaces, because whatever I did, exception occured (maybe someone > more familiar with this could do this (Raphael?)). Also, if someone has > more robust and simpler function, please tell me. > DMUSIC_FillSegmentFromFileHandle loads sample.sgt from DX SDK > completely... however, i didn't try the other. > > Also "fixed" a problem I've encountered while running 3DAudio.exe (from > SDK). One of the latest patches added this clause: > > if (!ppDirectSound) > IDirectSound_Release(*ppDirectSound); > > I don't know why, but it causes exception (i've commented it). Would you PLEASE remove the ! instead of commenting the whole stupid thing!? Aargh, too easy... ;) Andreas Mohr
Re: Bidi B3 - GetCharacterPlacement final cleanups
Hi, On Sat, May 31, 2003 at 06:49:57PM +0300, Shachar Shemesh wrote: > Apply with -p1 > > Changelog: > Shachar Shemesh <[EMAIL PROTECTED]> > >* Removed all redundant "GetCharacterPlacement" code from the > internal reordering function. WINE_BiDi_reorder now does only that. >* Removed all reordering code from "GetCharacterPlacementW". It now > has only the non-reordering stuff, calling "WINE_BiDi_reorder" for > the reordering code. Nice ChangeLog! And... what am I supposed to apply with -p1 here? Your mail or what? :) Andreas Mohr
Re: Bultin OCX?
Hi, On Thu, May 29, 2003 at 06:20:11PM +0100, Mike Hearn wrote: > > Err, we are trying that. > > Hmm, you want to create an Explorer clone as well? MS Paint? What I > meant was, it's not necessary to recreate every aspect of Windows the > desktop. Windows the platform yes, maybe. Naah, probably not an Explorer clone (unless we need a special one to support Wine-specific features, that is, and even that could be done instead by asking a well-established Explorer clone to support these Wine enhancements...) We're talking about *system* parts, and the relatively widely used Winsock OCX DEFINITELY falls under that category. (together with several other important OCXes in windows/system/) > > And a standard winsock OCX falls uder the > > "to be done" category for me. > > Ok, cool. I'd guess it's like MFC, nice to have but as apps usually ship > with it, not critical. But if somebody is going to write it, then that's > great :) Yep, it's sort of an "enhancement", since the native Winsock OCX should hopefully work with our own builtin Winsock DLL, so no need to write something here and now. (although it'd be cool to have it here and now, of course!) However if this OCX does NOT work with our Winsock, then please yell immediately. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: msdos/int21 CREAT special cases
On Mon, May 26, 2003 at 01:04:49PM +0200, Ferenc Wagner wrote:
> Volume label creation should fail, not create a regular file.
> Similarly for file names ending in a slash (this is actually
> needed for PKSFX Version 2.04g to unpack directory trees).
>
> Feri.
>
> Index: msdos/int21.c
> ===
> RCS file: /home/wine/wine/msdos/int21.c,v
> retrieving revision 1.93
> diff -u -r1.93 int21.c
> --- msdos/int21.c 19 May 2003 21:40:05 - 1.93
> +++ msdos/int21.c 26 May 2003 10:48:21 -
> @@ -474,8 +474,18 @@
> }
> static BOOL INT21_CreateFile( CONTEXT86 *context )
> {
> -SET_AX( context, _lcreat16( CTX_SEG_OFF_TO_LIN(context, context->SegDs,
> - context->Edx ), CX_reg(context)
> ) );
> +LPCSTR path=CTX_SEG_OFF_TO_LIN(context, context->SegDs, context->Edx);
> +
> +if (CX_reg(context) == 0x0008) {
> +SetLastError( ERROR_ACCESS_DENIED );
> +return TRUE;
> +}
> +if (path[strlen(path)-1] == '/')
> +{
> +SetLastError( ERROR_FILE_NOT_FOUND );
> +return TRUE;
> +}
> +SET_AX( context, _lcreat16( path, CX_reg(context) ) );
> return (AX_reg(context) == (WORD)HFILE_ERROR16);
> }
Hmm, and is there a reason to not do it in _lcreat16() instead?
Or is _lcreat16() really "clever" enough to handle volume labels
"properly" if called directly?
Somehow I doubt it... ;)
Or in fact you could walk further up the chain and maybe find that even
_lcreat() should be the function to have that check instead...
(or, for that matter, even CreateFileA and thus CreateFileW...)
So my rough guess is that this should probably be prevented in CreateFileW
instead even.
--
Andreas MohrStauferstr. 6, D-71272 Renningen, Germany
Tel. +49 7159 800604http://mohr.de.tt
Re: Fix incorrect documentation
Hi, On Fri, Mar 28, 2003 at 04:35:36PM +, Mike Hearn wrote: > I'm surprised nobody caught this one in my previous (duff) patch... the > "uninstaller" app appears to have been forgotten about. Well, I'd caught this in my update, but your version is somewhat better. Applied it ;-) I'm *almost* done with that stuff... -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: GIT implementation
On Sun, Mar 09, 2003 at 08:17:28PM +, Mike Hearn wrote: > With this patch, RhymBox makes it to the login screen now! :) > > ChangeLog: > - Implement the global interface table object using a simple linked list > - Connect it via CoCreateInstance HEY, you're supposed to work on your autopackage installer!! Quick, go back to doing Real Work, now will you!? Quit playing with Windows toy programs! :-) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: wineconsole
On Sat, Mar 08, 2003 at 09:23:59PM +0100, Eric Pouech wrote: > another regression fixed... > > this time sounds like I forgot to put back this line in after a couple > of other testings... :-/ > > this would make Dan even angrier, but also get rid of the several > win32-consoles on the same unix-terminal issue Dan was > experie^H^H^H^H^H^H^H banging his head into While you are at it, you could also fix the busy-loop in the cmdline parsing resulting from feeding an unknown parameter string ;-) (such as --BaCkEnD=XXX) (better use automatic advancing to the next argument instead of only manually advancing if the parsing of the last parameter was successful) -- Help prevent Information Technology Fascism! - before it's too late... http://www.againsttcpa.com
Re: SystemParametersInfo patch
On Wed, Mar 05, 2003 at 11:48:54AM +0100, Jon Bright wrote: > Hi, > > In the process of trying to get a component installed in Borland > C++Builder 5, I ran across an AV in SystemParametersInfo as a result of > a bug in the component. It seems Windows checks for NULL being passed > and returns an error instead of AVing. The attached patch makes Wine do > the same. Ah, good. Hmm, are you sure GetLastError() says zilch, nada? SystemParametersInfoA does have some SetLastErrors at other places... > (as an aside are patches preferred as MIME attachments or straight in > the mail here?) Straight in the mail is the usual way. However, after having raised some eye-brows, they will get applied anyway ;) -- Help prevent Information Technology Fascism! - before it's too late... http://www.againsttcpa.com
Re: patch move guides (each to there own directory)
On Mon, Feb 17, 2003 at 10:08:59PM -0700, Tony Lambregts wrote: > In order to make the documentation easier to maintain and use I want to > separate the guides each into its own directory. Basicly just move them > from where they are to where we want them. Argl. Somehow I'm afraid I won't like this too much ;) I'm currently working on a full-scale reorganisation of the Guides, and thus this is bound to get in the way... Either we apply that and I'll have to live with that, or I'll incorporate the changes into my tree... Or maybe I'm just barking up a non-existent tree (maybe it's pretty easy to sort out after all). Andreas Mohr
AppDB updated
Hi all, I just (well, not "just": more like a matter of a whole week or so) committed about 170 or so new entries to the AppDB, thus reaching a count of 1523 distinct applications. I guess I'm feeling really exhausted now... Anyway, have fun browsing the site at http://appdb.winehq.org ! Andreas Mohr
Re: [DINPUT] Fix some stupid game :-)
On Sun, Feb 02, 2003 at 12:46:22PM +0100, Lionel Ulmer wrote: > Hi all, > > Some games only Acquire the mouse device *if* we return an error on > GetDeviceData when the mouse in unacquired... > > So report this error as we should :-) Cool, this should fix a lot of games, hopefully. And maybe also Unreal Tournament (NOT 2003!), where I've been searching like frantic for that mouse acquire issue some time ago... Andreas Mohr
Re: PATCH: glibc 2.3.x and errno
Hi ! On Fri, Jan 24, 2003 at 05:20:12PM +0100, Marcus Meissner wrote: > Changelog: > Since glibc 2.3.cvs no longer exports __errno_location, we need > to overwrite the implementation in glibc/libpthread directly. Excuse me, but somehow I think this is p*ss poor. (and yes, I'm now marking you up for the dark side ;-) I mean, both Wine and glibc are successful (?) OSS projects, so they should be able to come up with something much better than this terribly embarassing solution (after all everybody knew that OSS development was a "superiour" approach, didn't they ? ;-). I for one would feel much better if we simply rejected that particular "broken" glibc version and supported a *new* glibc method of properly interfacing errno things in a newer glibc version... (maybe have some "advanced" setting in glibc that enables all sorts of funky interfacing capabilities in case a program needs it) After all if Wine needs this errno support, then there's probably a need for it, so it's glibc's bloody obligation to make sure there's proper support IMHO. BTW: why did they even choose to abandon a public errno_location ? Anyway, thanks for tackling this severe issue ! Andreas Mohr P.S.: Do you really think that Alexandre would commit it like that ? ;-)
Re: Packagers Guide Update #5
On Thu, Jan 23, 2003 at 11:42:31PM -0500, Tom Wickline wrote: > Changelog > > Update the Sample config IMHO this doesn't even have *any* business in the Packaging Guide. The guide should simply contain a pointer to the REAL sample config file, otherwise this exactly leads to the permanent updating mess which you just demonstrated ;-) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: * Hack * for Wine-20030115 DOSFS_Hash on Solaris 8 x86
Hi ! On Fri, Jan 17, 2003 at 08:40:30PM -0500, John Wehle wrote: > wine photoed reports it can't find GIFIMP32.FLT (and friends) > which prevents images from being imported. The trace is: > > trace:dosfs:DOSFS_GetFullName L"C:\\PROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIFIM > P32.FLT" (last=0) > trace:dosfs:DOSFS_FindUnixName /dos,L"PROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIF > IMP32.FLT" > trace:dosfs:DOSFS_ToDosFCBFormat (L"PROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIFIM > P32.FLT", df621770) > trace:dosfs:DOSFS_OpenDir "/dos" > ... > trace:dosfs:DOSFS_ReadDir Read: long_name: L"Program Files", short_name: (null) > trace:dosfs:DOSFS_FindUnixName checking L"PROGRA~1 " L"PROG~FBU " > > What happens is DOSFS_Hash hashes "Program Files" in an unexpected fashion > which prevents DOSFS_FindUnixName from realizing it matches ""PROGRA~1 ". > > The enclosed * hack * allows wine photoed to load images. It is * not * > the correct answer. One possible approach is to modify DOSFS_OpenDir_Normal > to generate "proper" short names after it has read all the directory entries. Hmm, somehow I don't think this is a proper solution. The reasoning being that you probably have a Windows partition in your Wine install with that ~1 path buried somewhere in the registry or so. And IMHO if the registry contains such a setting (*from installation only* - a program most likely wouldn't create a ~1 .3 shortcut pathname on its own !), then we are SOL and probably should keep it like that instead of adding hacks that probably don't improve the code a whole lot. Instead, people should install the program via Wine, thus gaining "proper" registry keys with "proper" 8.3 *Wine* hashing during the install via Wine ! We simply don't seem to have a way to have a *fixed* mapping of long filenames to the ~1 shortcuts used in Windows; that's why we need our hashing. (someone correct me if I'm wrong about this issue !) Or maybe I'm wrong and we should indeed try to cope even with such a pretty hopeless situation. Oh, and I just realized that maybe yet another patch from you might get rejected ;-\ (although I'm grateful for the discussion about that issue) Andreas Mohr P.S.: Please CC me on followup discussions - I'm not on wine-devel currently.
Re: Patch for Wine-20030115 heap allocation on Solaris 8 x86
On Fri, Jan 17, 2003 at 01:52:08PM -0500, John Wehle wrote: > Currently wine exits after complaining about an invalid heap during > startup on Solaris 8 x86. What happens is mmap is returning an address > above 0xc000 which HEAP_InitSubHeap passes to NtAllocateVirtualMemory > who rejects it. Perhaps someone familar with the code can suggest > a better solution or explain why the ADDRESS_SPACE_LIMIT check is there. Correct me if I'm wrong, but AFAICS this is even the third time that you submit this. Don't you think that it would have been time to ask Alexandre what the hell he's been thinking about constantly rejecting it ? ;-) Have a nice day ! -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Add filesytem type NTFS to config
On Mon, Jan 13, 2003 at 09:06:28PM -0700, Tony Lambregts wrote:
> Some program (VirtualDub) checks the fsname returned by
> GetVolumeInformation, to find the name of the file system, when it needs
> to write files that are larger than 2GB. It refuses to create the file
> when we return FAT but will successfully write the file when NTSF is
> returned.
>
> Change Log: add configuration option to report NTFS as the file system
> type for a drive.
Hmm, I'm not sure whether we should increase the preexisting Filesystem
type mess by doing that.
I've hated the "win95", "vfat" etc. syntax almost from the beginning
(well, to be fair, I think I'm not too innocent when it comes to its
implementation, but at some time I just came to the conclusion
that it sucked)
After all we're running on *Unix* file systems in many cases,
so "win95" does have no place here at all ! (neither does "vfat")
Not to mention that "win95" awfully collides with the "win95" winver...
And adding yet another "incorrect" "ntfs" setting makes my head
want to go bonkey ;-)
So I guess that it might be a good idea to think about how to solve this
configuration issue in a nicer way (and of course keep the old config
capabilities for about 2 years in order to have backward compatibility).
We might even want to think of introducing "nameless" filesystem type
settings (instead of having "broken" conflicting and "wrong" FS type names).
And of course it seems as if we also need a separate FS *name* setting
in order to have Wine return "NTFS" instead of "FAT" in your case...
So could we start a discussion about that perhaps ?
> Files changed: documentation/samples/config
> documnetation/configuring.sgml
> files/drive.c
Finally a beautifully implemented patch ! I hate having to clean up the
docu "after the fact".
> -;; DON'T use "unix" unless you intend to port programs using Winelib !
> +;; - "ntfs" for ext2fs (some program need this to write files > 2GB)
urks ! a significant portion of unix FS users
don't even use ext2fs...
> +;; - "unix" DO NOT USE unless you intend to port programs using Winelib !
Somehow that setting is also quite some pain...
Andreas Mohr
Re: fix shgetfileinfoW
On Wed, Jan 08, 2003 at 09:34:50PM +0100, Jürgen Schmied wrote: Content-Description: Mail message body > - fixed crash in winamp reported by andreas mohr Yay !!! That fixed it indeed ! (in other words: I just didn't trust you, so I had to try myself ;-) Andreas Mohr
Re: wineboot wininit patch 1
On Tue, Jan 07, 2003 at 08:19:19PM +0200, Shachar Shemesh wrote: > Changelog > Shachar Shemesh <[EMAIL PROTECTED]> > > programs/wineboot/wineboot.c > >* Added a print to indicate to user that installation is done. Hmm, I'm not sure whether that's an entirely good idea. It's probably more flexible to have the script invoking wineboot print such a message instead. (some people might want to have "hidden" execution of wineboot configured) But OTOH you could also solve that issue by configuring wineboot to be silent in such a case, so maybe having such a message is a good thing after all. Andreas Mohr
Re: Validate imagelists
On Tue, Dec 24, 2002 at 11:27:57AM -0800, Duane Clark wrote: > Changelog: > Validate imagelists with christmas magic. Huh ? > Index: dlls/comctl32/imagelist.h > === > RCS file: /home/wine/wine/dlls/comctl32/imagelist.h,v > retrieving revision 1.3 > diff -u -r1.3 imagelist.h > --- dlls/comctl32/imagelist.h 31 May 2002 23:25:44 - 1.3 > +++ dlls/comctl32/imagelist.h 24 Dec 2002 19:26:09 - > @@ -53,6 +53,8 @@ > INT nOvlIdx[15]; > }; > > +#define IMAGELIST_MAGIC 0x4C4D4948 "HIML" ?? Wouldn't that be more like 0x53414D58 ??? Merry Christmas, BTW ! :-) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: wineboot - Andy's version
On Tue, Dec 17, 2002 at 09:17:48PM +0200, Shachar Shemesh wrote: > Changelog: > Andreas Mohr > > programs/wineboot > >* Initial implementation This is exactly my implementation AFAICS. I could easily have submitted it on my own, thank you very much. Instead, I thought that somebody should refine some parts before submitting. Also, GUI.txt was meant to be an internal note only. Hmm, well, maybe it's indeed best to have it committed now and then get some improvements real soon. (like e.g. to have it integrated into startup) Andreas Mohr
Re: VarOr / oleaut32
On Mon, Dec 16, 2002 at 09:20:18AM +, Ben Clewett wrote: > [EMAIL PROTECTED] wrote: > >Hiya, > > > >What app shows this? Can I get hold of it - I should be able to knock > >something up for it as a test regardless, but it might not be til mid next > >week. > > > >Jason > > > > It's a VB6 application of our own description. I have not had a chance > to hack the source code to see where it comes into play, but probably > something to do with a third party DLL we use for remote database > connectivity. > > Thanks for the offer of a fix. > > I was hoping there was a generic fault, and somebody might have a > generic fix. Since it seems to be more indepth, I will try any get an > exact location of location of failure first. Even though I now implemented VarOr, I guess you might want to be careful about that and use a native oleaut32 instead, since oleaut32 contains tons of variant calculation functions (mul, add, and, xor, various conversions, div, round), so if there's *any* bug in there affecting some function your program uses, boom goes your data eventually. That's why I'd use native oleaut32 for production use. OTOH I'm still waiting for some builtin oleaut32 test reports ;) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
GetWindowTextLengthA()/WM_GETTEXTLENGTH issue
Hi all, Steuertipps PC 2003 (yeah, right, it's that time of the year again ;) has corrupted button text - drawing beyond the last actual string character. This is because the supplied OWL (Borland, I believe ?) DLL calls DrawTextA with twice the amount of string length (yeah, must be a Unicode issue, of course... :), thus forcing DrawTextA into drawing way too much. (side note: OWL seems to implement its own custom buttons) This doubled value comes from GetWindowTextLengthA() (0x14 bytes instead of 0x0e bytes), which thus comes from WM_GETTEXTLENGTH. WINPROC_UnmapMsg32ATo32W does for a WM_GETTEXTLENGTH unmapping: case WM_GETTEXTLENGTH: case CB_GETLBTEXTLEN: case LB_GETTEXTLEN: /* there may be one DBCS char for each Unicode char */ return result * 2; The button text in question is: L"&Schlie\00dfen" (aka "&Schliessen") (so it's a Unicode string with 0x0e units) MSDN says that both WM_GETTEXTLENGTH and GetWindowTextLength return inexact amounts of string lengths for certain Unicode/DBCS combos (and always at least as much as the minimum storage it requires). However, I guess that we really *shouldn't* double the string length in this case (I guess we better avoid that corruption ;). Hmm, any idea how the unmapping can be improved ? To me it seems that the generic unmapping in WINPROC_UnmapMsg32ATo32W is exactly the place where s^Hcrap happens. (there seems to be a pretty direct connection between GetWindowTextLengthA and DrawTextA) Andreas Mohr
Re: sound3d stub implementations, part I
On Tue, Dec 10, 2002 at 09:14:27PM +0100, Rok Mandeljc wrote: > I've managed to run ultima ix with openglide, but sound doesn't really work (3D >sound is silent). So I've decided to try to implement stubs in sound3d.c in dsound. >This is first part of it. It's my first real work, so someone please check it if it's >ok (it seems logical to me, but it could be wrong). Actually it seems quite illogical to me... Hint, hint: you forgot the patch ;-)) Andreas Mohr
Re: Some fixes in capabilities
On Tue, Nov 26, 2002 at 10:23:55PM +0100, Lionel Ulmer wrote: > Hi all, > > As long as we do not support multi-texturing in our D3D driver, fill the > caps properly. Now SS2 does not try to do multitexturing anymore (not that > it actually works now, it's just that it would break less :-) ). > > Note: is there a way from DLL X to activate relay debugging ? What happens > is that SS2 somehow freezes at one point and doing a relay trace from > the start is about a 3 GB file... So what I would like to do is at a > specific function in the D3D code that I know to be just before the > freeze, call 'activate relay' and voila, I have relaying on :-) (to be > able to do that for all DLLs would be even better). > > But well, considering DLL separation and all that, I doubt that this > would be possible :-/ Oh plze... I thought that at least the Wine developers are reading the wine docu properly... ;-) Let's see... first you use completely inacceptable words, and then you admit to never reading the docu... bad, bad, very bad guy. :) Read wine.man. It explains how to do relay logging for a single DLL. Although I'm afraid that this might actually be broken at the moment maybe :-\ -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview
Re: _stati64 (before _fstati64)
On Sun, Nov 24, 2002 at 09:35:53PM +0100, Stefan Leichter wrote: > Hello, > > by accident i have send this patch to wine-develop list instead of wine-patches. > This patch needs to be applied before my _fstati64 patch Err... and what had happened to *my* patch from Nov 09 ?? Duplicate work... urks ! :-\ -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview
Re: Wine's compatibility lists (updated)
On Mon, Nov 11, 2002 at 02:44:00PM +0100, Alberto Massari wrote: > Hi Carlos, > > At 13.27 09/11/2002 +0100, Carlos Lozano wrote: > > >Hello, > > > >It includes 3 lists, a gold list with applications what are > >working almost 100% in wine, a silver list with application > >what could be working in wine with some work in them, and > >the full list with every test done :) > > Speaking about IE 5.5, I was able to install it without first installing > dcom95/98 simply by placing rundll32.exe in the c:\windows directory. Oh. > I know that a pre-requisite of the compatibility list is not to have files > coming from a Windows installation, so I wanted to ask everybody: should be > build a built-in version of rundll32.exe (just like we have regedit and > regsvr32)? Or is this job already on the plate of who is in charge of doing > the "reboot" utility (a bunch of the RunOnce entries written by the > installer of IE are calls to rundll32.exe)? Or am I volunteering for the > job? ;-) Yes, this should be done (should be fairly easy, too). And yes, you are ;-) (and no, I'm not working on this part) Waiting for programs/rundll32/, Andreas Mohr
Re: Error while trying to run a wine
On Sun, Nov 03, 2002 at 08:47:21AM +0200, sean wrote: > When running wine with a program that i developed with with delphi 6. I get > the following error " variant array out of bounds" can anyone help me i dont > know where to start looking to fix this problem a) Are you really running latest Wine CVS ?? b) Sounds like it's oleaut32 (variants !) related. Thus check out a --debugmsg +relay,+ole logfile. Andreas Mohr
Re: winamp patch A0
On Sat, Nov 09, 2002 at 11:43:32AM -0500, Vincent Béron wrote:
> This doesn't seem the place to do it, since if we specify something
> different (in config) then the registry keys do not match, and some
> other app could possibly have some problems.
>
> Would it be possible to generate automatically those keys with a call to
> GetVersionEx or something similar?
I *knew* that it'd receive this reply ! ;-\
I've also been thinking about doing it semi-dynamically after a call to
GetVersion*(), but I was a bit unsure about it.
Should we do it like that ?
Note that these registry keys are a *global* thing (wineserver !), whereas
the version value returned depends on the wine *instance* ("smart" detection
algorithm). This could spell trouble...
--
"My attitude is, everybody should try competing with Microsoft once in their life.
Once."
- Marc Andreessen, former Netscape lead employee, in a "browser wars" interview
Re: wine button
On Fri, Nov 08, 2002 at 02:53:38PM +, Mike Hearn wrote: > Here is my first attempt. I'm hardly an ace designer, so feel free to > criticize, tell me to junk it etc. > > I did try at first to make a browser style button, but it was very hard > to make the wine logo fit in a way that didn't look odd, as it's largely > a vertical type of logo. Also, is the Windows logo usable? I'd assume > it's trademarked or something, but i've seen the 4 colour blocks used in > for instance icon overlays in KDE. Hmm, we could try to make a parody of the Windows logo maybe ;-) Any nice ideas ? > If it's thought that this is too large, I can either scale it, or try > and make another from scratch that is more button sized. MHO the grey area should be *behind* the Wine glass, not in front of the glass. Good design so far, but can someone think of some "chuckle" effect ? Andreas Mohr
Re: Wine 0.9 TODO v0.1
On Fri, Nov 08, 2002 at 08:50:49AM +, Mike Hearn wrote: > Random idea: might it be worth creating a "Works With Wine" button, > similar to the old web-browser buttons, these images could link back to > the page on winehq with a description and screenshot (or maybe the > appdb) and be sent off to the app maintainers. Obviously some (Microsoft > :) aren't going to put the button up anytime soon, but others such as > WinRAR etc may well do - it can't hurt to try and could be a good way of > getting some free advertising to Windows users who may have never even > heard of Linux before. > > I'm quite happy to try and knock up a design for this button and go ask > the developers for software we consider "Gold" to put it somewhere on > their site. So far most non-huge windows developers I've spoken to have > been pretty happy that their app works in Wine, so I don't think they'd > mind. > > Comments? Great idea, IMHO. We might want to make sure there is no conflict whatsoever between a certain point in time where it happens to work with Wine and a certain point in time when *Wine* is considered "Gold" and thus the app is *supposed* to work at that time, though. But OTOH that "certification" would probably simply translate into a web page where you can view which Wine version *exactly* with which Wine settings *exactly* has been made to work, so there wouldn't be a conflict.
Wine 0.8: VB compatibility !!
Hi all, I keep encountering people mentioning that VB stuff has lotsa problems on Wine. While I really can't say that I like VB, a lot of people seem to use it for critical tasks in companies on a daily basis, so it sounds like perfect VB compatibility would be utterly important. IMHO improving that should be a goal of 0.8.
Re: Docu updates question..
On Thu, Nov 07, 2002 at 10:41:31PM -0700, Tony Lambregts wrote: > Dustin Navea wrote: > > >There are 2 problems... > > > >1) I dont know any sgml (unless vim/emacs hides the tags or makes it look > >kinda like html) > >2) The wine guides as they are are so confusing to me on how to recreate > >winehq that I cant even get make_winehq to work... That may just be > >something I'm doing... Could someone explain to me how to get the docs > >"compiled" so I can see them as they should look? > > > >-Dustin > > > > > Well if you remeber we had this discussion about the same thing in bug > 727 http://bugs.winehq.com/show_bug.cgi?id=727 I would really like to be > able to build the documentation on my machine as well. So ANYONE that > knows how to help us PLEASE speak up. Oh come on, guys. Is it that difficult to read the README file ? The README file contains countless references to its documentation section, where it says that you're supposed to "make doc" in documentation/. The documentation compile process does need some fixing, though. A "make doc-html" (make target in toplevel Makefile; so you could assume that *this* builds the docu) craps out with a stupid FIXME: Only NROFF supported make[3]: *** [doc-html] Error 255 - at least for me. Also, "make doc" doesn't build HTML for me.
Re: FreeBSD configure fix
On Thu, Nov 07, 2002 at 06:21:14PM +0100, Patrik Stridvall wrote: > Gerald Pfeifer configure change broke FreeBSD 4.7 > This should fix it. ROTFL !! The "man who is constantly annoyed about having to fix stupid Linux breakage on *BSD" manages to break *BSD :-)) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Wine 0.8 TODO v0.2
On Thu, Nov 07, 2002 at 10:33:50AM -0500, Dimitrie O. Paun wrote: > On November 6, 2002 01:59 pm, Joerg Mayer wrote: > > How about providing a distributions directory where the (in)official > > maintainers for the distributions can just check in whatever they want > > once they are found/named? > > Let's just first find them, that's the hard part. We can figure out > where to put the binaries, once we have them around :) *That* > is not a big problem. I'd suggest a top-level directory like distrib/ or package/. Hmm, or is there some kind of "standard" on naming such directories to be used by the various package scripts ?
Re: Wine FAQ - call for a volunteer
On Tue, Nov 05, 2002 at 11:43:39AM +0100, Ulf Dambacher wrote: > Just one tip: > Why not use a wiki-Engine to creaate/maintain a faq, like e.g. > www.squirrelmail.net does? > I recommend phpwiki (http://phpwiki.sourceforge.net/) This way users can > maintain the faq and it is most up to date! The #1 problem of the FAQ in the FAQ-O-Matic was its maintenance, which has also been caused by users adding entries that either needed quite some attention or didn't make sense at all. I don't see how a Wiki would substantially change this. Thus it's probably really best to have the FAQ in CVS for everyone who's *serious* about properly maintaining it to be able to maintain it. (but given the earth-shaking previous amount of contributions, I guess that it might happen that the FAQ gets outdated again) Oh, and BTW, when I thought about doing a non-static "support area", I had also had a hard look at Wiki based systems, but went for the FOM instead... :)
Re: Interrupts / Move most of int31 to winedos
On Wed, Nov 06, 2002 at 01:32:07PM -0500, Dimitrie O. Paun wrote: > On November 6, 2002 01:19 pm, Andreas Mohr wrote: > > What's relevant is whether we still need to be able to use a real Win32s > > subsystem or not (and whether it's even still possible !). > > This is a hacky subsystem, and the associated code is hard to understand, > and maintain. I see no reason to support it, and only if it was just for > the simplicity we gain by dropping it, we should do it. It makes msdos work > more difficult, and that is a problem *now*. It is just an example how > we waste developer cycles on irrelevant problems like this. This is why > we should not try to keep every conceivable hack in the tree. While I get your point, you seem to be very eager to put everything into the worst possible light. May I suggest you say it with a somewhat sweeter voice next time ? ;-) (you know how harsh and proficient I can be at flaming back, so better don't challenge me ;-))) And yes, I certainly agree on removing it in case it is a problem (unless it's really needed to make some programs work, and even then it could be debated whether those programs that are broken enough to actually need an original Win32s subsystem are *really* worth supporting). -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: Interrupts / Move most of int31 to winedos
On Wed, Nov 06, 2002 at 12:12:45PM -0500, Dimitrie O. Paun wrote: > On November 6, 2002 11:47 am, Andreas Mohr wrote: > > If anyone needs that, I guess I could easily dig up the mail from Ulrich > > Weigand that explained the miracles accomplished at that time in great > > detail. (it was not much more other than pure luck that we were able to do > > what we did with Win32s support) > > That'd be good. Is there _any_ reasonable reason for not dropping > the silly Win32s altogether? Hmm, not sure. Check out the comment /* * If this is the first time we are called for this process, * hack the memory image of WIN32S16 so that it doesn't try * to access the GDT directly ... in msdos/vxd.c. We needed to support loading of the whole Win32s subsystem, at that time at least. Ulrich Weigand did the 0x1 offset shift because Win32s intended to create selectors with base addr 0x (not possible on Linux !), so he needed to shift all W32S address calculations by 0x1 to fight that problem. Anyway, that's probably irrelevant. What's relevant is whether we still need to be able to use a real Win32s subsystem or not (and whether it's even still possible !). Most likely we don't need it any more, since Win32s apps are *supposed* to work perfectly not only on Win3.1 + Win32s, but also on a real Win32 box (which doesn't have Win32s specific functions). And as Wine has pretty good Win32 support nowadays, it's probably not needed any more. The application that I had problems with at that time was a Win3.1 version of Mathcad, BTW (IIRC) (hmm, was it Mathcad 3.1 ??). And Ulrich had been some great help in making this stuff work ! I should probably try to run Mathcad 3.1 again and report any result. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: ComputerName
On Wed, Nov 06, 2002 at 05:55:20PM +0100, Martin Wilck wrote: > Am Mit, 2002-11-06 um 16.43 schrieb Dimitrie O. Paun: > > > Can you also please update the documentation as well (man pages, etc.)? > > Ok. Btw is there any specific reason why the man pages have not been > converted to Docbook yet? I really dislike hand-editing troff. Thank you very much for this offer to rewrite them in Docbook ! :) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Interrupts / Move most of int31 to winedos
On Wed, Nov 06, 2002 at 08:37:26AM -0800, Robert Amstadt wrote: > > >Sure, I know that (I'm working on DPMI32 which isn't for standard mode > >Windows programs), I was probably being a bit unclear about > >what I was wondering about. It is quite difficult to find any information > >about Win32s nowadays and everything I have found was suggesting that > >Win32s was for running Win32 applications on Win16. Since Wine does run > >Win32 applications directly it just made me wonder whether Win32s support > >is something that was once needed when Wine only had Win16 support. > > Win32s was an add-on to Windows 3.1 to allow it to run 32-bit Windows apps > before Win95 was available. The "s" in Win32s meant that it was a subset > of Win32 because features like threading and others simply weren't > available in Win32s. If anyone needs that, I guess I could easily dig up the mail from Ulrich Weigand that explained the miracles accomplished at that time in great detail. (it was not much more other than pure luck that we were able to do what we did with Win32s support) Andreas P.S.: Hello Bob: great to see you around again ! :) (and no, at *that* archaic time, *I* haven't been involved yet !)
Re: Lost Wages (round 2)
On Tue, Nov 05, 2002 at 05:04:20PM -0600, Jeremy Newman wrote: > On Tue, 2002-11-05 at 16:50, Jeremy Newman wrote: > > I blame IE here, but it could be Gimp's fault as well. > > Oh, how could I blame Gimp. Of course it's MS IE that is at fault. :-) > > Here is a good page on PNG support in browsers. > http://trific.ath.cx/web/png/ I'm starting to wonder silently whether that's *intentional* on Microsoft's part... After all *all* major Linux browsers support it properly... -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Lost Wages (round 2)
On Tue, Nov 05, 2002 at 02:38:43PM -0600, Jeremy Newman wrote: > I spent some time implementing my theme idea to the lostwages devel > version of the WineHQ website. > > Take a look at: http://lostwages.winehq.org Sweet ! Two issues, though: a) what about making menu headlines font +1 ? Would be better for the visually impaired people... b) HowTo ??? Has Wine ever had a HowTo ? (ok, I admit it, Wine even had a damn good HowTo, but it's already quite outdated now, and as we have the Guides now, I'm not sure whether we still need one) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Mozilla 1.0.1 Win32 works almost flawlessly
On Sun, Nov 03, 2002 at 07:04:49PM +0100, Jakob Eriksson wrote: > > > There you have it. > Yes, it's exciting. :-) > > > > Original Message > Subject: Re: win-mozilla on wine > Date: Sun, 3 Nov 2002 12:56:14 -0500 > From: "Dimitrie O. Paun" <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Organization: DSSD Software Inc. > To: Jakob Eriksson <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> > > > > On November 3, 2002 12:48 pm, Jakob Eriksson wrote: > >I just tried Mozilla 1.0.1 Win32 on Wine 20021031 > > > >Works mostly fine. Resizing works, I think it didn't a couple > >of months ago. > > This is great news. You should report this on the list, > so people know, and we can discuss there. If you don't > mind, of course. > > >The meny "File Edit View Go " etc is gone however. > >Strange? > > Yes, we should fix this. This is exciting, eh? :) Ugh, my issue still (I guess). I asked Alexandre to fix this, but he probably expected me to fix it instead. (by removing *all* of my menu related patches) The menu code needs *much* more refinement. Patches that "try" to cure the symptoms will only lead to many more problems, so I had asked Alexandre to revert all my patches. I'll care about that tomorrow... (err... today) Andi
Re: Interrupts / Move most of int31 to winedos
On Tue, Nov 05, 2002 at 06:47:35PM +0200, Jukka Heinonen wrote: > After this patch winedos contains almost complete int31 > emulation. What has not been moved to winedos is mostly > functions that require either W32S_WINE2APP or W32S_APP2WINE. > This makes me wonder whether Wine still needs to support WIN32S... Well, of course it does. Wine is supposed to run *all* reasonably new (i.e.: not "standard mode") Windows programs, and that does include Win32s IMHO.
Re: WineHQ menu (take 3)
On Tue, Nov 05, 2002 at 09:37:59AM -0500, Dimitrie O. Paun wrote: > On November 4, 2002 09:07 pm, Igor Izyumin wrote: > > Anyway, this can probably be solved by tweaking the stylesheet. Jeremy > > Newman came up with a different design, so I doubt that the current one > > will get adopted. > > OK, we can wait for now, but being on the subject, I _really_ hope > Jeremy will give the expanded menus a chance: they are so much more > explicit, they just make the site more 'open'. And that is Good! I second that. Hidden information seems to have been the *main* issue with the old site (yeah, I've had quite some discussions sometimes about certain things), so we should really have *more* than one level per default (and not more than two levels either, so you know what that now leaves us with ;-). In fact I dislike the preview (in this respect) even more than the current version, since it's a very tiny very non-informative menu. The current version, while not having two levels of menu info, at least has the very good excuse of being damn well visible. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: My WineHQ menu structure proposal
On Sun, Nov 03, 2002 at 12:41:29PM -0500, Dimitrie O. Paun wrote: > On November 3, 2002 12:26 pm, Andreas Mohr wrote: > > IMHO the CVS stuff should *only* be mentioned in the Wine User Guide (and > > the Developers Guide would explain the more advanced usage patterns). > > Then it'd be pretty easy to simply add a small "For CVS download of Wine > > source, see ". > > Why in Wine User Guide? Ideally, users should not have to deal with CVS > at all. The *only* reason this is so it's that Wine is very immature, > and changes quickly. But once we reach a stable release, this should > hopefully change a little. When I open the user guide, I want it to small, > and to the point -- it has to tell me the absolute minimum that I need to > know to run the thing. Note: ideally, it should be so easy, and intuitive > to run Wine, that we should not need a Wine User Guide! Hmm, I guess you're right. How about we throw away CVS in User Guide and document *all* CVS management issues in the Devel Guide and simply have a reference to the Devel Guide in the Users Guide when it comes to CVS ? WineHQ would then use a link to the Devel Guide only, of course. I think that makes quite some sense.
Re: My WineHQ menu structure proposal
On Sun, Nov 03, 2002 at 11:36:36AM -0500, Dimitrie O. Paun wrote: > On November 3, 2002 05:28 am, Francois Gouget wrote: > * I also hate the term "Application Database". It sounds too techy, > and it's one of the reasons I never used it. So I suggest > "Application Status" That's good, too. > * Minor nit, but I still don't like CVS under Downloads. First off, > nobody thinks about using CVS as a Download option. There is a big > semantical impedance mismatch here. CVS is viewed as a development > tool. Also people using CVS don't go to Download, and viceversa. > I think it's a mistake to group items based on their form/syntax, > rather than meaning/semantics. In this case, the grouping is based > on the fact that there are bits going across the wire, and I don't > feel it's a meaningful distinction for anyone. IMHO the CVS stuff should *only* be mentioned in the Wine User Guide (and the Developers Guide would explain the more advanced usage patterns). Then it'd be pretty easy to simply add a small "For CVS download of Wine source, see ". As the Wine Users Guide would have a link to the Wine Developers Guide for advanced stuff on its own, you even wouldn't need to mention the Wine Devel Guide CVS link, too... > * Something to keep in mind: the App DB menus don't render properly > in Konqy. If we're gonna standardize on that format, we should make > sure they render correctly in the OSS-world browsers. Bad, bad Konqy again ;) Good point, though. > I suggest we work off of your latest proposal, and suggest 'patches' > to it, if anyone feels there should be changes. But this does seem > to bring us closer to a universally accepted solution. Yay! Hmm, could someone yell "me!" when it comes to finding someone to mail a "this is it so far" status report to wine-devel ? I think it'd be good to have a mail describing the current agreement. And no, I won't do it, since I've got way too many things to do in the less than 2 hours left until my departure.
Re: My WineHQ menu structure proposal
On Sun, Nov 03, 2002 at 03:07:48PM +, Keith Matthews wrote: > On Sun, 3 Nov 2002 15:24:14 +0100 > "Andreas Mohr" <[EMAIL PROTECTED]> wrote: > > > On Sun, Nov 03, 2002 at 02:28:54AM -0800, Francois Gouget wrote: > > > * Who cares about an 'Applications Database'? What's that anyway? > > > Would a potential Wine user want to have dealings with a database? > > > Nah. Must be for geeks. What users want to know is what applications > > > run in Wine and thus that's how the menu entry and the thing itself > > > should be called: 'Supported Applications'. Even if the truth is > > > that it lists applications that do not work too. > > True. Application Database is somewhat non-descriptive. > > Well, why not call its item "(Non-)Supported Applications" then ? ;-) > > > This seems to be an area where conciseness and descriptiveness are > diametrically opposed. We will probably argue long and hard. My > contribution "Application Support States". Close, but no whole cigar ;-) I like "Application Support Progress" somewhat better. (and "Progress" has a coolness factor associated with it :) Although it's 3 not very short words, so that might disqualify it easily... Hmm, and what about doing away with "Support" entirely ? Then it'd be usable. > > > 6. Miscellaneous > > >6.1. Community > > >6.2. Related projects > > >6.3. Contacts > > >6.4. Legal > > > > Hmm, (almost) everything ok so far, but can't we do away with Misc ? > > Misc is so horribly non-descriptive. > > IMHO as last entry, it might be better to have "The Wine Team", > > which then includes Community, Contacts and Legal. > > I'm not sure yet about where to put Related Projects (probably About > > would be best), but apart from that... > > > Can't say I like 'Misc' either, and I do think that legal should be more > visible. The project is getting to be fairly visible to governments and > big corporations, and they like to check legalities early on. How about > 'Contacts and Legal'. Then you'd expel "Community", I think (it wouldn't really fit in there). But of course I'm aware that "Legal" might not easily get associated with "The Wine Team". Hmm, this could still need some improvement... -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview
Re: My WineHQ menu structure proposal - counterproposal
On Sun, Nov 03, 2002 at 07:52:09AM -0600, Igor Izyumin wrote: > On Sunday 03 November 2002 03:09 am, Dimitrie O. Paun wrote: > > On November 3, 2002 02:35 am, Francois Gouget wrote: > > > Too much nesting just hides information and forces the user to dig down > > > to find what he is looking for. > > > > I am sorry to do a AOL -- me too post, but I do agree 100% with Francois. > > For WineHQ, I _strongly_ feel it's a big mistake to have more than 2 levels > > of menus. Just top level, and a sublevel is more than enough. > > > > Here are the principles I used for my proposal: > > 1. Just two levels > > 2. The more some info is accessed, the fewer mouse clicks > > should be required to get to it. > > 3. Menus organized by usage patterns, rather then strict > > technical category. > > I agree with the first two, but the third is wrong. Information should not be > split up into illogical categories based on what you think is a logical usage > pattern. The fewer splits you can make, the better it is. If I'm looking > for a FAQ, I would first click on Documentation, but if it's buried in > "Support" I would not even bother clicking there. The best structure would > have clear, logical categories and you would not have to guess where a > certain document would be buried. Keep in mind that it is better to group > all information into as few logical categories as possible. There should be > no guessing involved. Agreeing 100%. > > Similarly, for the Development/Contributing. Time and again OSS > > project push only the "Development" part in front, scarring > > away non-programmers from contributing, just to realize later on > > that they do need a lot of non-programming help as well. Case in > > point, instead of spending my time on the controls, I do other > > things that could be handled by non-programmers :). It's a natural > > split, the Development area is very important for Wine, and people > > going there are not interested in items that are listed in > > "Contributing"; also, we should show people there are many other > > ways to contribute, appart from coding. BTW, the Contributing > > section is is Francois idea, but I strongly support it. > > OK, this section needs to be renamed, too. 'contribute' is a transitive verb, > and in a context of a free software project implies contributing code. A web > guru would never click on a "contribute" link because they think it's > instructions for sending in Wine patches. "Help out" or "Volunteer" or > something like that would be much more accurate. Great idea ! Contribute is in fact not "aggressive" enough, as it hides what the intentions behind that are. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: My WineHQ menu structure proposal
On Sun, Nov 03, 2002 at 02:28:54AM -0800, Francois Gouget wrote: > On Sat, 2 Nov 2002, Dimitrie O. Paun wrote: > > > This is my proposal for the WineHQ menu structure, > > based on the discussions I had with Francois. > > > > The Home Page should just be our news page. Many > > projects opt for this, and I think it's good: > > News are 'zero' click items. > > I think the home page should be targeted to people who may not know what > Wine is. Thus it should *answer* the question 'What is Wine'. The Gimp's > web site (http://www.gimp.org/) is a good example in that respect. The > first paragraph of the page answers the question 'What is the GIMP?'. > > Thus I think there should be a link to the News page but no more. The > news page is for returning visitors and if that's what they care about > then they should bookmark that page rather than the home page. I think nobody does that. Whenever *I* visit a page, I'm visiting it in order to know the latest facts about a project. And let's face it, there are only so many n00bs compared to long-time Wine users. I'd be willing to bet that 60% of WineHQ traffic is caused by long-time Wine users, and the rest is newbies. And what long-time users want is *news*. > Other things I have now realized: > > * I said before I prefered a non-expanded menu (again, ala Gimp) to a > fully expanded one. Now I changed my mind. If the menu is not fully > expanded from the start then it's hard to figure out what the heck is in > the unexpanded items. Proof: the current WineHQ site. Other proof, The > Gimp's web site. Click on Documentation. Wow! Eleven items appear! > Before expanding the menu, did you know that mailing list was in > Documentation rather than in Resources? No? Well, you had no way of > knowing anyway. True. IMHO we should try to have two levels by default, and a third hidden level if need be (on the resulting page). > * That brings me to another point. I like the menus in Bugzilla and the > Application Database: >http://wine.codeweavers.com/bugs/ >http://appdb.winehq.com/ >I vote for using the same system for WineHQ. This would also bring a > better unity of style. Each top-level menu is a 'box' that contains all > the level two menu items. Sounds good (if it's doable). > * Who cares about an 'Applications Database'? What's that anyway? > Would a potential Wine user want to have dealings with a database? > Nah. Must be for geeks. What users want to know is what applications run > in Wine and thus that's how the menu entry and the thing itself should > be called: 'Supported Applications'. Even if the truth is that it lists > applications that do not work too. True. Application Database is somewhat non-descriptive. Well, why not call its item "(Non-)Supported Applications" then ? ;-) > * I'm moving the Who's Who to the development section. Now it seems > clear to me that people trying to have an idea about what Wine is don't > care about Who's Who. On the other hand, developpers, i.e. people more > involved with the project, would certainly be interested to know > more about their fellow developpers (in fact it's almost a developper > list). No, it's a developer list ;-) > * Contributing is important. I'm glad Dimitrie agrees with me. But now > I'm not sure we should have a menu entry for each of its sections. So I > moved it to 'About Wine'. This means it gets nearer where people new to > Wine (i.e. who are not involved in Wine yet) are. Maybe that compensates > a bit... I think that that one *at least* also needs a link on the Development section if we don't have a separate Contributing section. > * In the same spirit there are things that must be there but that fewer > people would look for. So I created a 'Misc' top-level section which > would be the last section to regroup these and unclutter more important > sections such as 'About Wine'. >As a guiding principle I tried to imagine someone new to Wine who is > not a developper, determine what he will want to see first, and put > these first. Then come potential developpers but I know they will zoom > in on the 'Development' and 'Forums' categories and go there. > > > So, here goes: > > Home > (no menu item for this one, just click on the Wine logo) > > 1. About Wine >1.1. Introduction > a. Intro > b. Why Wine > c. Myths > d. Technology > e. History > g. Companies >1.2. Screenshots >1.3. Supported Applications >1.4. Contributing > a. Application maintainer > b. Bug triage > c. Website maintenance > d. Development >1.5. News >1.6. Press > > 2. Download >2.1. Binaries (installing from binaries) >2.2. Source (installing from source) >2.3. CVS(installing from CVS) > > 3. Support >3.1. FAQ >3.2. Howto >3.3. Bug Tracking >3.4. Troubleshooting >3.5. Forums > a. Mailing Lists > b. Newsgroup > c. IRC Channel > > 4.
Re: My WineHQ menu structure proposal - counterproposal
On Sun, Nov 03, 2002 at 09:43:40AM +, Keith Matthews wrote: > On 02 Nov 2002 23:51:01 -0600 > "Jeremy White" <[EMAIL PROTECTED]> wrote: > > > > > > So, I propose the following instead: > > > > First, this assumes that we use Jeremy Newman's idea of a rotating > > screen shot on main page, and continued prominence of the news. > > > Ugh. Why do people insist on thinking that 'sexy' images are the be-all > and end-all of web design. When I go to a web site I want _information_, > not some bandwidth-soaking image that gives nothing useful. Have > screen-shots for those that can't see beyond them, but don't put them on > the home page, put a clear link to them. > > A lot of people are still on analogue dial-up links, they don't > appreciate large images increasing download time, I'm on DSL and I > switch off images to get faster downloads. But a screenshot showing a sufficient amount of information should only have about 5 KB or slightly more (I hope :). Also add a subtitle describing the current screenshot, and then 5 KB "ought to be enough for everybody" to be interested about a particular screenshot. > Other than that you may want to promote 'legal' to the top level, if > only to reduce the number of menu options for item 1 at the next level. > 9 is as many as one should have and 7 is a better limit. Yep, 7 is the standard amount of things you can manage/grasp. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: menu resource parsing question...
On Sat, Nov 02, 2002 at 09:07:08PM -0500, Chris Morgan wrote:
> Upon the testing of Kazaa lite I ran into numerous errors like:
> err:menu:MENU_ParseResource not a string item, flags: 0x0800
>
> These entries appear to be intended as separators and in fact the flag of
> 0x800 is MF_SEPARATOR. The code in question is :
>
> if (!IS_STRING_ITEM(flags))
> ERR("not a string item, flags: 0x%04x\n", flags );
>
> Where IS_STRING_ITEM is a macro:
> #define IS_STRING_ITEM(flags) (MENU_ITEM_TYPE ((flags)) == MF_STRING)
>
> And:
> #define MENU_ITEM_TYPE(flags) \
> ((flags) & (MF_STRING | MF_BITMAP | MF_OWNERDRAW | MF_SEPARATOR))
>
> So, what appears to be occuring is that Kazaa is passing in MF_SEPARATOR as a
> flag and wine expects instead to get a MF_STRING with a string of null and in
> MENU_SetItemData() it does 'flags |= MF_SEPARATOR;'
>
> I'm only posting to wine-devel because this check has been in the code since
> the initial import into cvs and I wanted to see if anyone knew more of the
> background on the issue. The fix is pretty simple, just ignore the fact that
> IS_STRING_ITEM() returns false. The rest should be taken care of by the
> existing checks.
Hmm, so if I understand you correctly: simply make the ERR a WARN ?
Or does that negative IS_STRING_ITEM test really make a difference in code,
too ?
In this case that'd probably have to be changed, too.
But you might want to make sure that *only* this case is being disregarded;
any other anomalies should trigger the alarm line.
--
"My attitude is, everybody should try competing with Microsoft once in their life.
Once."
- Marc Andreessen, former Netscape lead employee, in a "browser wars" interview
Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
On Sat, Nov 02, 2002 at 07:17:28PM -0800, Francois Gouget wrote: > On Sat, 2 Nov 2002, Andreas Mohr wrote: > [...] > > The only advantage I can think of would be the use of Unix code, but then > > you could achieve the very same thing by writing the Unix equivalent DLL > > of a Windows DLL (e.g.: hardware access or so) and using the Unix specific > > DLL version instead on Wine. > > That's one of the advantages and it allows you to do things you would > probably not be able to do by just loading a Winelib dll from a non > Winelib application. One such thing is mixing Win32 windows with QT ones > in a single application. This is not a pipedream, it has already been > been done on a large application at least once. Umm, that's all fine and dandy, bu I was coming from the other direction ;-) Using a program on *Wine* that loads a DLL built into this customized version of Wine that does the Unix interfacing. The Windows version of the DLL would do the hardware communication on Windows. But you're right, that certainly sounds impressive. > The other advantage of course is that Winelib makes it possible, at > least in theory, to port your application to non x86 platforms like the > Sparc or PPC. In fact I think the path to removing the x86 monopoly is: > 1. run existing Windows applications using Wine > 2. Linux grows market share > 3. Wine improves enough on non-Linux x86 Unix platforms (FreeBSD, > OpenBSD, Solaris) that you can run Windows apps on them as well as on > Linux > 4. now that Linux has a significant market share on the desktop ISVs > start taking Wine into account when designing applications > 5. ISVs use Winelib to migrate off the Win32 API to more cross-platform APIs > 6. ISVs use Winelib to port their applications to non x86 platforms or > port them directly if they already moved off Win32 using Winelib as a > transition True. I guess it might very well happen that Wine gradually becomes a release requirement for applications. Just wait some time until more and more people (application "porters", that is) join the development plate, and you'll see Wine becoming more and more relevant (the fact that Wine is the only *real* Win32 platform on Linux definitely helps, too ;-). -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Wine FAQ - call for a volunteer
On Sat, Nov 02, 2002 at 11:47:43AM -0500, Dimitrie O. Paun wrote: > On November 2, 2002 12:27 pm, Thomas Wickline wrote: > > When your ready just let me know and we will go at it .. > > send me a list of things to start on.. > > OK, here's the TODO: > > 1. Extract the FAQ from the FAQ-O-Matic > This means also deleting it from there, to avoid > duplication, and confusion. We need to: > i. Separate the FAQ from troubleshooting > ii. Delete stuff from FAQ-O-Matic > Andy, how can we do that? Hmm, no idea :-) You should ask Newman to grant you access in case a normal user account on the FOM isn't able to delete the FAQ part. I'd have no trouble whatsoever deleting the FAQ part, though, so I could easily do this myself ;) > 2. Come up with a stylesheet based on the DVD FAQ >http://www.dvddemystified.com/dvdfaq.html >that's more in the spirit of WineHQ > > 3. Format the extracted FAQ, and put it on the site > > 4. Work on getting the SGML tools to do what we >want, so we can write the FAQ in XML, like so: > > > > What is this for? > Nothing in particular, it's just cool. > > Ah, that sounds cool indeed !
Re: Wine FAQ - call for a volunteer
On Sat, Nov 02, 2002 at 11:01:48AM -0500, Dimitrie O. Paun wrote: > > Jeremy White wrote: > > Okay, we have a backup FAQ volunteer. Who will be our primary? > > It's always easier to criticize, than to do. If you do something, > you're bound to make mistakes. If you never do anything, you can rest > assured that you're not a fault. So, to get a taste of my own medicine, > I will coordinate the FAQ work, if people are OK with it. Give everybody > a chance to flame me to a smoldering bit. ;) Sounds damn good to me. So again, the idea was that the FAQ part should get converted into SGML source for easy conversion etc. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Today wine's compatibility with 20 popular apps from tucows
On Sat, Nov 02, 2002 at 04:53:03PM +0100, Carlos Lozano wrote: > Hello :) > > I have taken the 20 first entries of the top 100 tucows list, > except that some entries has been removed, mainly antivirus > and programs what need other different program to work. > (URL: http://tucows.uam.es/toppicks.html) > > Comments, improves, ... are welcomed :)) Cool stuff ! > 4. WinZip - The most popular compression utility for Windows just got better. > >VERSION 8.1. >* Install: Yes. (Dlls installed none) >* Run: No, it needs riched20.dll to shown the text in zipped files what > includes a message, zipped files without messages works fine. Hmm, why No here ? AFAIR WinZip works pretty well. > 10. Winamp - This program has so many possibilities and offers such a wide > range of interfaces, you'll need no other player. > > VERSION 3.0: > * Install: Yes. (Dlls installed none) > * Run: No. (Need native msvcrt.dll then works) This should definitely be looked into (might be easy, too). We really should be able to run Winamp out of the box. > 13. Fruityloops - Make your own MIDIs, WAVs and MP3s in minutes. > > VERSION 3.56: > * Install: Yes. (It will install fruitloops in the directory what you are > when run the installer, it is a buggy because you must stop the > instalation with ctrl+c when it will ask by "overwrite files", but > it works). > * Run: No. (Need hhctrl.ocx native, with it the program runs, but i haven't > used it before :/) "Windows syndrome" - you'd have needed hhctrl.ocx on Windows, too, no !?!? Hmm, or is hhctrl.ocx a standard Windows component ? > 18. Easy CD-DA Extractor - This program rips CDs, converts audio files between > different formats, and creates audio CDs from WAV and MP3 files. > > VERSION 5.0. > * Install: Yes. (Dlls installed advpack.dll, drmv2clt.dll,msdmo.dll, >w95inf16.dll,wmnetmgr.dll,asfsipc.dll,l3codeca.acm,msnetobj.dll, >w95inf32.dll,wmstream.dll,blackbox.dll,laprxy.dll,msvcrt.dll,wmadmoe.dll, >wmvcore.dll,drmclien.dll,npwmsdrm.dll,WMASF.dll, drmstor.dll,msaud32.acm, >sl_anet.acm,wmidx.ocx) > * Run: No, crashes. (sysparams.c:1646 - user.dll.so) Err... this is the same crash as with... > 26. CD Mate - This is a powerful CD backup utility. > > VERSION 2.2.8.1. > * Install: Yes. (License and more info is not visible - riched32) (Dlls > installed none) > * Run: No, crashes. (sysparams.c:1646 - user.dll.so) (the audioplayer > included with the program works) ...this one ? > 29. Putty - This simple Telnet application could hang with the big boys. > > VERSION 0.52. > * Install: No needed install. > * Run: No. (it doesn't show the right part of the window, regression) Very strange. PuTTY used to work. And please don't name it "Telnet application". Telnet is a small part of it that should be neglected as much as possible. But AFAIR I recently had problems getting it to run, too. Andreas Mohr
Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
On Sat, Nov 02, 2002 at 10:36:21AM +, Matthew Bloch wrote: > So with the ICOM_MSVTABLE_COMPAT flag set I get the "off-by-two" calling error > from within Winelib when it's trying to invoke a COM function. When it's not > set I get the same bug occurring in my program when it tries to do the same. > > I'll keep investigating but I'd be amazed if I was the only person who's tried > to build a DirectDraw application against Winelib-- surely someone else must > have solved this problem before? Or do most Wine users only use Wine for > loading PE executables? I'd say that *BY FAR* most people use Wine to run programs. What would you use Winelib for anyway ? IMHO it has somewhat limited use, given that you don't really gain a lot from "porting" programs via Winelib (neither performance, nor code size, nor ...). (maybe I'm mistaken here, but currently I don't know of some significant gains) The only advantage I can think of would be the use of Unix code, but then you could achieve the very same thing by writing the Unix equivalent DLL of a Windows DLL (e.g.: hardware access or so) and using the Unix specific DLL version instead on Wine.
Re: Wine FAQ - call for a volunteer
On Fri, Nov 01, 2002 at 04:44:53PM -0500, Dimitrie O. Paun wrote: > On November 1, 2002 04:36 pm, Andreas Mohr wrote: > > My (hidden) point was that the FOM is two *SEPARATE* units, > > the FAQ and everything else. > > (as always, nobody seems to grasp this) > > Good point, but you see, I wasn't grasping it :) But that's a > problem in itself, there's some confusion there, no? Err, yes. > P.S. Guess we can consider the FAQ issue closed, right? Yep, the FAQ stuff should be moved back to a static page. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Wine FAQ - call for a volunteer
On Fri, Nov 01, 2002 at 04:29:20PM -0500, Dimitrie O. Paun wrote: > On November 1, 2002 04:02 pm, Andreas Mohr wrote: > > I agree that using a static web page for the FAQ part instead could > > probably be better - but for the troubleshooting content ?? > > The troubleshooting content is meant to be a step-by-step problem solver > > area (and it is, to some extent). Now tell me how you'd implement the > > same thing easily with an ordinary web page, without losing flexibility > > for very quick changes/reordering ?? > > Well, for one thing, this should not be in the FAQ, but a separate > troubleshooting section. Second, I *know* I don't want to see the > FOM as a user. It's just bad. Beyond words! :) I don't understand > why you want this very quick changes/reordering flexibility. It > just seems we're trying to fix the wrong problem. We don't need a > tool to help us add hundred of pages, because nobody will bother > to read them. We need to think how we can present the information > in a few pages. Tops. If not, we are better off spending the time > fixing the problems, rather than documenting workarounds on > hundreds of pages. The largest part of the FOM *is* the troubleshooting section. The FAQ is only a small part of the FOM that has been added later for maintenance convenience of the FAQ. Good luck implementing it in a different way. I'm outta that one for now, especially given that spending my time on non-Wine things currently probably is a wise thing to do. About the hundreds of pages: What's so problematic with navigating a directory structure that gets more and more specific about your problem until you (hopefully) hit the specific answer to your question ? That'd all get lost with your suggested change. Sometimes I've got the impression that I'm partly fighting the "KISS dumb-it-down-until-there-is-plain-nothing-left-to-annoy-the-helpless-user- with-its-bewildering-size-and-information-overload syndrome". -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Wine FAQ - call for a volunteer
On Fri, Nov 01, 2002 at 04:21:54PM -0500, Dimitrie O. Paun wrote: > On November 1, 2002 04:02 pm, Andreas Mohr wrote: > > Excuse me, what is sooo terrible about the FOM ??? > > Having to maintain hundreds of different web pages by hand > > (in order to gain the required interdependencies for some complicated > > issues) is a *lot* more difficult than simply adding/removing/reordering > > FOM content as you see fit. > > But this is not the point. I was pretty clear on my problem with the > FAQ-O-Matic: the interface is s bad, I wonder if anyone bothers > reading the content! I was also clear on the solution, too. That is, > I suggested something on lines of this FAQ: > http://www.dvddemystified.com/dvdfaq.html > While this is a *HUGE* FAQ, it's all in *one* page. This is important, > as people don't have to click like crazy around to read it. The > formatting is simple, distinctive, and easy on the eyes. It's easy > to navigate (you can just click on the question), or read (just scroll > down the page). It's simply a pleasant experience. And this is not my point either... My (hidden) point was that the FOM is two *SEPARATE* units, the FAQ and everything else. (as always, nobody seems to grasp this) > Now, from a maintenance point of view: we don't need "hundreds of > different web pages". The problem with the DVD FAQ is that it is We definitely do. Not for the FAQ, but for everything else. IMHO. > way too big. I suggested only for the format. Ours should not have > more than 50 questions. If it does, something is wrong. Very wrong: > -- important issues get lost in the torrent of information > -- few people will bother reading it > -- we actually *scare* people away > -- it's a maintenance nightmare! > > My do we need some special tool to maintain one page of FAQs? Like I said, not necessarily. I originally chose to also migrate the FAQ content to the FOM, since adding/modifying was a lot faster that way. Turned out that adding the FAQs probably wasn't a winner... (mainly to the "not one page" syndrome, which should be the case for the FAQ) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Wine FAQ - call for a volunteer
On Fri, Nov 01, 2002 at 03:06:55PM -0500, Dimitrie O. Paun wrote: > On November 1, 2002 08:15 am, Jeremy White wrote: > > My vision for the FAQ is a hand edited main > > FAQ with the current FAQ-o-matic being > > pushed to a secondary role. > > Please get rid of the FAQ-O-matic. The interface > is atrocious. A hand written one would do just > fine, is not like we add 100 questions per day! > (And if we do, something's wrong, who's gonna read them?) Excuse me, what is sooo terrible about the FOM ??? Having to maintain hundreds of different web pages by hand (in order to gain the required interdependencies for some complicated issues) is a *lot* more difficult than simply adding/removing/reordering FOM content as you see fit. I agree that using a static web page for the FAQ part instead could probably be better - but for the troubleshooting content ?? The troubleshooting content is meant to be a step-by-step problem solver area (and it is, to some extent). Now tell me how you'd implement the same thing easily with an ordinary web page, without losing flexibility for very quick changes/reordering ?? *I* am the one maintaining the FOM (well, currently on the paper at least :-\) and thus *I* reserve the right to have some extra say on how that docu part should be done. To me it sounds a bit like people turn a glaring maintenance problem (I currently don't have a lot of time to give it the necessary attention it requires due to people adding tons of stuff, and there're not too many people to still properly handle this) into a general, greatly simplifying "we need something entirely different, this sucks" kinda thing. IMHO the REAL problem here is that the content is sort of outdated and unmaintained since I currently don't have a whole lot of time to spend in the IRC channel in order to catch up current Wine issues of people, and of course due to other obvious reasons. ...unless you can convince me that the FOM *indeed* is the wrong approach and you name me a valid replacement that handles the step-by-step problem solving approach at least as well as the FOM (or you name me an entirely different approach that is *superiour*). Turning the FOM read-only might also be a "solution" to the maintenance issue... I'm starting to be fed up about the fact that people keep complaining about things, without *really* suggesting superiour alternatives and *really* making sure this gets fixed if it's not good enough.
Re: So lets say we do it
On Thu, Oct 31, 2002 at 11:18:56PM -0800, Francois Gouget wrote: > On Thu, 31 Oct 2002, Dimitrie O. Paun wrote: > > BTW, how can I contribute to the WineHQ CVS? Can I get access to it? > > See http://www.winehq.com/development/ > > Check out Winehq_com. > > Actually you can also get the same info there: > http://www.winehq.com/download/ > > Argh! Duplication, bad, bad, bad (597). IMHO, the CVS docu should *all* be moved into Wine Users Guide (basic CVS download only ! with pointer to Devel Guide) and Wine Developers Guide (generating patches, applying diffs, ...), and then have only *links* on WineHQ point to the static links in the HTML versions of these documents. I've been planning to do this for quite a while, but, ya know, time and stuff... ;-) There wasn't much to be said about Winehq_com here, but I just wanted to point out that CVS docu in general is very suboptimal. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: So lets say we do it
On Thu, Oct 31, 2002 at 04:05:21PM -0600, Jeremy Newman wrote: > On Thu, 2002-10-31 at 15:30, Dimitrie O. Paun wrote: > > Agreed. I say, let's get some of the content in shape, and worry about > > the form a wee bit later. BTW, any web-design guys around, that may > > want to take on this task? > > Oh pick ME ME ME! :-) > > Wait a minute, I'm already in charge of that. Must have been slacking > off again. > > Here's my idea. On the front page, add a new box above the WNN box, > below the Latest Wine release box. This box would be a random screenshot > pulled from the AppDB, (or a predefined list of available screenshots). > I can whip up a new page/section/what have you called "Screenshots". > This requires a new button for the front page. It should be linked to on > the About page, and the screenshots page links back to the About page. A > little cross referencing if you will. > > Does this work for anyone. I can probably do this during the weekend in > my "off" hours. Two words: Earth-shattering idea ! :-) (oh wait, there's just been an earthquake in Italy :-\) That's a very good proposal. I guess all that's left for us to do is to make sure About looks terrib^H^Hific :) -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview
Re: So lets say we do it
On Thu, Oct 31, 2002 at 04:16:45PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 03:58 pm, Andreas Mohr wrote: > > BTW, I just updated the Contribute page quite a lot. > > Very cool. You see, there's a lot of good stuff on the site, > but it's kinda hidden. We need to bring some of it > (like screenshots, FAQ, contributing) more to the front, > so people stumble upon it, rather then search for it. > > But I should stop talking, and doing more work. :) See ? Maybe my medicine finally starts to take effect :) I wouldn't be 100% against placing a Screenshot link on the main page - it's a mere 99% only. But with the current menu infrastructure, I'm about 150% against it. If we added a separate Screenshots menu item (which, by the way, I don't think is needed, since we do have that nice About page), then the whole page would grow overly long. So either adapt the main page menu items' size as a whole, or shut up and properly adapt About instead ;) That's my opinion on it at least.
Re: So lets say we do it
On Thu, Oct 31, 2002 at 03:20:34PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 03:11 pm, Andreas Mohr wrote: > > Why, the current rate is avalanche-like ;) > > > > I'm growing ever more astonished about the increase in wine-patches per > > day... > > Same here. It's quite amazing! But can we sustain the rate for a year? I might be willing to bet that it might actually increase even more, now that more and more companies go The Linux Way... > > But of course you're sorta right, we're still quite far off the mark. > > Yes, but it's been my experience that there's nothing like a good, > focused TODO list to get people working on what's needed. And this > is were I'm aiming with these emails... Very true. We should make sure that the Contribute page links more or less directly to one page listing the requirements for a specific version (that'd be the Bugzilla 0.9 and 1.0 pages, I guess). But AFAIK the Contribute page already does this. BTW, I just updated the Contribute page quite a lot. -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."
Re: So lets say we do it
On Thu, Oct 31, 2002 at 03:17:26PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 03:09 pm, Andreas Mohr wrote: > > Well, that maintenance would e.g. include the localization work I > > suggested, having a *separate* CVS containing all localized Wine Guides, > > and having automatically updated docu maintenance web pages > > for every language involved. > > But this is probably a bit too much. I mean, yeah, would be great to > have the guides localized, and what not, but that's a _lot_ of work, > and we don't seem to be able to maintain the English ones, let alone > other languages. Localizing the guides right now would just compound > the problem by just ending up with more unmaintained documentation. And here AGAIN I have to disagree with you :) Given a *correct* and *working* framework, the docu simply would not be rendered unmaintained. Every change in the English docu would keep sitting (or rotting) on the various foreign language translation pages until this change has been applied to the respective language and the item has been closed. (OK, if you're overly pessimistic, then you'll probably tell me now that nobody will ever work on updating foreign languages, despite of such a marvellous infrastructure) > What would be more productive, at this point, is a clear, and focused > TODO list for the current documentation, broken down into two sections: > 1. What is out of date (and needs fixing) > 2. What is missing (and needs writing) > Now, you being the guy that know the docs best, ..., eh, ..., maybe > you can help create such a list ;) Once it's done, maybe people will > start picking an item at a time, etc. What do ya say? Hmm, WAIT... didn't I say somewhere that I wouldn't work on docu any more ? I guess I didn't :) I could do that, but don't count on it, since my time is limited. (heck, I can't even keep up with the Wine mails that keep flooding my inbox !) (not to mention that it's me today who's to blame quite a lot for this mail situation today :) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: So lets say we do it
On Thu, Oct 31, 2002 at 02:58:12PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 02:44 pm, Andreas Mohr wrote: > > For christ's sake, IF YOU CAN'T STAND THE DOCU, THEN *IMPROVE IT*. > > Well, that's a good point. And I did a bit, but not nearly as much > as you. > > > I did. (past tense) > > But maybe then it seems like I didn't... > > Hey, I've never complained about the work you did on the docs! Not directly, yes. > All I am saying is that the docs are, in part, out of date, > and I'm not pointing a finger at you, as it isn't your responsibility > to keep them up-to-date. *I* didn't keep the ones I wrote up-to-date, > so I don't dare point my finger at anyone :) Heh. > The docs are huge, and requite work, which should be tackled by > more than one person. No matter how much you work on them, if > you are alone, you'll always be behind. So don't take my comments > as an attack against you, the one actually working on the docs; > quite the opposite, it's a comment to the community for not helping > on the said maintenance. Well, that maintenance would e.g. include the localization work I suggested, having a *separate* CVS containing all localized Wine Guides, and having automatically updated docu maintenance web pages for every language involved. So far there still is nobody who has stepped up to the plate of implementing such a database-driven web page framework... (I could complain here again, but this time I better won't :) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: So lets say we do it
On Thu, Oct 31, 2002 at 07:08:07PM +0100, Marcus Meissner wrote: > On Thu, Oct 31, 2002 at 08:24:28AM -0800, Alexandre Julliard wrote: > > So no, I'm not going to make a general public release just yet... > > Not yet too late for another 'Halloween' release though ;) Yep... ...next year ! ;)
Re: So lets say we do it
On Thu, Oct 31, 2002 at 03:07:15PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 03:00 pm, Andreas Mohr wrote: > > > Not yet too late for another 'Halloween' release though ;) > > > > Yep... > > > > ...next year ! ;) > > I don't want to jinx it, but at the rate we're going, we'd be > lucky to do a 1.0 'Halloween' release next year :/ Why, the current rate is avalanche-like ;) I'm growing ever more astonished about the increase in wine-patches per day... But of course you're sorta right, we're still quite far off the mark.
Re: So lets say we do it
On Thu, Oct 31, 2002 at 01:19:33PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 11:24 am, Alexandre Julliard wrote: > > You forgot a few things here: > > Yes, and no: it was getting late, hand was all funny, > email was getting too long... :) > > > First it doesn't even start because they don't have a config file. OK, > > Hear, hear! BTW, we should move configuration out of documentation/samples Hmm, why ? Where should it be then ? Having sample config in such a directory has a pretty long tradition. One thing that comes to my mind here is Debian. > > Then they finally manage to run the installer but it > > puts stuff in RunOnce that never gets run so the app doesn't work. > > See, I wasn't even aware of that! Hmm, my problem :-\ > > Then they finally make the app run but can't print anything. And > > True. I second that (at least sometimes). > > when they ask for help they get told to fight the FAQ-O-Matic crap to > > maybe finally find an answer telling them they are an idiot. > > That FAQ-O-Matic should just be 'rm -rf'. It's crap. We either have > a carefully hand-written FAQ, or nothing at all. Gee, thanks ! You know how many man-weeks (err, months ?) I've been putting into it, right ? I guess I hereby declare that I'll stop ALL documentation work. Obviously it's not too appreciated, given the constant and very annoying whining. Not to mention that I've been constantly working "behind the fact". For christ's sake, IF YOU CAN'T STAND THE DOCU, THEN *IMPROVE IT*. I did. (past tense) But maybe then it seems like I didn't... Boy, that'll give me quite some free time for RL work... -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: So lets say we do it
On Thu, Oct 31, 2002 at 02:11:31AM -0500, Dimitrie O. Paun wrote: > That is, > > Lets assume for the sake of argument that Alexandre likes my > 0.8 idea so much, that he releases Wine 0.8 with much fanfare > next Monday (so we have a good audience), and the news reaches > Slashdot where a message with a link to http://www.winehq.org > is posted, in good CmdrTaco fashion... > > And so, let's see what's going to happen: > > 1. 90% of /.ers will click on the link, and WineHQ gets Slashdotted! :) > > 2. People will look for the typical left-side menu: > Home > About > Status > Development > Download > Screenshots > > *BZZT* We don't have any. 5% will drop off here. Sorry to say that, but in this mail, *you* were talking *some* crap IMHO ;-) We *do* have screenshots. The About page has some pretty nice screenshot. OK, it's a minimalist approach, granted, but it does show IE etc. If you want more screenshots, then you just need to go to the AppDB. (although we don't mention it yet, so I'll add a subtitle "for more screenshots, see AppDB" to the screenshot now) > 3. Then they'll visually search for the word "Screenshot" > > *BZZT* We don't have any on front page. 30% will drop off. > *I* drop off here when I visit other projects, for crying out loud! The "About Wine" item *definitely* tells *everyone* that a screenshot should be found within the "About Wine" section... If we honoured every stupid link request, then the main page would look like some huge pile of... err... crap. We've been asked directly or indirectly countless times to include certain things on the main page (and we often thought "hmm, this needs quite a bit of attention, so: put it on the main page ??"). But including everything would be a HUGE mistake. Instead WineHQ needs a *clean* and obvious organisation (some improvements might well be possible here, I guess). And the idea of finding screenshot(s) on "About Wine" is definitely as good as it can ever get. > So let's assume that by a miracle they'll discover the screenshots: > do they make them drool? No, we loose another 15%. Hmm, k, it could be a bit more spectacular, correct. > Damn, that's tough! Let's see what happens to the rest: > > 4. Let's download, and try it out > > Do we have officially sanctioned binaries (at the very least > .rpms for RH, and .deb for Debian)? No. *BZZT* We loose another 30%. > Again, *I* don't care about stuff that doesn't come as a binary > .rpm for my RH system. I used to, not anymore. Well... obviously we don't have enough people who are willing to enforce a properly maintained package for various architectures. Instead we've got some chaotic heap of wildly differing packages. One could argue that this situation helps CodeWeavers' bottom line, though ;-) > Fine, some will install what they download. What next? Hm, this > Wine thing just sits there, it's not that simple. We need to > read some docs. Back to the site. > > 5. Look at the docs > > Oh, we have some. We hate to read docs, but Wine is cool, so we > swallow the pill. Only to find out it's out of date!!! What a > piece of #@$%! *I* am definitely not the one to blame here :) (BTW, you got a point here) > *BZZT* Another 10% drop off. > > Thats 90% drop-off before they really tried it out! The rest 10%, > go on. So, what do we do with it? > > 6. Look for a list of Win-apps that we can run > > Is there something on the site? No. Blah, too much hassel... > > *BZZT* Another 5% go. Hmm, I guess it all boils down to having the About page get redesigned a bit. We should definitely include a prominent link to the AppDB, and maybe also a separate page with kickass knock-down screenshots... Does anyone want to give us some ideas about how the page should be redesigned ? > (Don't even mention app-db, it's *way* too complicated!) Huh ?? I really can't follow you on that one... (ok, it's not a dumbed-down page listing some screenshots and nothing else apart from that, but it was never meant to be made for dummies) Which all boils down to the essential question: which amount of morons does our project need/want ? :-) > So the 5% left, install wine, install a Win-app, and play around. > Great, it works! They start learning the utilities, etc., but > those are in flux, and we change them, and they get PO-ed. Another > percent, or two leave the fold... OK, those ~ 90% might be somewhat drastic (after all if you really *need* to run Windoze apps, you'll be willing to go through quite some hassle), but it might be rather high indeed. May I suggest that you'd probably have fixed about 50% of these issues if you hadn't done this ranting about it, but instead used that time to fix them ? ;-)) Take it easy, Andreas
Re: Versions & mass-appeal
On Wed, Oct 30, 2002 at 10:00:08AM -0400, Dimitrie O. Paun wrote: > On October 30, 2002 08:56 am, Andreas Mohr wrote: > > Thus you could encounter an app which manages to trash your whole > > filesystem ANY DAY; this app simply needs to use a very rarely used > > function that we barely implemented... BOOM. > > Andy, this is just crap, and it's the type of crap that we should > not perpetuate. There are tons of reasons why this _never_ happens, > and you know them. So let's not propagate this type of misinformation > that we have already too much out there, and which hurts us undoubtedly. "Never" ? Never is never a perfectly fitting word... I for one *have* heard in some admittedly rather *rare* cases of data corruption due to Wine (something like deleting the parent directory instead of the program directory due to skipping one level in directory hierarchy in some function due to a problem). -- oops, whole Wine drive content gone (in a worst-case scenario). (also, there's that well-known Explorer renaming issue, which is *not* a Wine problem but happens on Wine due to braindead Microsoft programming) Crap is also a rather bold word (which admittedly I also use quite often - shame on me :). I'd say almost all of my text was based on facts that may happen sometimes, thus it could hardly be called crap. I don't want to spread the perception that Wine is unsafe - in by far almost all cases it's definitely not. But people should keep in mind that for every new program that they install, there might still be a bug lurking in some rarely used function that this program uses, which could in some cases cause some... err... problems with data. But most well-known programs have been tested quite a lot already, so the chance something like that happens with a well-known program is pretty slim to none, of course. And given that even W2K or XP have strange filesystem problems when used with an excessive amount of files sometimes, this leads me to believe that Wine isn't that bad after all... After all: Software == Heap o' Bugs :) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Versions & mass-appeal
On Wed, Oct 30, 2002 at 12:21:51PM +0200, Shachar Shemesh wrote: > > > Ender wrote: > > >- Getting the right set of dlloverrides and registry entries correct > >for a large portion of software is irritating. Most of this comes down to > >the lack of WINE being able to dynamically run RunOnce and wininit.ini > >entries. Doing this manually is far beyond your average user who just > >wants to install a reasonably complex program. Something like Crossover's > >reboot.so is needed. > > > > > I'm willing to tackle that (the BiDi stuff is only slowly going, and > there may be some unexpected development coming that is outside my > hands, so I have SOME free resources available). > > Where do I get reboot.so to have a look? Either that, or can someone > answer a few questions regarding it? I've been having a finished implementation of wineboot in my tree for ages. I guess it's about time to get it submitted... > - When are the boot time activities taking place? On wine start? On > wineserver start? Good question. I guess we once agreed on it being done on winelauncher script startup. (or alternatively really on user desktop login, but I'm not sure whether this is what we want) winelauncher should probably check whether any of the places that register reboot activities need processing, and if this is the case, then first finish a wineboot process, *then* start regular wine apps. All this would have to be resistant against race conditions, of course :-\ > - When are login time activities taking place? > - How should a reboot request be treated? Should it be an indication > that all these operations should start now, and let other wine programs > carry on as usual? IMO we need to make sure we only do this when no other wine process is running. Optionally there could be some way to tell Wine to do it immediately, even during a session, though. Sounds like nobody ever watched the wineconf2002 streams, since nobody ever knows about wineboot... -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: Versions & mass-appeal
On Wed, Oct 30, 2002 at 07:08:08AM -0600, Rick Romero wrote: > I would love to convert my desktops to Linux + Wine, but one 'little' > thing keeps nagging at me (even if my apps did work perfectly). I > haven't seen it uttered in a while, but the phrase, "Wine is ALPHA > software" sticks in my head. > > People know what beta software is, and when someone see's "Alpha", > they're not even going to attempt do debug it. Alpha (at least to me) > conjures up such a raw state of affairs, that whatever problem is > occurring, is happening because "Alpha" is seen as horribly broken. > > I realize this isn't the case. I'm also sure that a lot of people DON'T > realize that. I think CodeWeavers has greatly helped Wine's image by > giving it a version number. Well, but I'd still insist that Wine IS Alpha software. After all we've got about 15000 Windows functions, and of course we only implement about 4000 to 5000, and of those that we do support, a ridiculously small number is entirely bug-free. Thus you could encounter an app which manages to trash your whole filesystem ANY DAY; this app simply needs to use a very rarely used function that we barely implemented... BOOM. That this doesn't happen every day can be attributed... well... to the fact that Wine maybe is not entirely Alpha any more, but by no means does that mean it's Beta or even almost finished. Wine is *not* a standard boring John Doe program, it's got a massively more difficult way to reach final stability. With an ordinary program, every little sub-version can easily be implemented to reach utter stability within its sometimes totally negligible goals. Not to mention that with a standard program, *you* define (and *know* !) what this program is supposed to do and how, whereas with Wine... you know the story ;-)
Re: winapi update
On Wed, Oct 30, 2002 at 11:25:50AM +0800, Dmitry Timoshkov wrote:
> "Patrik Stridvall" <[EMAIL PROTECTED]> wrote:
>
> > > On October 29, 2002 11:27 am, Patrik Stridvall wrote:
> > > > Anyway, I can't inline my patches the because Microsoft
> > > Outlook wraps
> > > > the lines and I sure a lot of other people that use attachments have
> > > > similar problems.
> > >
> > > And can't be turned off?!? Hmmm, anyway, just attach them as
> > > text/plain.
> >
> > I have no idea how or if it is possible to do either.
>
> This is a part of my mail sent to Guy in order to help him to send patches
> using Outlook Express. I hope that it will be helpful for Outlook users too.
>
>
>
> Since I was using OE to send patches, I have found a way to send diffs as
> attachments and without \n vs. \r\n problem.
>
> You need following two things to make it work.
>
> 1. Make sure that .diff files have \r\n line ends, because if OE detects
> that there is no \r\n line endings it switches to quoted-printable format
> attachments.
>
> 2. Using regedit add key "Content Type" with value "text/plain" to the
> .diff extension under HKEY_CLASSES_ROOT (same as for .txt extension). This
> tells OE to use Content-Type: text/plain instead of application/octet-stream.
Ah the joys of forcing even utterly BROKEN programs like Outlock into
half-compliance with today's reasonable standards that are being obeyed
by everyone else but Microsoft ("EEBM")...
I guess we might want to put a linked page right next to the wine-patches
mailing list stuff about certain helpful settings for some email programs
(if they deserve to be called like that)...
Re: Segmentation Fault: A possibility???
On Tue, Oct 29, 2002 at 04:56:24PM -0500, [EMAIL PROTECTED] wrote: > Andreas Mohr writes: > > >Huh ? You don't want to tell us that you've got a dualboot Windows/Linux > >and you're the internet server - via Windows ??? > > No - linux is the internet gatrway - But if I try to log out of it then > linux will freeze due to wine - so I can't just logout and login. Huh ?? What the h*ll ??? You might really want to investigate this in case this persists after upgrading both the kernel and Wine. This isn't an SB16 card by chance, or is it ? > >A very fitting (originally German) statement about this would be: > >Oh, you use a Windows internet gateway to let some Linux PC get access to > >the > >internet ? > > Actually I use a linux internet gateway to allow some windows pc with > access to the internet Ah, ok. Sorry for the embarrassment :-) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: Bug #321: dlls/msvct/vf[w]printf functions (Patch 2)
On Tue, Oct 29, 2002 at 07:36:06PM -, Jaco Greeff wrote: > On 29 Oct 2002 10:53:32 -0800, Alexandre Julliard <[EMAIL PROTECTED]> wrote : > > Still, this only works for vfprintf, vfwprintf > > has to output in Unicode so you cannot convert to ASCII or use the > > system printf for that. It would probably be easier to grab a printf > > implementation from somewhere and convert it to Unicode. > > Can I swear on this mailing list? Please, I need to. And one would think > I've never used the vfwprintf function before the way I'm making all these > wrong assumptions. Damnit, I know the Win32 API. *sigh* Luckily my wife got > most of the frustrations at my stupidity... [insert some rant about certain highly non-rewarding functions here...] Still, you're doing some pretty essential work, so let me just say thanks for your (annoying ?) work ! -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
[OT] Announcing Aztech AZF3328/PCI168 sound driver
Hi all, the reason I've been rather quiet on the wine-patches side is that I've been busy writing an ALSA driver for the entirely UNDOCUMENTED and UNSUPPORTED PCI soundcard Aztech PCI168. This has been consuming vast amounts of weeks (all in all I'd say in compressed form 4 weeks of 2 hours per evening). This driver (azt3328.c) is more or less working now (some minor quirks remain) and has just been committed to ALSA CVS today. I don't expect anyone here to have access to such a card, but if you have, then you might want to give it a whirl ;-) Greetings, Andi
Re: Segmentation Fault: A possibility???
On Mon, Oct 28, 2002 at 09:50:35PM +1100, Kye Lewis wrote: > Hi, > > Sorry for posting all of this to the wine-devel group continuously, but I may > have found the problem (or I may not have) but either way I need some help. > > I have run wine --debugmsg +relay acrord32.exe and read the resulting file. > The last thing that comes up is: wineoss.drv > > I had a quick look through the specific function's code > > (The actual log entry is: > > Call wineoss.drv.DriverProc(,403e2858,0001,,) > ret=40c9d2b5 > > ) > > Recently in the KDE Control Panel's Sound options, I ticked the 'Use Full > Duplex' option - and ever since that it hasn't worked. > > Could this have been the reason? > > I can't look and see if it was now, i'll have to restart linux, and right now > i'm the internet server on the network - so no restarts for me :( Huh ? You don't want to tell us that you've got a dualboot Windows/Linux and you're the internet server - via Windows ??? A very fitting (originally German) statement about this would be: Oh, you use a Windows internet gateway to let some Linux PC get access to the internet ? - so I gather you also use nails to drive hammers into the wall ? BTW: sounds like fullduplex change may have been the reason, yes. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: search for Slava Monich
On Sun, Oct 27, 2002 at 03:21:31PM -0500, Doug Brown wrote: > Hello > I used to work with Slava Monich in the period 1992-1997 thereabouts. > I am interested to find him now. > I found his name on some Wine web pages from Google search > on his name and after not finding anything furthermore specific > I ask you for help. > > If you have any latest and greatest contact information for > this gentleman, please let me know. > > I tried him at [EMAIL PROTECTED] but got denied. Nothing easier than doing: andi@note:/usr/local/src/wine$ grep -i monich ChangeLog |sort|uniq * windows/dialog.c: Slava Monich <[EMAIL PROTECTED]> * windows/dialog.c: Slava Monich <[EMAIL PROTECTED]> * windows/syscolor.c: Slava Monich <[EMAIL PROTECTED]> * windows/win.c: Slava Monich <[EMAIL PROTECTED]> * windows/winpos.c: Slava Monich <[EMAIL PROTECTED]> Slava Monich <[EMAIL PROTECTED]> Slava Monich <[EMAIL PROTECTED]> Contributions from 06/1999 to 07/2000. -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview
Re: Listview Z8
On Sun, Oct 27, 2002 at 07:14:41PM +0200, Shachar Shemesh wrote: > I can offer you the Hebrew alphabet. Except "à" (Aleph), which was used > to indicate the various infiinity levels, there are 21 brand new, never > before used, ready for your viewing pleasure letters (the number grows > to 26+aleph=27 if you want to count the different forms a letter may > take, depending on it's place in the word). > > "àáâãäåæçèéëìîðñòôö÷øùú". Very useful `-) What a weak and useless suggestion, this will run out of characters in no time at all ;-) Better use Chinese characters ! And if even those run out, then use Complex Chinese instead of Simplified Chinese ;-)) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: Wine securityflaw: Protect against root
On Sun, Oct 27, 2002 at 07:51:01AM -0600, David D. Hagood wrote: > I would ALSO suggest that wine check the execute bit on the application > being run - the recent incident with Klez running under Wine would not > have happened (I think) if wine would not run that which is not marked > with the -X bit (unless, again, a command line parameter is supplied, > and a warning dialog is confirmed). Broken idea. This would stop any and all installers, as they first extract a compressed archive and then invoke *further* install helper programs. Windows is not Unix, period. That's why mapping to the X bit really doesn't make sense IMHO. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: How can an app detect it's running under WINE?
On Fri, Oct 25, 2002 at 10:30:15AM +0200, Alberto Massari wrote: > Hi Andreas, > > At 03.12 25/10/2002 -0500, you wrote: > >Message: 13 > >Date: Fri, 25 Oct 2002 10:10:32 +0200 > >From: Andreas Mohr <[EMAIL PROTECTED]> > >To: Alberto Massari <[EMAIL PROTECTED]> > >Cc: [EMAIL PROTECTED] > >Subject: Re: How can an app detect it's running under WINE? > >Reply-To: [EMAIL PROTECTED] > > > >On Fri, Oct 25, 2002 at 09:25:23AM +0200, Alberto Massari wrote: > >> Hi everybody, > >> I am working on making our software (Stylus Studio, > >> http://www.stylusstudio.com) run under WINE, if this is feasible. To > >> achieve this, I have already implemented a bunch of APIs (the application > >> is built against the UNICODE version of the Win32 APIs) and fixed some > >bugs > >> I hit (I already mailed the first patch to [EMAIL PROTECTED]). > >> > >> However, I would feel better if I could detect I am running under WINE > >and > >> gracefully disable some functionalities that are not yet fully supported; > >> is there any way to achieve this? Is there a WIN32 API (like, say, > >> GetVersionEx) that can return a string like "Windows 2000 (WINE)" or is > >> WINE trying to be as stealth as possible? > >http://www.winehq.org/FAQ/ would have been answering this in countless > >cases already. > > I'm sorry I asked this here, but the only help I got from the FAQ was: > > -- > Q: How can I detect Wine? > A: You really shouldn't want to do this. If there's a quirk in Wine you > need to work around, it's *much* better to fix it in Wine (after all you're > a developer, so you should be able to gather enough help and knowledge to > fix it for real). > If you think you really want to know how to detect it anyway (maybe in > order to just have a cool "running on Wine" status text or so), then please > mail me. > (address-suppressed) > -- > > So I though I could ask it here Argh ! That "(address-suppressed)" wasn't meant to be like that from the beginning... :-( Originally that part showed my email address. Thanks for notifying me about this issue ! So yes, your posting is pretty much very justified after all. Like someone else said (IIRC), you could check for the existence of the Wine configuration registry key branch. That'd be a 150% reliable method of detecting Wine presence. But again, trying to fix issues would be preferrable. (unless there are just too many problems to be fixed) Andreas Mohr
Re: Whats done? not?
On Fri, Oct 25, 2002 at 06:20:56AM +, Christensen Tom wrote: > > > Obviously wine is still being actively developed, > and I know its not close to "done" however, I want to get involved, I know > C/C++ and have a pretty good grasp of windows apis, I'm just wondering is > there a place (kinda like in the Mono project they have a tree laid out > with all of the classes/functions that are in the .NET runtime, and they > have them marked done, being worked on, not started...) So I'm wondering > if wine has anything similar? or should i just pick a function, and see if > its done already by searching through the source? At any rate, wine should > have a nice concise place to look and see if wine has certain functions > implimented.. The About page links to http://www.winehq.org/about/index.php?status (note: I realized the Devel page doesn't have a link, so I just added one, too) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: How can an app detect it's running under WINE?
On Fri, Oct 25, 2002 at 09:25:23AM +0200, Alberto Massari wrote: > Hi everybody, > I am working on making our software (Stylus Studio, > http://www.stylusstudio.com) run under WINE, if this is feasible. To > achieve this, I have already implemented a bunch of APIs (the application > is built against the UNICODE version of the Win32 APIs) and fixed some bugs > I hit (I already mailed the first patch to [EMAIL PROTECTED]). > > However, I would feel better if I could detect I am running under WINE and > gracefully disable some functionalities that are not yet fully supported; > is there any way to achieve this? Is there a WIN32 API (like, say, > GetVersionEx) that can return a string like "Windows 2000 (WINE)" or is > WINE trying to be as stealth as possible? http://www.winehq.org/FAQ/ would have been answering this in countless cases already. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
WM_COPYDATA linear/SEGPTR crash
Hi all, Dr. Hardware crashes like that: Backtrace: 0 0x0297:0x01c0 1 0x00f7:0x 2 WINPROC_CallWndProc16+0x211(proc=0x2970186, hwnd=0xa4, msg=WM_COPYDATA, wParam=0xab, lParam=0x403cbc48) 3 WINPROC_CallProc32WTo16+0x99(, , wParam=0x200ab, ...) 4 CallWindowProcW+0x6f(func=0x4ce0458, hwnd=0x400a4, msg=WM_COPYDATA,wParam=0x200ab, lParam=0x403cbc48) 5 call_window_proc(...) 6 MSG_peek_message+0x409(msg=0x410b2a74, hwnd=0x0, first=0x0, last=0x, flags=1) 7 PeekMessageW+0x7c(msg_out=0x410b2b78, hwnd=0x0, first=0x0, last=0x0) 8 GetMessageW(msg=0x410b2b78, hwnd=0x0, first=0x0, last=0x0) 9 GetMessage32_16(msg16=0x403c9698, hwnd16=0, first=0, last=0, wHaveParamHigh=0) 10 GetMessage16(msg=0x403c9698, hwnd=0, first=0, last=0) 11 __wine_user_exe_CallFrom16_p_word_pwww 0x0297:0x01c0: lesw 0x104a,%bx Wine-dbg>x/2w 0x2af:0x104a 0x02a:0x104a: bc48 403c (sound familiar ?) To me it's obvious what's happening. Now the obvious question is: how to fix this problem ? (i.e.: where is some kind of translation missing ?) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
WANTED (dead or alive): additional AppDB maintainer
Hi all, as I'm currently in my studies duties again and the AppDB submissions are piling up enormously (> 20 new entries in less than two weeks), I'm looking for one or two additional AppDB maintainers to do the Beowulf thingy ;-) (I'm talking about http://appdb.winehq.org, here) The job description can be found at http://www.winehq.org/about/index.php?contrib#active Sadly enough, this description page has been online for several months now, with (almost ?) nobody applying for any jobs listed. Thanks, Andi
Re: Listview U0
On Sat, Oct 19, 2002 at 02:55:44AM -0400, Dimitrie O. Paun wrote: > > ChangeLog > U0: Better report mode. Hmm, I guess you better reach listview completion rather soon, otherwise you'll slowly run out of patch letters... ;-))) In other news: thanks a bunch for this incredible work ! -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: new wine, me whining
On Fri, Oct 18, 2002 at 09:44:17AM +0200, [EMAIL PROTECTED] wrote: > > > 1. when will this be fixed ? > > > fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or > > > DDBLT_ASYNC: can't handle right now. > > > > Did you actually read any DirectX doc before complaining ? These flags are > > completely useless when emulating a blit and have sense only when doing it > > in hardware. > > Ok, i did not and I should have done it before :( > > > > wine: Unhandled exception, starting debugger... > > > > Did you send us a backtrace of the problem ? A trace ? > > here it comes: > =>0 0x402acdc7 (NTDLL.DLL.memcpy+0x27 in libc.so.6) (ebp=406a29e4) > 1 0x40c90844 (DIB_DirectDrawSurface_BltFast+0x51c(iface=0x403c2da8, > dstx=0x28, dsty=0x23, src=0x403c3878, rsrc=0x406a2b8c, trans=0x10) > [dib.c:870] in ddraw.dll.so) (ebp=406a2b34) > 2 0x40c937df (IDirectDrawSurface3Impl_BltFast+0x47(This=0x403c2dac, > x=0x28, y=0x23, pSrcSurf=0x403c387c, prcSrc=0x406a2b8c, dwTrans=0x10) OK, that very much sounds like we've got some graphics geometry wrong and the memcpy() done by DIB_DirectDrawSurface_BltFast() thus catches a wrong number of bytes to copy... Try finding out why that graphics buffer copying uses the wrong size arguments... -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: multithreading winelib app
On Thu, Oct 17, 2002 at 05:29:27PM -0700, Francois Gouget wrote: > On Fri, 18 Oct 2002, Malte Starostik wrote: > > > Hi, > > > > before I make some major mistakes: can a winelib app safely use pthreads and > > run WinAPI functions from multiple threads or will it have to use Windows > > threads? > > Winelib applications cannot use pthreads. They should not even be linked > with the pthread library. The obligatory question: is it in the Winelib Users Guide ? ;-) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Find the main winelib app with GetModuleHandle
On Thu, Oct 17, 2002 at 02:44:09PM -0700, Alexandre Julliard wrote: > Malte Starostik <[EMAIL PROTECTED]> writes: > > > Check if the name passed to GetModuleHandle() is the name > > of the main executable. As those normally don't have an extension > > ".DLL" was appended and the search failed. > > Actually you should give your executable a .exe extension, there are a > number of places where we expect that (the Unix wrapper script doesn't > need an extension of course, but the .so does). Is there *anything* that we can do to automatically print a warning message during some stage ? Would be quite helpful, don't'cha think ? -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: GetCommandLine
On Thu, Oct 17, 2002 at 12:37:31PM -0700, Alexandre Julliard wrote: > Andreas Mohr <[EMAIL PROTECTED]> writes: > > > Not quoting the arguments is a legal way of doing it, but I guess in order > > to be 150% compliant with Windows, we might want to think of a way > > to reintroduce quotes for programs we start. > > (IIRC Alexandre said it's a bit difficult, but should be doable) > > Well, if you want quotes you can add them to the Wine command-line, or > use a wrapper script. Wine itself shouldn't force quotes since > otherwise there is no way to start a program without quotes (and I > most definitely can start a program without quotes under Windows). Hmm, strange, I thought last time we discovered that adding quotes to the argument in the shell would not work for some strange reason (I believe Wine itself got confused about the quotes in the argument). Or maybe this is fixed now ? Anyway... Yep, e.g. simply doing a CreateProcess() would enable you to run a program without quotes. Thus any program which assumes to get launched *with* quotes *only* should be considered broken. What astonishes me a bit is that you tell us that NT 4 doesn't quote shell launching (Win 9x definitely does). Next time someone is bold enough to tell me that UNIX/Linux is "fragmented"... Andi
Re: GetCommandLine
On Thu, Oct 17, 2002 at 02:36:41PM -0400, [EMAIL PROTECTED] wrote: > This patch pretty much fixes it. It still isn't quite right, although > this probably isn't the same problem. In windows, GetCommandLine returns > a string with quotes around it, while in wine, only the sub process command > line has quotes around it (ie, in windows the first window displays > "MainProc.exe", while the second displays "SubProc.exe", while in wine it's > MainProc.exe and "SubProc.exe"). That's because in Windows, Start -> Execute *always* quotes the argument. (dito with Explorer file execution) Needless to say, some programs are having trouble with the Wine way of doing things: not quoting arguments. (they are prepared to cut away quotes and fail horribly if they don't exist) Not quoting the arguments is a legal way of doing it, but I guess in order to be 150% compliant with Windows, we might want to think of a way to reintroduce quotes for programs we start. (IIRC Alexandre said it's a bit difficult, but should be doable) -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview
Re: Problem with X11 driver
On Thu, Oct 17, 2002 at 10:01:33AM +0200, Till Mossakowski wrote: > Hi, > > I have a problem with the X11 driver (it seems), related to bug 1027. > When I run my program (Fitch.exe), wine gets stuck. All threads > do a WaitForMultipleObjects, the main thread a WaitMessage. > And I get an error > > err:ntdll:RtlpWaitForCriticalSection section 0x40af4b04 "x11drv_main.c: >X11DRV_CritSection" wait timed out, retrying (60 > sec) tid=080b8780 > > I read the FAQ about critical section errors, and it helped my to get the > following calling stack: > > KERNEL32.DLL.WaitForMultipleObjectsEx+0x16a > X11DRV.DLL.MsgWaitForMultipleObjectsEx+0xf3 > USER32.DLL.MsgWaitForMultipleObjectsEx+0x14f > USER32.DLL.WaitMessage+0x22 > WINAWT.DLL.PrintEmbeddedFrame+0x7ca > JAVAI.DLL.mmiFrameMethod+0x3625 > JAVAI.DLL.mmiFrameMethod+0xb60 > COMDLG32.DLL.PrintDlgExW+0x2a2dc0 > JPEG.DLL..reloc+0x12e2cb9b > *** Invalid address 0xc308c483 (IBMJITC.DLL..reloc+0x1df5f482) > > (Indeed, Fitch is written in Java - however, unfortunately > it is not possible to run it directly under Linux. > I also tried to get diagnostic messages from the Java runtime systems, > but it seems that all classes are loaded correctly, and then the error occurs.) > > When I set "Synchronous" = "Y" in the x11drv section of config, > everything works, but *very* slowly. Sometimes it takes 15 seconds > until a mouse click leads to the desired action. I also played with > the other x11drv settings in the config file, but without effect. > > The documentation says that one should set "Synchronous" = "Y" > for debugging purposes. But how proceed then? This seems to be the classical deadlock problem. If you add synchronous X11 request processing, then the X11 handling is slower, thus it's not activating a lock when some other thread also (tries to) activate(s) a lock. Could you find out which wine process is stuck exactly where by using the standard gdb attach debugging ? gdb wine attach backtrace (using current CVS, of course...) The WINAWT.DLL.PrintEmbeddedFrame+0x7ca and then the WaitMessage could mean that it's trying to print something and then probably Wine does some WaitMessage and gets stuck as some other thread is already holding the X11 lock and can't proceed for some other reason (since it's trying to enter a different lock already established by our thread ?). Should be rather useful to get this deadlock nailed... Iff WaitMessage() indeed gets called by Wine and not the program itself, then it's either in windows/win.c or controls/menu.c (maybe add some debug traces there to confirm this invocation). Good luck ! ;-)
Re: Australian Tax Program now working, but WINHLP32.EXE fails
On Wed, Oct 16, 2002 at 11:45:51AM +1000, Ben Stanley wrote: > Hi, > > I've been using wine cvs for a while now, and trying to run the > Australian Tax Office's ETax2002 program for preparing tax returns. Up > until yesterday, it would fail with an illegal memory access, but > yesterday it started working! I have not identified which patch fixed > it, but the program uses flat scroll bars and list (tree) views. > > I have now used the program to complete one (non-lodgement) tax return, > and am part way through preparing another. The ETax2002.EXE program > appears to work very well! > > However, I am unable to utilise the on-line help, which is provided in > winhlp format. When I try to run > > wine winhlp32.exe etax2002.hlp > wine "C:\\Windows\\winhlp32.exe" \ > "C:\\Program Files\\etax2002\\etax2002.hlp" > > I get a message dialog saying > Error while reading the help file > `"C:\Program Files\etax2002\etax2002.hlp"' > > The WINE help program then displays an empty window. > > So it looks like more work is needed upon the help file viewer, but I > suppose this is on the todo list anyway. I am able to access the help > using the printed material from the tax office, which is identical to > what is in the help file. Our builtin winhelp implementation is known to be far from perfect, indeed. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: Wine problem
On Tue, Oct 15, 2002 at 01:50:19PM -0300, Leonardo Bocalon wrote: > Ac wine programers !! > I am from a software company and we have a problem, our software communicate with a >keyboard which has a display this software is make using Delphi (by borland) and for >cominicate with the keyboard we use assembler code , wile we run the software in >windows it work perfectly but when we try to use it in Linux using the wine it >dosen´t work (the keyboard display). > > Please a need a sulution for it Please retry with latest Wine CVS if you haven't yet, then add a BugZilla report describing the problem if it still persists. Attach screenshots if useful and maybe already add some log file like: wine --debugmsg +relay,+event,+key,+keyboard MyPrg.exe &>/tmp/winekey.log -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: PATCH: dlls/comctl32/listview.c
On Mon, Oct 14, 2002 at 10:09:12PM +0200, Gerald Pfeifer wrote: > This is not ANSI/ISO C as far as I (and current GCC) know, so I hope > this straightforward fix is fine. > > Gerald > > ChangeLog: > Avoid GCC-specific language extension. > > Index: listview.c > === > RCS file: /home/wine/wine/dlls/comctl32/listview.c,v > retrieving revision 1.224 > diff -u -3 -p -r1.224 listview.c > --- listview.c11 Oct 2002 23:34:32 - 1.224 > +++ listview.c14 Oct 2002 20:04:57 - > @@ -4467,6 +4467,7 @@ static LRESULT LISTVIEW_GetColumnWidth(L > break; > default: > /* we don't have a 'column' in [SMALL]ICON mode */ > + ; Warum nicht einfach ein break; ? Sieht irgendwie "korrekter" aus...
Re: alsa driver configuration
On Mon, Oct 14, 2002 at 01:53:00AM +0200, Sylvain Petreolle wrote: > Set "Drivers=winealsa.drv" at section [WinMM]. > > Documentation is outdated about this. > > Developers : Whats's needeed to edit sgml files ? vim, xemacs ? I never really convert it to something non-simple when writing docu patches. I only try html conversion.
