January 2003 - Wine-Devel - list.winehq.org

Re: Update: Wine & Mozilla

by Dimitrie O. Paun

On January 3, 2003 09:07 am, David Fraser wrote: > But I'm not sure what the standard way of trying this out is > Particularly should I be using the mozilla tools in the path, should I put > them before or after msys/mingw/cygwin, will they cause problems? I have no idea, I didn't yet manage to compile and run NSPR. If you did, that great -- let me know how you did it! :) -- Dimi.

Jan. 3, 2003

Re: RFH: ICON statement

by Dimitrie O. Paun

On January 3, 2003 08:30 am, Mehmet YASAR wrote: > Yep, > that works even with icon file named "x-x!xx", "-xxx" or "!xxx". (note > that I'm running Win2K) Thanks, I've just send a new patch in to support these as well. -- Dimi.

Jan. 3, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Dimitrie O. Paun

On January 3, 2003 01:54 pm, Alexandre Julliard wrote: > That's not another rule, it's just the standard behavior: functions > are called the same way under Wine and under Winelib. If we use the > wine_* functions in Wine too, then the rule is that in Winelib > everything is identical, except that TRACE/ERR/WARN/FIXME have to be > prefixed with WINE_. That's certainly easier and more consistent than > having a separate rule for the debugstr functions that is different > from everything else. Granted. But there is a fundamental difference: all other wine_* functions are so esoteric and rarely used, that we could even call them wine_esoteric_function_... and no one would be bothered by it :) Besides, they are meant to be called by some sort of portability layer in any decent app anyhow, so you'll have a few instances of those in any app, no matter how large. The debug functions are on the other hand the _most_ used functions in any app. A lot more than even the string functions. And those have names that are 6-8 char long. wine_dbgstr_point is 17 chars long. And in a TRACE statement, you're not unlikely to use 2-3 of these: WINE_TRACE("(lprc=%s, lppt=%s, nSize=%d)\n", wine_dbgstr_rect(lprc), wine_dbgstr_point(lppt), nSize); There is so many stuff in there... it's way too verbose, you don't know what's going on there anymore. Contrast with this: TRACE("(lprc=%s, lppt=%s, nSize=%d)\n", dbgstr_rect(lprc), dbgstr_point(lppt), nSize); or even: TRACE("(lprc=%s, lppt=%s, nSize=%d)\n", dbg_rect(lprc), dbg_point(lppt), nSize); Obviously, if people are going to use our interface, they are not going to use our long names directly. Why not allow them the option of using our short names? How many apps are going to have a TRACE macro _if_ they decide to use our debugging API? And if they do, they can -DWINE_NO_SHORT_DBG_API and be done with it (or we can enable it only if -DWINE_SHORT_DBG_API). -- Dimi.

Jan. 3, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Well, I've tried the dump-directly-to-output version, and it invariably > leads to ugly code. The usage of debuglvitem_t is _so_ much nicer > compared to anything else. And uniform. And easy to understand. > Granted, the function is a bit big, but the resulting string is not > that 'huge'. In fact, the function is big because I'm trying to minimize > the string (and thus uncluttered the output). The max_size of 200 that we > have now is more than enough for anything we need. As for the lifetime > of the string, it's _identical_ to the RECT, POINT, and SIZE ones. Not really; it's doing a lot more stuff between the time the string would be allocated and the time it is printed, even including other buffer allocations which would make it impossible to release the unneeded string space. If you don't want to make it dump directly to the output, you could put things into a stack buffer and then do a wine_dbg_sprintf to copy that buffer into the strings space. > On the other hand, cluttering all on Wine's code with wine_* and WINE_TRACE, > and WINE_ERR, is not also very appealing either. Look, let's not try to > solve world's problems: this is not the debugging API to end all debugging > APIs. It's Wine's internal one. And it's present interface is _nice_, and > easy to use. The thing is that it's not only internal, it's useful in Winelib apps because there are no good debugging functions in the Windows API. And everybody I know who has tried to use the debug API in a Winelib app has been confused by the different names. Now I'm not saying we should rename TRACE everywhere, but for new functions, especially ones that aren't used all that much, I don't think an extra 'wine' prefix is a problem, and it makes things a lot easier to follow. -- Alexandre Julliard julliard(a)winehq.com

Jan. 3, 2003

Re: sharpdevelop and .NET

by Sylvain Petreolle

have the same problem. using nt40: problem with windows version check. using winme: unable to install the MSI Installer. don't do that its .NET core... > I tried runninf sharpdevelop and it complained about a missing dll so > I'll try copying those over from my windows setup..... ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 3, 2003

Re: Problem with a VB app...

by Bill Medland

On January 3, 2003 01:43 am, Ben Clewett wrote: > Wine, > > Running a large VB app on 20021125, and I get this output: > > fixme:ole:CoSetState (0x653c3f80),stub! > fixme:ole:CoRegisterMessageFilter stub > fixme:win32:PE_CreateModule Security directory ignored > fixme:win32:GetCalendarInfoA > (00000809,00000001,20000030,(nil),0,0x403ac1f4): quarter-stub > fixme:win32:GetCalendarInfoW > (00000809,00000001,20000030,(nil),0,0x403ac1f4): quarter-stub > fixme:win32:PE_CreateModule Security directory ignored > wine: Unhandled exception, starting debugger... > fixme:ole:CoSetState ((nil)),stub! > > Is there anything I can do to make my application run? > > Ben That output probably has little to do with the application not running. Did the debugger come up? If so were you able to get a stack trace? Try running with --debugmsg +relay to see if the failure occurred during a wine function (but don't be surprised if it doesn't). Is the VB App commercial or a one-off? Does it have a name? (You never know; someone else may have been working with it) -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

Jan. 3, 2003

Re: wine/ library/debug.c include/wine/library.h i ...

by Dimitrie O. Paun

On January 3, 2003 12:45 pm, Alexandre Julliard wrote: > The thing is that it's not only internal, it's useful in Winelib apps > because there are no good debugging functions in the Windows API. And > everybody I know who has tried to use the debug API in a Winelib app > has been confused by the different names. That includes me. But since we're not going to rename everything (and this makes me so happy, I would have hate it if we did), the confusion is still going to be there. People are still going to have to learn that there is this mapping. But than, for magically chosen, obscure functions, they will have to learn another rule! Thing is, inconsistency always hurts more, even if done toward a better goal. How can things be any easier in such a situation? Furthermore, in this very case it's not clear at all to me we are aiming at anything better. I have seen no project that uses this long names for its debugging API. There are many reasons why not, I will not hash them here, but this simple observation should tell us something. I stand by my suggestion of having a way of exporting the shorter API independently of defining __WINE__. 99% of apps will be able to use it as is, and they'll be a lot happier. Our own internal apps will certainly be able to, and that's going to eliminate all confusion. For the ones that can't use it, most likely they'll go through the exercise of defining a shorter API anyhow, so nothing is lost or made harder for them. -- Dimi.

Jan. 3, 2003

Re: IE browsing local files

by Alberto Massari

At 15.11 03/01/2003 +0000, you wrote: >Hi all, > >When entering a local address, for instance "C:\" into the IE address >bar, it dies with a crash somewhere inside comctrl32 (it seems). Is this >because it tries to engage the Explorer view COM object, and that isn't >present in Wine? I am currently able to browse the local file system only if I use the native version of shell32.dll (btw, I use Wine with the "nt40" setting) Alberto ------------------------------- Alberto Massari eXcelon Corp. http://www.StylusStudio.com

Jan. 3, 2003

IE browsing local files

by Mike Hearn

Hi all, When entering a local address, for instance "C:\" into the IE address bar, it dies with a crash somewhere inside comctrl32 (it seems). Is this because it tries to engage the Explorer view COM object, and that isn't present in Wine? Also, a bit OT this one, but I've been told that the MS EULA in Office XP forbids running it on anything other than Windows. Is this true, and if so, is it legal for them to say this? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 3, 2003

Re: Update: Wine & Mozilla

by David Fraser

Dimitrie O. Paun wrote: >Hi folks, > >For those of you who follow my Winelib quest, one of the most >ambitious projects is compiling Mozilla under Wine. Needless >to say, this would be quite something to accomplish, and would >provide Wine with a formidable test for it's headers, and it's >tools (wine{build,gcc,wrap), wrc). > >The goal of course is to port the entire beast with very little >changes. For anyone who looked at the source, it should be clear >that this is the only way it can happen. If it requires massive >work, I'm just not going to do it. > >To accomplish this task, Mozilla needs to build first on mingw. >Unfortunately, Mozilla still requires MSVC to compile on Windows. >There is an ongoing effort that is tracked in bug #134113: > http://bugzilla.mozilla.org/show_bug.cgi?id=134113 > >I will be lending those guys a hand with the port. Mostly the >work seems to be done, they just need a gentle nudge to get it >in the tree (I hope :)). > >As always, your comments and suggestions are highly appreciated. > > > Hi I've read the bug, downloaded the source, trying to compile it on my Windows box... Applied the patches (straight-code.patch and rest.patch). But I'm not sure what the standard way of trying this out is Particularly should I be using the mozilla tools in the path, should I put them before or after msys/mingw/cygwin, will they cause problems? (Basically if they're first in the path then it says the host type is i586-pc-msvc, but if not, then it picks up i686-mingw or cygwin etc). David

Jan. 3, 2003