wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

NtPulseEvent
by Robert Lunnon 05 Apr '04

05 Apr '04

What is the status of NtPulseEvent it emits a diagnostic messages fixme:ntdll:NtPulseEvent (7c,0) yet it looks to me that NtPulseEvent is implemented but the fixme is bogus Anyone know about this ? BTW Has anyone experience with the Skype application under linux, does it work there ? Bob b

2 1

Should winemaker be able to handle this
by Bill Medland 05 Apr '04

05 Apr '04

I haven't been following the winemaker stuff so I don't know whether it is supposed to be able to handle this (and is broken) or not. I am having to play with the "build a builtin dll to wrap a linux so" concept again after a year or so since the last time, as discussed in the Winlib manual, chapter 5. I see that winemaker has changed since then. In particular the bit that is not working for my case is the -D, -I, -L and -l options. What I want is to run winemaker to generate the build environment and then do the build. What I used toi have was: #! /bin/bash # Run this script in order to pass the correct arguments to winemaker so that # it can set up the build environment winemaker --nosource-fix --nogenerated-specs --dll --single-target mytarget --nomfc -DMY_SETTING -I$MY_INC_DIR -L$MY_LIB_DIR -lmylinuxso . I see that we don't bother with generating spec files any longer. However I see that the -D, -I, -L and -l options don't find their way into the Makefile these days. Is that by design or a bug? (i.e. do I have to fix winemaker or do I need to look at a different way of doing it) -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

4 5

RE: Handling dialogs created without using templates
by Santosh Siddheshwar 05 Apr '04

05 Apr '04

Hi, Thanks. Would you be able to share details of the changes you did for handling MDI windows? Regards Santosh > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry@baikal.ru] > Sent: Tuesday, March 30, 2004 7:40 PM > To: Santosh Siddheshwar > Cc: wine-devel(a)winehq.com > Subject: Re: Handling dialogs created without using templates > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > Yes attached is a sample which is pretty similar to what I described > > below. > > Thanks. Now I see where the problem is. We have to hook dialog creation > code into common window creation code, something similar to what I've done > recently for MDI. Alexandre, are my thoughts correct? > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

Re: Re: dbghelp
by Pouech Eric DMI AEI CAEN 05 Apr '04

05 Apr '04

> UnDecorateName is still a stub, while our winedump has some a good > framework for UnDecorateName, also translating into a GCC way and not in a > VC++ way. How should these things go together? See the comment in dbghelp.c !! My first thouhgt would be to make a .a lib out of winedump code, and use it in winedump and msvcrt and / or dbghelp. I haven't studied yet the best way to share the code between msvcrt and dbghelp A+

1 0

Re: appdb - improvement in serching out bugs
by tony_lambregts＠telusplanet.net 04 Apr '04

04 Apr '04

Quoting hatky <hatky(a)hatky.myz.info>: > > 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=#" > > No, no, no... read the patch again. The current code is correct as far as it goes, but it grabs the substring. So when the appdb# is 68 it grabs bugs that for appid 680, 681... 689. It will also grab bugs that just happen to have 68 in the url. My testing with this has been limited somewhat since I have not been able to set up the appdb on my machine but I know enough to know that the code as I have submitted will do what it needs to do. -- Tony Lambregts

1 0

Re: dbghelp
by Uwe Bonnes 04 Apr '04

04 Apr '04

>>>>> "Eric" == Eric Pouech <pouech-eric(a)wanadoo.fr> writes: Eric> Eric Pouech a écrit : >> This is a first (and incomplete) shot at implementing the dbghelp >> DLL. Eric> forgot to say that: - this patch must be applied before the ones Eric> on imagehlp & taskmgr - code is highly derivated from winedbg Eric> current code Eric> I'm also working on a winedbg version based on this DLL, but it Eric> isn't ready yet (as dbghelp seems to get a bit more mature, I Eric> thought some people might be interested in testing it) UnDecorateName is still a stub, while our winedump has some a good framework for UnDecorateName, also translating into a GCC way and not in a VC++ way. How should these things go together? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Personal tree with interesting patches
by Mike Hearn 04 Apr '04

