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: * 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 LC:\\PROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIFIM P32.FLT (last=0) trace:dosfs:DOSFS_FindUnixName /dos,LPROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIF IMP32.FLT trace:dosfs:DOSFS_ToDosFCBFormat (LPROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIFIM P32.FLT, df621770) trace:dosfs:DOSFS_OpenDir /dos ... trace:dosfs:DOSFS_ReadDir Read: long_name: LProgram Files, short_name: (null) trace:dosfs:DOSFS_FindUnixName checking LPROGRA~1LPROG~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
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: LSchlie\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: _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: 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: 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: 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: 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: 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.
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: 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.
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 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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 Wine Users Guide link. 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 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 Wine Users Guide link. 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: 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: 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: 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: 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: faq entry questionWhat is this for?/question answerNothing in particular, it's just cool./answer /entry /faq Ah, that sounds cool indeed !
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: 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 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: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: 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: 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 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 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 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 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 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 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 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: 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: 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 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: 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
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: 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. QUOTE 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)...
[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: 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: 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: 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: 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
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 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
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-dbgx/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
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
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: 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: 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: 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: 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 pid 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: 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: 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: 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: Using a DLL from a linux shared lib
On Thu, Oct 10, 2002 at 08:57:19AM -0300, Descalzi Carlos wrote: Hi. I'm trying to use a DLL from a linux shared lib and i'm having the next error in the initialization: err:heap:HEAP_GetPtr Invalid heap ! err:heap:HEAP_GetPtr Invalid heap ! Please read the Winelib Users Guide on how to properly use a complete Wine infrastructure with that. Simply linking in the Winelib file to your program to access that DLL is NOT an option. (unless you did initialize it properly and the error is actually being caused by some other problem) Hmm, do we have that in the FAQ yet ? -- 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: Registry problem
On Wed, Oct 09, 2002 at 12:00:02AM -0500, Ender wrote: I'm getting the same crash with Word 2000, when I pull down the 'View' menu: 08075528:Call ntdll.NtQueryValueKey(0188,40114358,0002,40691bec,0100,40691be0) ret=406c8355 trace:reg:NtQueryValueKey (0x188,LWaveMapper,2,0x40691bec,256) wine client error:8075528: sendmsg: Bad file descriptor I'd just like to add that Rein Klazes' sound problem had the same error... -- Microsoft Licensing 6.0: Pay us now in advance, so that we can own you later.
Re: Major tidy up of Scroll.c to add foundations for flatscroll bars
On Fri, Oct 04, 2002 at 09:51:10AM -0400, Dimitrie O. Paun wrote: Note: Flat scroll bar APIs are implemented in Comctl32.dll versions 4.71 through 5.82. Comctl32.dll versions 6.00 and higher do not support flat scroll bars. Let's just drop support for the buggers (that is, forward the FlagSB_* calls to the standard calls, like we do now, but remove the FIXME's). You might want to keep in mind this little snippet I once wrote in a patch mail: :: AddWeb 5 Professional (free download) uses QT_Thunk() to thunk down to :: GetFreeSystemResources16(), and due to that crash and an exception :: handler it refused to load with a not enough resources error. :: This patch fixes it almost completely (except for crashes probably :: due to unimplemented flat scrollbars). :: Wonderfully complex program ! :) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: [Version] in ~/.wine/config
On Mon, Sep 30, 2002 at 10:20:58PM -0500, Chris Morgan wrote: Any reason why we don't default the windows version to something recent like Win2K and let the user change this to an older version if necessary? As has been said some times before, this value is a *forced* value, which thus overrides Wine's version detection mechanism in case no value is forced. IOW: a bad thing to do per default. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: Fix to protect users from selves.
On Sun, Sep 29, 2002 at 09:03:24PM +0200, Sylvain Petreolle wrote: Me to... This name is absolutely correct and could be used by another program. I verified it : I created a file called !$!$.txt and a directory on my desktop under Windows NT. Yep, exactly. Please research the exact names/content of certain registry keys instead that some people suspected to be necessary to prevent Explorer from setting the World on fire. -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: Patch - Fix typo
On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: I noticed this when adapting WINE code for ReactOS [...] - * DialogBoxIndirectParam (USER.240) - * DialogBoxIndirectParam16 (USER32.) + * DialogBoxIndirectParam16 (USER.240) + * DialogBoxIndirectParam (USER32.) */ INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, HANDLE16 dlgTemplate, HWND16 owner16, DLGPROC16 dlgProc, No this is correct. The 16 bit function's external name is DialogBoxIndirectParam The 32 bit function's external name is DialogBoxIndirectParam16 Then maybe add a comment instead: (yep, 16/32 naming is correct) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: Fix lossage due to pathname truncation in calls to MODULE_LoadLibraryExA
On Thu, Sep 12, 2002 at 08:38:09PM +1000, Michael Beach wrote:
Recently I've been using WINE to run a Win32 exe which needs to load certain
DLLs which are located in the same directory as the exe. I was most perplexed
when I found that this worked initially, but when I moved the exe and DLLs to
a different directory it stopped working ie WINE would refuse to start the
exe, claiming that it was unable to load the required DLLs.
After some debugging, I discovered that the critical factor was the length of
the pathname to the exe, when it passed a certain length it stopped working.
However this length was way short of the MAX_PATH value of 260.
Ah, cool finding !
static BOOL DIR_TryModulePath( LPCWSTR name, DOS_FULL_NAME *full_name, BOOL win32 )
{
-/* FIXME: for now, GetModuleFileNameW can't return more */
-/* than OFS_MAXPATHNAME. This may change with Win32. */
-WCHAR bufferW[OFS_MAXPATHNAME];
+WCHAR bufferW[MAX_PATH];
LPWSTR p;
if (!win32)
-727,13 +725,13
if (!GetCurrentTask()) return FALSE;
if (!GetModuleFileName16( GetCurrentTask(), buffer, sizeof(buffer) ))
return FALSE;
-MultiByteToWideChar(CP_ACP, 0, buffer, -1, bufferW, OFS_MAXPATHNAME);
+MultiByteToWideChar(CP_ACP, 0, buffer, -1, bufferW, MAX_PATH);
} else {
- if (!GetModuleFileNameW( 0, bufferW, OFS_MAXPATHNAME ) )
+ if (!GetModuleFileNameW( 0, bufferW, MAX_PATH ) )
return FALSE;
}
if (!(p = strrchrW( bufferW, '\\' ))) return FALSE;
-if (OFS_MAXPATHNAME - (++p - bufferW) = strlenW(name)) return FALSE;
+if (MAX_PATH - (++p - bufferW) = strlenW(name)) return FALSE;
strcpyW( p, name );
return DOSFS_GetFullName( bufferW, TRUE, full_name );
Argl, why does this code use the buffer size contants instead of
sizeof(variable) !?
I suggest we always specify buffer length constants only *once*,
namely at creation of the buffer.
Not doing so can be potentially very harmful if we decide to change
the buffer length and then manage to forget one or more length constants...
Maybe you could even also fix that weirdness in our code ?
Thanks ! :)
--
The Declaration of Software Freedom:
http://freedevelopers.net/freedomdec/index.php
