- Wine-Devel - list.winehq.org

Personal tree with interesting patches
by Mike Hearn April 4, 2004

April 4, 2004

Hi, As I'm pretty busy right now and won't have time to work on the various misc projects I've been working on up until recently for the foreseeable future, I'm checking them into my personal arch archive for people to play with and maybe work on themselves. My archive co-ordinates: http://navi.cx/~mike/archive/2004 mike(a)navi.cx--2004 so, you'd use: $ tla register-archive http://navi.cx/~mike/archive/2004 There are currently only two interesting branches: wine--mainline--0.9: misc patches that were never applied for whatever reason, debug delay, lockwindowupdate (disabled), that sort of thing as i find more patches around my system i'll check them in for safekeeping wine--loadarea-reserve--0.9 execshield/prelink work, see the log message in patch-1 for details on what remains to be done Have fun! thanks -mike

2 2

installation program
by Brian Vincent (C) April 4, 2004

April 4, 2004

On the To Do List (c.4) is an item for having a new graphical Wine install program. Anyone ever looked at Frank Hendrickson's WineTools program? http://franksworld.net/winetools.html It used to be written in some funky language, now it's all shell script. Anyway, if you look at the script (wt210) you'll notice he uses xdialog ( http://thgodef.nerim.net/xdialog/ ) for the GUI. So here's what I'm wondering.. How feasible would it be for Wine to create a new Winelib program (say, wdialog) and use a similar concept as Frank? wdialog would simply replicate the functionality of xdialog. We could potentially fail gracefully into shell mode if Wine can't start. It might be a cheap and simple way to get a GUI front-end. Of course, all this requires sane defaults so Wine can actually run wdialog. Any thoughts? --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

1 0

Re: appdb - improvement in serching out bugs
by hatky April 4, 2004

April 4, 2004

On Sunday 04 April 2004 06:21, tony_lambregts(a)telusplanet.net wrote: > The current code can get bugs that have nothing to do with the AppDB. This > should fix it. > > -- > > Tony Lambregts I think this is wrong, you are saying the url in bugzilla should be exactly "appdb #" where it should realy be "http://bugs.winehq,org/show_bug.cgi?id=#" -- Hatky, Worshiper of wine (http://www.winehq.org/) Impossible is only an opinion.

1 0

Microsoft SDK samples
by Jonathan Wilson April 4, 2004

April 4, 2004

Has anyone given thought to using the Microsoft SDK samples (e.g. DirectX samples) to improve WINE? i.e. take a particular sample and work away at it untill what you get in WINE matches what you get in Windows. Although I suspect that there are things that the MS samples dont cover :)

2 1

Re: Documentation for GDI Region Functions
by Alexandre Julliard April 3, 2004