04 Apr '04

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) 04 Apr '04

04 Apr '04

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

Microsoft SDK samples
by Jonathan Wilson 04 Apr '04

04 Apr '04

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

winapi_stats
by Tom 03 Apr '04

03 Apr '04

Hi, http://www.winehq.org/site/winapi_stats Is incorrect as it shows Total 19640 100% 100% would be nice but its incorect! Tom

3 6

Re: Documentation for GDI Region Functions
by Alexandre Julliard 03 Apr '04

03 Apr '04

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 03 Apr '04

03 Apr '04

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 03 Apr '04

03 Apr '04

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 + +@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@8@8(str str) CtlSetLddPath32 +2 stdcall GenFormStrWithoutPlaceHolders32@12@12(ptr str str) GenFormStrWithoutPlaceHolders32 +3 stdcall GenInstall32@20@20(str str str long) GenInstall32 +4 stdcall GetSETUPXErrorText32@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 02 Apr '04

02 Apr '04

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 02 Apr '04

02 Apr '04

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 02 Apr '04

02 Apr '04

> 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

Re: GDI: Merge the enhmfdrv into one .c file.
by Mike McCormack 02 Apr '04

02 Apr '04

I object! Being one of the people who sometimes works on EMFs, I don't like this change. A flat namespace in my mind meants that we have one dll's code in each subdirectory in wine/dlls, not that there's no other subdirectories under those. It's a bad precedent to set that each dll can have no further subdirectries. I don't think this change is necessary, and it's going to make the EMF code harder to manage, since the file you've created is very big. Ditto for the MF change. Mike Dimitrie O. Paun wrote: > Merge the entire enhmfdrv into one .c file. > It's not big, and it's the way we usually do > things in wine (e.g. dlls/comctl32/*.c). > Moreover, we get rid of the extra dir in > dlls/gdi/, and gets us closer to a flat > dlls/*/ namespace.

2 2

Re: Developer's path to Windows/*NIX multi-platform?
by greensh＠knology.net 02 Apr '04

02 Apr '04

At work we write A LOT of 3D graphics code that has requirements to run on winders/linux/macintosh. Qt has definitely proved the way to go (5 years now) with only minor changes required and then it worked on ALL platforms. Java and Python were too slow and required too many code changes for each platform, whereas Qt worked with our existing C/C++ code nicely. BTW, a real good book that's out now is "C++ GUI Programming with Qt 3" by Jasmin Blanchette and Mark Summerfield. It starts very basic from Hello World. It's worth the $30. I'd have to say, so far from what I've seen Wine still has a long way to go before it's ready for production, and reliable use... it's getting there but just not there yet. It's great for porting apps, but too poorly documented for actual development. I mean this forum is about it and you're lucky if you can get answers. But thanks to all the helpful people here, maybe it will grow. Shaun On Thu, 1 Apr 2004 17:39:14 -0500 (EST), "Dimitrie O. Paun" <dimi(a)intelliware.ca> wrote : > > 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. > > > > > > >

2 1

abnt2 delete keys problem
by Rafael Ávila de Espíndola 02 Apr '04

02 Apr '04

I am having the following problem with a abnt2 (Brazilian) keyboard: When the numlock is off both delete keys work correctly. If the numlock is on both key produce a delete plus a comma. The message http://www.winehq.org/hypermail/wine-patches/2002/12/0329.html appears to describe the same problem. But the proposed patch didn't work for me. Attached is a xev log. The numlock is initially on. Them the I press the middle keyboard delete, keypad delete, numlock, middle keyboard delete and keypad delete. Thanks for any help. Rafael Ávila de Espíndola

2 4

MFC app compile problems with AFX
by greensh＠knology.net 01 Apr '04

01 Apr '04

