- Wine-devel - list.winehq.org

Apps that installs VBA
by Max 07 Jul '02

07 Jul '02

Installing AutoCAD 14, I get everytimes an error telling that VBA (visual basic for applications) cannot be installed (the messagebox tells a very very meaningful 'error 18' (sigh) and aborts VBA setup). As I've seen that someone is working on visual basic apps (maybe Ann and Jason Edmeades ?), does someone have an idea of the solution ? Regards Max

3 5

Re: Suggested bitmap coords resolve
by Andreas Mohr 07 Jul '02

07 Jul '02

On Sun, Jun 23, 2002 at 06:18:13PM +0300, P. Christeas wrote: > This patch resolves some trouble with bitmap drawing (DIBs), when the y-axis > uses negative mapping (LPtoDP). This makes Aut0CaD r. 14 usable under wine. > Please note bug #720, which was closed by this patch and note any problems w. > the patch. > > The second patch is a simple suggestion about a NULL handler. IMHO all NULLs > coming from external programs-libs should be handled in a prog. In that case, > a NULL causes no harm, but I guess my 'early test' may introduce a minor > speedup. "Am I right?" No, IMO this is not correct. If Windows doesn't handle NULLs, then we shouldn't either. How are we supposed to detect problems with our API implementation if all we ever do is handle every single problem gracefully ? That way we'll never find out about that grave implementation problem of ours leading to a NULL value... -- "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

2 1

Wrote an graphical wine.config frontend
by Clemens Eisserer 06 Jul '02

06 Jul '02

Hi Wine-Hackers! I wrote an graphical tool to make the administrations of the config-file easier for those windosen. Currently its only an prototype and isnt very stable. Its written in Java, compiled into native-Unix-binaries and it uses java-gtk as gui-toolkit. Its nearly as fast as C++ but coding is much easier and faster. I added a screenhot, and I hope that nobody's angry about the big download-size :-( My problem is that I dontknow all the wine.config options avaible, I've just implemented all active and all not active (;) options, only the program-specific setting are still not implemented and they wont be implemented in the near future. So is there an overview avaible, which explains all the options aviable in the config? Thx , Linuxhippy

1 0

Graphical Configuration-Tool for wine.conf
by Clemens Eisserer 06 Jul '02

06 Jul '02