April 3, 2004

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > and renamed the variables to Microsoft conventions. Please don't do that. The variable names don't matter at all for compatibility, so we don't have to follow the brain-damaged Microsoft conventions for them. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Developer's path to Windows/*NIX multi-platform?
by Dimitrie O. Paun April 3, 2004

April 3, 2004

You ask: > I am willing to re-write my best Windows software from scratch, but I > insist that the result is native or almost on Linux so there are not any > weird GUI glitches. Do you think Wine is the way to go for me, or am I > better off writing individual versions and keeping the Windows software > native and then producing QT or GTK versions for *NIX? I'm at a cross-roads > here, since I'll be dedicating years of work in whatever direction I take. IMO Wine is the perfect tool for you. We know, it's not perfect. But the best use of your time (and the most efficient) would be to: 1. Fix any problems in your apps (like reliance on strange Windows corner cases, use of very obscure features) 2. Help out fix Wine so that your apps run properly. This will not only help us a lot, but it will help you make good use of your time, and it will allow you to do cross platform development (even for Windows) from your Linux box. Please direct questions to wine-devel(a)winehq.org, where people can help you out. -- Dimi.

7 9

W95INF32 implementation, incase it's useful to anybody
by Mike McCormack April 3, 2004

April 3, 2004

Hi All, In the process of understanding another bug, I did a little work to implement w95inf32, which appears to be a small IE/win9x only DLL and which is probably of not much use to Wine. It appears to be a think wrapper 32bit around 4 functions in SETUPX. So this is just for documentation purposes, and incase anybody is curious or finds a real need for this DLL. Mike --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/Makefile.in 2004-03-30 12:03:27.000000000 +0900 @@ -0,0 +1,20 @@ +#MKDLL_SKIP +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = w95inf32.dll +IMPORTS = setupapi kernel32 +ALTNAMES = w95inf16.dll + +SPEC_SRCS16 = $(ALTNAMES:.dll=.spec) + +C_SRCS = \ + w95inf32.c + +(a)MAKE_DLL_RULES@ + +w95inf16.spec.c: w95inf16.spec + $(WINEBUILD) $(DEFS) $(DLLFLAGS) -o $@ --main-module $(MODULE) --spec $(SRCDIR)/w95inf16.spec + +### Dependencies: --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/w95inf32.c 2004-03-29 17:07:20.000000000 +0900 @@ -0,0 +1,91 @@ +/* + * W95INF32 - This is a small 32bit interface to SETUPX + * + * Copyright 2004 Mike McCormack for CodeWeavers + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include <stdarg.h> +#include "windef.h" +#include "winbase.h" +#include "winuser.h" + +#include "setupapi.h" + +#include "wine/debug.h" + +WINE_DEFAULT_DEBUG_CHANNEL(w95inf32); + +BOOL WINAPI CtlSetLddPath32( LPSTR x, LPSTR y ) +{ + FIXME("%s %s\n", debugstr_a(x), debugstr_a(y) ); + return FALSE; +} + +BOOL WINAPI GenFormStrWithoutPlaceHolders32( LPSTR dst, LPCSTR src, LPCSTR filename ) +{ + HINF hinf; + DWORD ret = 0; + + FIXME("%p %s %s\n", dst, debugstr_a(src), debugstr_a(filename) ); + + hinf = SetupOpenInfFileA( filename, NULL, INF_STYLE_WIN4, NULL ); + if( !hinf ) + return GetLastError(); + + /* FIXME: call LookupStringInTable? */ + strncpy(dst, src, MAX_INF_STRING_LENGTH ); + + SetupCloseInfFile( hinf ); + + return ret; +} + +DWORD WINAPI GenInstall32(LPCSTR filename, LPCSTR section, LPCSTR directory, DWORD flags) +{ + HINF hinf; + void *context; + DWORD ret = 0; + + ERR("%s, %s, %s, %08lx\n", filename, section, directory, flags ); + + hinf = SetupOpenInfFileA( filename, NULL, INF_STYLE_WIN4, NULL ); + if( !hinf ) + return GetLastError(); + + context = SetupInitDefaultQueueCallback( 0 ); + if (!SetupInstallFromInfSectionA( 0, hinf, section, flags, 0, NULL, + SP_COPY_NEWER_OR_SAME, SetupDefaultQueueCallbackA, + context, 0, 0 )) + { + ret = GetLastError(); + ERR("Failed %08lx\n",ret); + } + + SetupTermDefaultQueueCallback( context ); + + SetupCloseInfFile( hinf ); + + return ret; +} + +BOOL WINAPI GetSETUPXErrorText32(long a, long b, long c) +{ + FIXME("\n"); + return FALSE; +} + --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/w95inf32.spec 2004-03-29 17:04:15.000000000 +0900 @@ -0,0 +1,9 @@ +# w95inf32 functions have @nn in their names... +# winebuild removes the last @xx in a function name. + +1 stdcall CtlSetLddPath32(a)8@8(str str) CtlSetLddPath32 +2 stdcall GenFormStrWithoutPlaceHolders32(a)12@12(ptr str str) GenFormStrWithoutPlaceHolders32 +3 stdcall GenInstall32(a)20@20(str str str long) GenInstall32 +4 stdcall GetSETUPXErrorText32(a)12@12(long long long) GetSETUPXErrorText32 +5 stub w95thk_ThunkData32 +

1 0

When saving a file with staroffice it is not saving with extension.
by Ravi Kumar April 2, 2004

April 2, 2004

Hello Sir, I am working with wine for some time now. I faced with a problem, whenever i am saving a file from Windows version of Staroffice from wine it is saved without extension. I think it is a problem with wine, as staroffice in windows stores files with extensions. I am using wine-20031118 version. Can anybody help me out in this regard. I will also check out to see if it has been solved in later versions. Thanking in advance. regards, ravi.

3 2

Development CDs for Windows
by Steven Pignataro April 2, 2004

April 2, 2004

I have a large amount of Windows Development CDs....i am wondering if these would be of any interest to the Development team of Wine.... I think that these would become very usefull at developing for Wine as well as alot of what Windows does is still most of the same. They are Windows NT 4 development kits and much much more. We where going to chuck them at my school...but salaviged them Please let me know Thanks -- Steven Pignataro A+ Partner/ CSO Computer Vision Networks, Inc. Toll Free: 866-897-8896 Phone: 269-979-5582 Fax: 269-288-0418 http://www.computervisions.net/ (c)2002-2004 --

1 0

Re: Developer's path to Windows/*NIX multi-platform?
by greensh＠knology.net April 2, 2004

April 2, 2004

> integration. Ideally, we will have a GTK theme and a QT theme > that just calls the respective toolkit's theming code, so a > Wine app will look native both in GNOME and in KDE. I 100% agree > that native integration is paramount, and this is why we will > have it. This sounds very good. Maybe someday. > Since you've mentioned the toolkits, a small comment on that. > Of the two only QT is a serious option for cross-platform development. > It's a good option, but it's not perfect because your application > will not be native in GNOME, Well not to start a KDE vs Gnome debate, but Gnome is way behind KDE development... it doesn't even support Superkaramba (last I checked). Gnome users typically do not prefer KDE or Qt, and part of that stems from that KDE was developed using Qt and it's integration is woven throughout. > you will not be using the native toolkits > in Windows, you have to pay a lot of licensing fees, etc. You only pay licensing if your Qt app is commercial. The free version is perfect for opensource (ie GPL software) hence why it's included in almost all linux distros and you can D/L the same version for winders. Maybe > wxWindows is a better option... It requires too many code changes (at least in Python) for easy cross-compiling. In Qt you simply generate a .pro file for the platform. Shaun > > -- > Dimi. > > > > >

2 1