Since I was told the winlib docs are out of date, I'll try posting this problem. winemaker --interactive seems to have worked and converted the 'winders' source .cpp and .h files and made the backups fine. It only created one file; Makefile When I type 'make' it produced a bunch of afx errors needing only five afx*. h files, so I copied these over from the VS6 directory, ran 'make clean', but hen it needed a ton more, so I copied them all afx*.h and afx*.inl. Then 'make' gets all the way down to the first errors; /usr/local/include/wine/windows/rpcndr.h:383: error: non-local function ` <anonymous struct>* NDRSContextUnmarshall2(void*, void*, long unsigned int, void*, long unsigned int)' uses anonymous type In file included from afxdtctl.h:19, from StdAfx.h:18, from ArbreNiv.cpp:2: afxdisp.h:75: warning: malformed '#pragma pack(push[, id], <n>)' - ignored afxdisp.h:1182: error: friend declaration requires class-key, i.e. `friend struct COleDateTimeSpan' afxdisp.h:1259: error: friend declaration requires class-key, i.e. `friend class COleDateTime' afxdisp.h:1408: warning: #pragma pack (pop) encountered without matching #pragma pack (push, <n>) In file included from afxdisp.h:1413, from afxdtctl.h:19, from StdAfx.h:18, from ArbreNiv.cpp:2: afxole.inl: In constructor `COleVariant::COleVariant(const CHAR*)': afxole.inl:97: error: `vt' undeclared (first use this function) afxole.inl:97: error: (Each undeclared identifier is reported only once for each function it appears in.) afxole.inl: In constructor `COleVariant::COleVariant(unsigned char)': afxole.inl:101: error: `bVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(const COleCurrency&)': afxole.inl:103: error: `cyVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(float)': afxole.inl:105: error: `fltVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(double)': afxole.inl:107: error: `dblVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(const COleDateTime&)': afxole.inl:109: error: `date' undeclared (first use this function) afxole.inl: In member function `DWORD COleSafeArray::GetDim()': afxole.inl:283: error: `parray' undeclared (first use this function) Can anyone help? Any ideas for me to try? I can run the winders executable with wine, but it's very buggy and will crash easily, so I wanted to use winelib. Shaun

2 1

ANNOUNCE: CVS to arch gateway
by Mike Hearn 01 Apr '04

01 Apr '04