Hi! I'm one of two web-masters of www.linux-wine.de . Many people in our forum asked for a graphical frontend to the wine.config. And because google didnt find anything, I've just wrote a prototype. Its written in Java, is compiled to a native-Linux program via gcj and uses java-gtk as toolkit. It is nearyl as fast as a C++ program, but coding is much faster und easier. And (for all GNU-fanatics) its fully GPL-compatible.... My problem is, that I dont know all options of the config-file. Till now I only implemented the options which stands in my wine-config, including the ;-Entries. Only the specific-program settings are not iplemented, its too hard to make this part GUI-based (I'm so sorry, but my english is terrible). Is there somewhere an overview over all avaible options? Is such a tool already avaible, or an existing codebase? Please note that Jine (Jawy after the rewrite) isnt ready for use. O.K it does work, but the code is awful and I'm currently working on a rewrite. May I ask wine-questions for this tool at this list? Thx , Linuxhippy

2 1

Strange behaviour -- app starts only with --debugmsg+snoop
by Max 06 Jul '02

06 Jul '02

AutoCAD again ! After finally R14 runs fine, i'm trying with AutoCAD 2000. Setup goes ok (besides usual VBA problem). Starting with 'wine acad' gives a very early error of unhandled access violation. I tried to start it with --debugmsg +snoop to see what happened and, surprise, app starts up quite good. It then hangs much later, but that's another problem. So the question : how it's possible that requesting snoop messages bypasses the initial access violation ? I think that snoop adds only a thunk to calls on native dlls.... Any suggestion appreciated ! Regards Max

3 2

Re: The filedlg95 behaviour
by Ann and Jason Edmeades 06 Jul '02

06 Jul '02

This leads to an interesting question. The MSDN states (edited for w2k behaviour but others are teh same): Initial Dir: Pointer to a null terminated string that can specify the initial directory. The algorithm for selecting the initial directory varies on different platforms. Windows 2000: ------------- If lpstrFile contains a path, that path is the initial directory. Otherwise, lpstrInitialDir specifies the initial directory. If lpstrInitialDir is NULL and the current directory contains any files of the specified filter types, the initial directory is the current directory. Otherwise, if the application has used an Open or Save As dialog box in the past, the path most recently used is selected as the initial directory. However, if an application is not run for a long time, its saved selected path will be discarded. *****> Otherwise, the initial directory is the personal files directory of the current user. Otherwise, the initial directory is the Desktop folder. Questions... Windows has the 'personal files' directory set to My Documents - That is why when doing this patch I implemented it that way. If you are saying you would prefer the home directory to be this, then why dont we make the Personal Files registry key always point to the users home directory? We either have complete compatibility eg. files go in ~ which is the Unix methodology, but windows apps looking in \My Documents directly would work, or we can try to slightly unix-ify the windows way and use ~ as the My Documents directory. I'm not convinced a patch should be submitted unless this is addressed. I have no problems assuming my change is not 100% correct, but we dont want a bounce of patches where someone tries to swap it back later to fix a specific unix app. BTW It is not a registry key directly which changes the behaviour, moreover which version of windows is trying to be emulated by Wine at that time. Regards, Jason

1 0

Re: wine/ dlls/dsound/dsound_main.c dlls/x11drv/x1 ...
by Steven Edwards 06 Jul '02

06 Jul '02

> Log message: > No need to call GetModuleFileName16 now that > GetModuleFileNameA > handles 16-bit tasks. With this patch I can now build dsound on Mingw if I import ntdll. Are there going to be other places like this where the A/W function can be used rather then the 16? Thanks Steven __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com

2 2

Re: ShellExecute placeholder patch
by Eric Pouech 06 Jul '02

06 Jul '02

Duane Clark a écrit : > > As the comment to ShellExecute states, there can be placeholders in > commandlines retrieved from the registry. For example, MS Installer has > this string: [snip] Hi Duane, It would be better IMO to merge actually ShellExecute and ShellExecuteEx Most of what you need is already in ShellExecute but not in ShellExecuteEx (of course, ShellExecute should call ShellExecuteEx, but this isn't done yet) A+

2 2

The filedlg95 behavior
by Duane Clark 06 Jul '02

06 Jul '02

I was hoping to perhaps provoke discussion of the new behavior of the file dialog. Prior to this patch: http://www.winehq.com/hypermail/wine-cvs/2002/06/0028.html the default behavior was to start the open file dialog in the current directory. After the patch, the default behavior is to start in the C:\My Documents directory, though this can be changed with a registry key. While this is the default behavior on Windows, I am not sure that wine should copy this behavior so precisely. I personally think that the old behavior was better. I would think that very few Linux users would actually use the C:\My Documents directory. But perhaps my own preferences are coloring my views. I think the command line oriented nature of Linux would call for a occasional differences in behavior. Duane

2 2

RegEnumValueA bugs and patch in dlls/advapi32/registry.c
by Max 05 Jul '02

05 Jul '02

Well, finally found and corrected a bug that made AutoCAD R14 hang... I guess some other apps could have the same problem solved, but had no time to test more :) In RegEnumValueA, when the size for requested data buffer is too small, function should return an error (as it does), but also return correct buffer size (as it doesn't). Found in AutoCAD; it asked for a reistry key value, got error, and then looped forever trying to get val with wrong buffer size. I guess, but had no time yet to check, that this problem could happen somwhere else in Registry.c, I'll check it out next days. With this patch, finally AutoCAD R14 is perfectly usable in wine, even without a native windows installed ! Here the patch : --- dlls/advapi32/registry.c Sat Jul 6 01:29:08 2002 +++ /home/massimo/wine-patches/registry.c Sat Jul 6 01:35:32 2002 @@ -1157,6 +1157,9 @@ RtlUnicodeToMultiByteSize( &len, info->Name, info->NameLength ); if (len >= *val_count) { + /* CHANGELOG : 04.07.2002 by Max + MUST RETURN REQUESTED CORRECT BUFFER SIZE, NOT ONLY TELL IT'S WRONG */ + *val_count = len + 1 ; status = STATUS_BUFFER_OVERFLOW; goto done; } @@ -1174,6 +1177,9 @@ { if (len > *count) { + /* CHANGELOG : 04.07.2002 by Max + MUST RETURN REQUESTED CORRECT BUFFER SIZE, NOT ONLY TELL IT'S WRONG */ + *count = len+1 ; status = STATUS_BUFFER_OVERFLOW; goto done; } I'll just post it to wine-patches too. Regards Max

1 0