Hi everybody, I'm pleased to announce the public availability of a gateway from WineHQ CVS to the GNU arch version control system. It marks the beginning of an experiment not just in new forms of source control, but in new ways for the Wine project to be organized and function. Nobody knows if it will catch on, but a few of us (me, dimi and alexandre) have been discussing trying out arch for some time. Carpe dium! ==================================================================== For those who already know arch, here are the details: archive coordinates: http://navi.cx/mike/wine/archive mike(a)winehq.org--wine/wine--mainline--0.9 It is synchronised with CVS on the hour, every hour and a cacherev is generated once a week. There are a couple of useful scripts in the root directory, branch and merge which are described in the README.ARCH file. It is mirrored here: http://mirrors.sourcecontrol.net/mike@winehq.org--wine/ For your convenience, and for people who have never used arch before, here is an adapted form of the README file. It's available in pseudo-HTML here: http://navi.cx/~mike/wine/ ===================================================================== README.ARCH Mike Hearn <mike(a)navi.cx> GNU arch is a distributed source control system. Unlike CVS, arch trees can be branched and branched again with no write access to the original archive. It has a variety of other interesting features - for instance, it uses atomic commits and can operate using a variety of network protocols. For more information see http://wiki.gnuarch.org The rest of this readme is going to take the form of a tutorial on how to use arch with Wine. We'll start with the really basic tasks that even non-developers may wish to use, and work up to advanced usage (branching and merging). It will not answer every question you have, for that use the wine-devel mailing list for discussion :) * Tracking Wine development --------------------------- You might not be reading this file from an actual arch project tree, so let's start with how to get a copy of the gateway tree. First of all you need to install "tla", the reference implementation of arch. You can get it from the gnuarch.org website, but a simpler way is to use the prebuilt binary available here: http://www.navi.cx/~mike/wine/tla Download, chmod +x, copy to /usr/local/bin and you're set. The binary should work on any Linux distro. Yes, it's large, the arch build system contains local copies of various libraries. Now it's installed, run the following command: tla register-archive http://www.navi.cx/~mike/wine/archive/ Once it's registered succesfully (you get a message when that happens), you can run the following command to check out the tree: tla get mike(a)winehq.org--wine/wine--mainline--0.9 winehq This will place a copy of the gateway tree into the winehq/ directory. "winehq" is a good name to use, because you may later wish to download other branches or even make your own, but there will only ever be one WineHQ tree - the one controlled by Alexandre Julliard. Yes, I know mike(a)winehq.org isn't a valid email address, it doesn't matter, the email is only for namespacing and identification reasons :) The checkout will take a long time even on a fast link: the Wine sources are 10mb. Once downloaded, updating the tree is easy: tla update So, now you have an arch project tree, what can you do? Arch has a lot of interesting commands, try "tla changelog | less" and "tla missing -s". Have fun! * Simple development ==================== The easiest way to use arch for development is the same way we use CVS: by making changes in a tree, generating a diff from those changes, then emailing in the patch. Let's see how that works. First of all, we make a change to the tree. Then we use: tla changes --diffs to get a patch. In fact, this will generate a lot of extra stuff that you don't really need - feel free to remove it, but it's not required; patch can strip out garbage from patches automatically. You can get diffs for individual files with "tla file-diffs". Be warned! These commands work against the last revision you updated to, they do *not* work against the latest version in the remote archive like CVS does. So you probably want to update first. However, unlike people just tracking the tree, you DO NOT want to use update! What update does, roughly speaking, is reverse changes made to the tree, apply the missing patches in turn, then reapply the changes. If there are any conflicts they appear in patch style .rej and .orig files. There is a better way. Arch has a very interesting and powerful command called "star-merge". Star-merge allows you to merge your tree with another tree (subject to certain rules), in a Just Works(tm) fashion. It will deal with repeated merges, and it works if the person you are merging from previously merged with you. To make this simpler, I've written a script that figures out what you branched from (if anything), and then merges from it. In effect, this is like "cvs update". ./merge This operation can be quite slow (because it involves constructing multiple trees and comparing etc), but it is generic and will work both with the gateway tree and branches - and it gives 3-way merge inline conflict markers too. If you want to do it faster, and you don't mind having patch style .rej files generated in the case of conflicts, try: tla replay which simply downloads and applies each patch in turn. "tla update" does work too, why not try them all to see which you prefer? * More advanced development =========================== So, here comes the interesting part. Now we've covered the basics, it's time to find out how to make our own branches and commit to them. You need to do a bit of setup. Firstly, you need to tell arch who you are: tla my-id 'Mike Hearn <mike(a)navi.cx>' You have to use an ID of this form, arch won't accept others. Now you need to create your own archive. An archive is a rough equivalent of a CVS repository with one key, fundamental difference: an archive is a personal thing which can contain trees from many different projects. Typically a person has only one archive, though there's nothing to stop you having more. Archives are just directories and files, no special server software is required to run one. You just need some web space. The basic workflow with arch goes something like this: 1) Write patch 2) Commit to branch 3) Upload to a mirror of your archive Your actual archive is usually kept locally, which means you can work and commit offline. You then mirror the archive on a remote machine so others can access it. If people want to work on your tree, they branch it, set up their own archive and then you pull from that. In other words, only you have write access to your own archive. So, you need to create a directory to hold your archive, like this: tla make-archive mike(a)navi.cx--2004 ~/Code/Arch/2004 tla my-default-archive mike(a)navi.cx--2004 The named directory should not exist, but its parents should. An archive name must have the form of an email address followed by two dashes followed by a name. I've named it after the year of creation which is pretty common, but it can be called anything. Now, to speed things up, you probably want to create a revision library. This is basically a cache (using hard links to be space efficient) of revisions. You probably want it. Make one like this: mkdir ~/Code/Arch/RevLib tla my-revision-library ~/Code/Arch/RevLib tla library-config --sparse --greedy ~/Code/Arch/RevLib OK. Now you just need some web space. Arch can write to web space using ftp, sftp (ssh), or WebDAV. You probably want sftp. If you don't have any web space you can use talk to me and I'll put you in touch with people who can give you some space specifically for hosting archive mirrors. For now, don't bother with a remote mirror. Just play with a local copy, that way you can delete things if you make a mistake (you can delete a branch with rm -rf inside the archive, nothing will break). Let's say you wish to branch the WineHQ tree, and start work on the winecfg program. The simplest way to do this is to create a directory somewhere that you will keep all your wine trees in. I use /source/wine/arch. Then do this: tla get mike(a)winehq.org--wine/wine--mainline--0.9 winehq cd winehq ./branch winecfg The branch script is in the root of the gateway tree, and is written by me. It's designed to let you rapidly branch a given Wine tree. It works by "tagging" the new tree in arch, then duplicating the current tree using hard links before finally forcing the duplicate tree to the new branch. WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! If you use the branch script you MUST use an editor that breaks hard links. emacs does by default, vim does if you :set bkc=no (though be warned, this will interfere with some programs that invoke vim like crontab -e). zile does not. If you want to use an editor that does not break hard links you must remove the -l option from cp in the branch script so a real duplicate is made. This uses more disk space and is slower to copy, but is safer. The result is a new directory called winecfg/ created as a sibling of the current directory. You can now commit to this tree however often you like. Running merge will update the branch from the tree you branched from (in this example, the gateway tree). You can branch from that tree again, and so on. Other people can branch from your tree in the same way! Feeling giddy with power yet? No? Good. Remember that patches which aren't in the mainline tree aren't reaching 99.9% of the users - being able to branch is useful but don't use it as an excuse to not get patches upstreamed! The new branch is put in the default archive and the name is derived from the current, for instance running branch in mike(a)winehq.org--wine/wine--mainline--0.9 with the parameter "winecfg" produces a branch with the name mike(a)navi.cx--2004/wine--winecfg--0.9 Now you need to publish a mirror: tla make-archive --mirror mike(a)navi.cx--2004 sftp://navi.cx/home/mike/public_html/archive and update it when you have done some commits tla archive-mirror which actually uploads the changes. If you are always connected, you can run the first make-archive command (back when you created your archive) with a remote location straight away, but doing it locally then mirroring is more common. Finally, tell people the URL of your archive so they can register it and grab your tree. That's it! Have fun! If you have any questions ask them on the wine-devel mailing list.

3 4

Ping: Gerald Pfeifer
by Dimitrie O. Paun 01 Apr '04

01 Apr '04

Hi Gerald, It seems nobody can send you email because: Recipient: <pfeifer(a)dbai.tuwien.ac.at> Reason: Service unavailable; Client host [fep03-mail.bloor.is.net.cable.rogers.com] blocked using abuse.rfc-ignorant.org; Not supporting abuse@domain; See http://www.dbai.tuwien.ac.at/block.html Nice, but that make the email account a bit useless, no? :) Anyway, I had a small question for you: what version of FreeBSD are you building Wine for? -- Dimi.

1 0

Re: shell32 patch 28
by Alexandre Julliard 01 Apr '04

01 Apr '04

"Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > Changelog: > _ILCreateFolder(), _ILCreateValue(): check for NULL in AlternateFileName cAlternateFileName is an array, it cannot possibly be NULL. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: bug in winemine about box
by Ivan Leo Murray-Smith 01 Apr '04

01 Apr '04

> Are you really running a windows version of winemine under XP running in > Bochs? Or is the screen shot misleading? No, that is a windows build of winemine running on windows server 2003 (Got a 180 day trial license from M$, it's a free download), that is NOT windows xp. xp does run on bochs, but I don't have xp (Got some OEM cds with the pc(that I got for free), but trashed them as they were system restore cds and didn't run on bochs, and I didn't want dual boot), a few shots are at http://www003.portalis.it/115/win2k3/ Ivan.

1 0

Fwd: Developer's path to Windows/*NIX multi-platform?
by Sylvain Petreolle 01 Apr '04

01 Apr '04

You should write to wine-devel for that. ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) Say NO to software patents Dites NON aux brevets logiciels "You believe it's the year 1984, when in fact, its closer to 2184"1984 / Matrix Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel