wine-devel

wine-devel@winehq.org

2 participants
84471 discussions

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by John K. Hohm 01 Nov '02

01 Nov '02

> > No, it's wrong. You should be using the Windows API (CreateProcess > > etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE. > Sorry, I had a few beers tonight ;) Ok, I just remembered what my concerns > were about using CreateProcess initially when I looked at MSDN: I think you need to look more closely at the LPSTARTUPINFO lpStartupInfo argument to CreateProcess. It points to a STARTUPINFO structure having HANDLE hStdInput, HANDLE hStdOutput, and HANDLE hStdError members, which are used if the dwFlags member has the STARTF_USESTDHANDLES bit set.

1 1

MDAC
by Gustavo Junior Alves 01 Nov '02

01 Nov '02

Hi guys, I don't know if this is the right place, but I actually trying to run some commercial applications on Wine. We have sucess in all aplications, but VB. These applications need to use MDAC, and this Microsoft package need to be licensed for commercial use. Anybody know any MDAC project? If not, what about to implement it on Wine? I know that it a huge API, but we need to start someday. Any comments??? Gustavo

1 0

Re: Wine FAQ - call for a volunteer
by Jeremy White 01 Nov '02

01 Nov '02

> > I expect to be living close to it for the next few months and may > well get some questions that don't appear on the mailing list. I also > don't see myself being able to find the time to do much coding, however > much I'd like to. > > On the other hand I'm not sure I can do things in a timely manner with > other commitments. Might be better to have a primary and reserve > maintainer. I'd certainly be prepared to take on the latter. > > I can at least offer to do things from a static IP to make access > control more certain (sorry, I'm a bit of a security freak). Okay, we have a backup FAQ volunteer. Who will be our primary? A certain path to fame, fortune, and a lot of thankless work <grin>. Jer

1 0

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by Jaco Greeff 01 Nov '02

01 Nov '02

On 01 Nov 2002 08:40:20 -0800, Alexandre Julliard <julliard(a)winehq.com> wrote : > No, it's wrong. You should be using the Windows API (CreateProcess > etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE. Sorry, I had a few beers tonight ;) Ok, I just remembered what my concerns were about using CreateProcess initially when I looked at MSDN: CreateProcess executes a Windows executable with parameters, whereas _popen executes as shell, ie. you can do stuff like _popen("dir/w") which will return an open file in which you can read the directory contents from. In essence under Windows, this gets executed at "cmd.exe /C dir/w". Now using CreatePorcess we can potentially do the same, provided that the executable (command interpreter) resides in your path. From MSDN: "The string can specify the full path and file name of the module to execute or it can specify a partial name. In the case of a partial name, the function uses the current drive and current directory to complete the specification." Now wera are faced with a problem in that wcmd is not a pure Windows application and it doesn't reside in your Windows filesystem, rather it is in your *nix path. In the case of _popen, a file-handle is returned which allows you to either read or write to the application unsing the normal fwrite/fprintf/etc. commands. CreateProcess has an information structure containing the following information: typedef struct _PROCESS_INFORMATION { HANDLE hProcess; HANDLE hThread; DWORD dwProcessId; DWORD dwThreadId; } PROCESS_INFORMATION; I don't see any clear way of doing, 1. Converting the above structure into something usable, eg. MSVCRT_FILE 2. Actually allowing us to read or write to the application Potentially the magic lies in the current Wine CreateProcess implementation, I'll have a look at it. Is doing this really feasable using the CreateProcess family? In essence a HANDLE will map back to an fd with the wine implementation (rather we can get an fd for a HANDLE), but can this be used to read/write to the process? The first obstacle however, will be in having a clean way to get wcmd going if it doesn't reside in C:\. Maybe it should be there and should be installed like notepad.exe for example? Some questions, and yes I'm slow tonight... :) I think that just by typing this some concerns have been aleviated so excuse my rumblings but just check the logic. Greetings, Jaco

4 4

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by Jaco Greeff 01 Nov '02

01 Nov '02

On Fri, 1 Nov 2002 20:50:07 +0100, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote : > Giving a fully qualified patch is probably bad advice here. Try "wcmd.exe" > only and have cmd.exe.so in wine's program directory. Wine sets on startup > WINEDLLPATH to "$topdir/dlls:$topdir/programs" and wineapploader there > should manage to start the application. Umm, that might help a bit. When I get to the point of testing again, I'll give it a bash. What seems to be the concensus as to the "right-way-to-do-things(tm)" in this case? Greetings, Jaco

1 0

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by Jaco Greeff 01 Nov '02

01 Nov '02

On Fri, 1 Nov 2002 11:21:26 -0800 (PST), Francois Gouget <fgouget(a)free.fr> wrote : > Try c:\Windows\System\wcmd.exe and I think you will find that it works. *lol* Like I've said, expect me to be slow tonight :)

1 0

Wine securityflaw.
by Peter Andersson 01 Nov '02

01 Nov '02

Hello again, (FYI, I took the liberty to change the topic since I started the former thread "How is Win/Dos syscalls implemented in Wine?" which I feel has gone a little bit off-topic) I had some more thoughts on the issue... I believe most wine users trust wine not to touch anything outside of its configured drive space. Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage. After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected. The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt. I really love the idea of Wine, and the fact that its working good and rather stable now does mean its gaining popularity and a broader user base, which further IMHO accelerates the wine movement. If wine users were aware of the risks of using wine at present, I believe wine would be used more cautiously. Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens. I do think company policy decissions againt using wine, will do just as much damage to the wine movement as too the free software movement at large. I would, despite my current lack of knowledge, gladly offer my help. But I hope someone more experienced would take the lead. Best Regards, Peter Andersson

18 35

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by Jaco Greeff 01 Nov '02

01 Nov '02

On 01 Nov 2002 08:40:20 -0800, Alexandre Julliard <julliard(a)winehq.com> wrote : > Jaco Greeff <jaco(a)puxedo.org> writes: > > > 1. Calling the popen function returns a FILE* which needs to be > > converted to a MSVCRT_FILE*. The apprach taken here is potentially not > > the best route but the only one I could think of. Is it suffiecient? > > No, it's wrong. You should be using the Windows API (CreateProcess > etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE. I was actually taking a re-look at that this afternoon. I agree, the initial reason for th implementation was obviously that _popen is supposed to mimic popen, but the file conversion leaves me feeling really uncomfortable. I'll fix it up and submit it shortly. Greetings, Jaco

1 0

Re: Treeview notifications before Guy's patch problem
by Dustin Navea 01 Nov '02

01 Nov '02

--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > On November 1, 2002 02:00 am, you wrote: > > after banging my head on my keyboard for a few minutes > > because i couldnt find treeview_notifyformat i went and looked at cvsweb > > and found out...there is no treeview_notifyformat before guy's patch so > > there is no way for me to get that kind of a debug output... > > Good find. Please add this to Bugzilla. But it presents a big problem: > if we behave correctly, we break the app. What do we do? > I'm wondering if maybe its my app thats broken already and thats why its sending the unicode message.. ---appended--- Maybe Alexandre should look at this too? Appended notes to bug 1073. Does anyone reading this have any ideas on any kind of hack that wont completely break every other app while still fixing this one? __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

1 0

What does "Printer: Wine Poscript Driver, Error: 709" mean
by David.Goodenough＠DGA.co.uk 01 Nov '02

01 Nov '02

I installed a program called Mind Manager, and tried to run it. It installed OK, but when I came to run it the initial dialog came up and it was totally unresponsive to either keyboard or mouse. So I looked around the system for any errors and found that the title of the window in the KDE window list was as shown above. Anyone got any ideas what error 709 means? Thanks in advance David

1 0

Re: dlls/msvcrt: process.c (msvcrt-popen-1)
by Alexandre Julliard 01 Nov '02

01 Nov '02

Jaco Greeff <jaco(a)puxedo.org> writes: > 1. Calling the popen function returns a FILE* which needs to be > converted to a MSVCRT_FILE*. The apprach taken here is potentially not > the best route but the only one I could think of. Is it suffiecient? No, it's wrong. You should be using the Windows API (CreateProcess etc.) not the Unix popen(). Then you can build a proper MSVCRT_FILE. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: dlls/msvcrt: msvcrt-popen-1.1
by Joerg Mayer 01 Nov '02

01 Nov '02

On Fri, Nov 01, 2002 at 03:16:58PM +0200, Jaco Greeff wrote: > +/* FIXME: Don't know what this value should be, 10 seems enough as > + * the maximum number of simultaneous _popen'ed processes > + */ > #define POPEN_MAX_FILES 10 ... > +INT POPEN_getOpenFileSlotPos(VOID) > +{ > + INT i = 0; > + for (i = 0; i < POPEN_MAX_FILES; i++) > + { > + if (!POPEN_Files[i].fProcess) > + { > + POPEN_Files[i].fProcess = (MSVCRT_FILE *)POPEN_FILE_IN_USE; > + return i; > + } > + } Please output an ERR here to ask people to report that POPEN_MAX_FILES needs to be increased. > + return -1;

2 1

RE: Wine 0.8 TODO v0.1
by Patrik Stridvall 01 Nov '02

01 Nov '02

> Oh, one other thing that would be nice, while I think of > it... is there > any reason (now we are GPL'ed) that we cannot incorperate cabextract > (http://www.kyz.uklinux.net/cabextract.php3) into Wine? Because we are not GPL:ed. We are LGPL:ed. Application that go under programs/ might as an exception go under GPL. However in the case of cabextract we need substantial parts of it to implement functions like SetupIterateCabinet in SETUPAPI.DLL so only the LGPL or less restrictive is acceptable. However the author(s) of cabextract might agree to release the parts we need under the LGPL. Perhaps it better if he release it all under the GPL since we might want to implement the CAB SDK tools like cabarc.exe that is supposed to do almost exactly what cabextract does (and possibly more) AFAICS. What don't you ask him? > Currently we shell out to it as an external program, Do we? Hmm. OK, it seems we do in dlls/urlmon/umon.c. Ugly. That code should probably call SetupIterateCabinet instead. Of course that function is not implemented yet. See above. > in order to run > Microsoft's setup APIs ecetra. This is really annoying for > new users, as > unless they look closely at pages of logs... theres no real indication > that's why installation of a Microsoft program failed. True.

1 0

Tucows top-100 applications :)
by Carlos Lozano 01 Nov '02

01 Nov '02

Hello, It is today top 100 tucows list. I think that it shouldn't be the better wine top 100 list, some entries should be removed, and some new added. (For example some cdrecord program). Regards, Carlos. -- ___ _ \ | / Infraestructuras | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.epsxe.com

2 1

What is a leap second
by György 'Nog' Jeney 01 Nov '02

01 Nov '02

While I was looking through dlls/ntdll/time.c I came across the following two comments: "FIXME: Compute the number of leap second corrections here" and "FIXME: get the GMT offset here" What do these mean? nog.

4 9

Status of libwine MFC and msvcrt compilation
by Uwe Bonnes 01 Nov '02

01 Nov '02

Hallo, what is the status of winelib compilation of MFC and msvcrt? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Versions & mass-appeal
by Dimitrie O. Paun 01 Nov '02

01 Nov '02

People, I think everybody here agrees that Wine's biggest problem is the lack of developers. No developers, slow progress, no users, back to no developers. We are in this vicious circle for a while, spinning our wheels like crazy. We've achieved great progress lately, but I hope we all agree that Wine is a vast project that can succeed only with a mass appeal similar to the fueling the development of the Linux Kernel. Why are we in this position? For reasons I will not go into right now, it seems painfully obvious to me that we are suffering from a severe case of Bad Public Image (tm). Whenever I talk to people not intimately familiar with Wine, about our beloved project, I am _always_ treated with the same reaction: a surprised "Really, it works? Hmmm, I thought it was only running Freecell...". Translation: people consider Wine a huge hack that can run (by some strange happenings) some apps, sometimes. It is viewed as unreliable, "freak of nature sideshow"; something (maybe) cool to talk about, but utterly useless. THIS IS OUR PROBLEM. The lack of users follows trivially. We know the above opinion is not true. *I* get constantly amazed by how much progress we've made. Something must be done, and I think there is something to be done. How do we change this state of affairs? Well, people need major events to reevaluate their opinions. Being major, they are by definition few, and so we don't have too many chances. For Wine, these events are the upcoming x.y releases. What I'm trying to say is that we have to prepare properly for them. Here's my concrete proposal for releases: 0.8.x : Wine is usable, we don't guarantee binary compatibility 0.9.x : Wine is usable, and we kinda guarantee binary compatibility 1.0.x : Wine is quite usable, we guarantee binary compatibility I'll define these things more precisely later, but before that, let me explain why we should introduce the 0.8.x series: -- a chance to attract more users into the fold -- Wine is approaching that stage fast -- it's a logical, interim step to 0.9 -- will help us focus Whatever the reason, it's a _logical_ step that we must go through in our journey to 0.9, and from a user's perspective, it makes sense to make it public. There's no point in robbing us of the userbase for a abstract techy goal of binary compatibility. That's the next stage. Criteria for these releases: 0.8.0 -- Wine runs several popular apps well (we're close) -- Web site is updated (e.g. Who's Who, etc) -- Existing docs are up-to-date -- Utilities are close to final form (winebuild, etc.) 0.9.0 -- DLL separation complete -- Server protocol complete 1.0.0 -- Major bugs squashed -- Flawless UI -- Complete docs I'll leave it at that. Comments, flames? -- Dimi.

18 45

Getting actively involved in the Wine project
by Thomas Wickline 01 Nov '02

01 Nov '02

From the page: ----- PR manager Currently we almost have no Public Relationship management at all. This should change for the better. Currently almost the only form of PR is "preaching to the choir", since we're having articles on online IT sites (by far most are Linux only !). We should have much more coverage on traditional Windowsish sites and, most importantly, in dead-tree newspapers, to enlighten the general public also known as The Great Unwashed Masses ! ----- Wine users , CodeWeavers & WineX customers could do Previews/Demo's at there local lug meetings as well.. This is what I did a couple months back and it was a huge success there were Windows users at the meeting to see Linux and Win app's being run on Linux ... Also it gives Linux users a look at wine as well. So I suggest that we try to encourage wine users to volinteer to show Wine at there local user groups/Installfest/Computer shows and so on. This is not a PR manager but it is PR...... Tom

3 3

Re: RFC: msvcrt _popen/_wpopen/_pclose
by chrismorgan＠rcn.com 01 Nov '02

01 Nov '02

What is wrong with using wcmd and extending it if necessary? Chris > > From: "Jaco Greeff" <jaco(a)puxedo.org> > Date: 2002/10/31 Thu PM 04:27:43 EST > To: wine-devel(a)winehq.com > Subject: RFC: msvcrt _popen/_wpopen/_pclose > > Hi, > > I want some comments on the possibility of a _popen/_wpopen/_pclose > implementation in Wine. Reference available at: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html… > > The open functions basically operate in the same way as the popen function > in Linux, ie. it spawns a process with the command via the command > interpreter. Now, unfortionately we don't have our won cmd.exe available, > but should people really need this functionality it might not be too much to > ask as to copy it from a working Windows installation. > > In my mind, supporting the Win 95/98 command interpreters might be a > nightmare - my gutt feel is that these two rely too much on DOS internals to > be sucessfully launched via Wine. No, I haven't tried it, so I might be > completely wrong. Either way, something like this might be better > implemented via the Win NT/2000/XP cmd.exe. (I'll test my assumptions > tomorrow, I don't have access to the command interpreters tonight.) > > I've hacked (yes, it was quick) a potential implementation of the _popen > family of functions. (Haven't compiled, haven't tested, this is just and RFC > - if it can work, I'll spend some real time on it.) Anyway, here it is, > comments appreciated: > > --[ inline-ish RFC ]---- > > #include "config.h" > #include "wine/port.h" > > #include <stdio.h> > #include <stdlib.h> > #ifdef HAVE_UNISTD_H > # include <unistd.h> > #endif > > #include "winbase.h" > #include "winnls.h" > #include "wine/unicode.h" > #include "msvcrt/stdio.h" > #include "msvcrt/string.h" > > #include "wine/debug.h" > > #define POPEN_FLAG_READ 0x0001 > #define POPEN_FLAG_WRITE 0x0002 > #define POPEN_FLAG_TEXT 0x0004 > #define POPEN_FLAG_BINARY 0x0008 > > inline CHAR *LPCWSTRToLPSTR(const LPCWSTR lpwstrIn, INT nIn) > { > INT nLen = WideCharToMultiByte(CP_ACP, 0, lpwszIn, nIn, NULL, 0, NULL, > NULL); > CHAR *szOut = (CHAR *)malloc((nLen+1)*sizeof(CHAR)); > if (szOut) > { > WideCharToMultiByte(CP_ACP, 0, lpwszIn, nIn, szOut, nLen+1, NULL, NULL); > szOut[nLen] = '\0'; > } > return szOut; > } > > INT POPEN_parseModeFlags(const CHAR *szMode) > { > INT nFlags = 0; > while (szMode && *szMode) > { > switch (*szMode) > { > case 'r': > { > if (nFlags & POPEN_FLAG_WRITE) > WARN(": _popen: Cannot set both read and write open > flags, ignoring read flag\n"); > else > nFlags = nFlags & POPEN_FLAG_READ; > break; > } > case 'w': > { > if (nFlags & POPEN_FLAG_READ) > WARN(": _popen: Cannot set both read and write open > flags, ignoring write flag\n"); > else > nFlags = nFlags & POPEN_FLAG_WRITE; > break; > } > case 'b': > case 't': > { > FIXME(": _popen: %c mode flag not implemented, ignoring\n", > *szMode); > break; > } > default: > { > WARN(": _popen: unknown mode flag %c, ignoring\n", *szMode); > break; > } > } > } > return nFlags; > } > > MSVCRT_FILE *MSVCRT_popen(const CHAR *szCommand, const CHAR *szMode) > { > MSVCRT_FILE *fProcess = NULL; > > if (!szCommand || !szMode) > return NULL; > > INT nFlags = POPEN_parseModeFlags(szMode); > if (!(nFlags & (POPEN_FLAG_READ|POPEN_FLAG_WRITE))) > { > ERR("No open mode flag r or w specified\n"); > return NULL; > } > > /* _popen/_wpopen executes the required command via the command > * processor, either command.com (Win 95/98) or cmd.exe (Win NT/2000/XP). > * Wine does not currently have it's own "cmd.exe" hence we cannot > * really do anything more at this point. However, we try to lauch it > * and hope for the best... > */ > CHAR *szExec = (CHAR *)malloc(strlen("wine -- C:/cmd.exe -C > ")+strlen(szCommand)+1); > if (szExec) > { > sprintf(szExec, "wine -- C:/cmd.exe -C %s", szCommand); > fProcess = popen(szExec, (nFlags & POPEN_FLAG_READ) ? "r" : "w"); > if (!fProcess) > ERR("Execution of C:/cmd.exe via wine failed\n"); > else > WARN("Launch of %s succeeded, no guarentees of success made\n", > debugstr_a(szExec)); > free(szExec); > } > > return fProcess; > } > > MSVCRT_FILE *MSVCRT_wpopen(const WCHAR *wszCommand, const WCHAR *wszMode) > { > MSVCRT_FILE *fProcess = NULL; > > if (!wszCommand || !wszMode) > return NULL; > > CHAR *szCommand = LPCWSTRToLPSTR(wszCommand, strlenW(wszCommand)); > if (szCommand) > { > CHAR *szMode = LPCWSTRToLPSTR(wszMode, strlenW(wszMode)); > if (szMode) > { > fProcess = _popen(szCommand, szMode); > free(szMode); > free(szCommand); > } > free(szCommand); > } > > return fProcess; > } > > int MSVCRT_pclose(MSVCRT_FILE *fProcess) > { > if (!fProcess) > return -1; > return pclose(fProcess); > } > > > >

2 2

So lets say we do it
by Dimitrie O. Paun 01 Nov '02

01 Nov '02

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. 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! So let's assume that by a miracle they'll discover the screenshots: do they make them drool? No, we loose another 15%. 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. 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 #@$%! *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. (Don't even mention app-db, it's *way* too complicated!) 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... -- Dimi. P.S. A story-like TODO (with embedded rationale) for 0.8.0 :)

10 27

Re: Treeview notifications
by Dustin Navea 01 Nov '02

01 Nov '02

--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > Dustin, Adrian, can you please try this one, and let me > know if it fixes your problems? > > ChangeLog > Fix some treeview notification codes between ANSI/Unicode mode. > Another sidenote... in TREEVIEW_NotifyFormat shouldnt (lParam == NF_REQUERY) be (lParam == NF_QUERY) and change the corresponding line in TREEVIEW_Create since that is the original query? I have already searched throughout the sources and the only place that TREEVIEW_NotifyFormat is called is in treeview.c in TREEVIEW_Create ... -Dustin __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

2 1

Re: I suck...
by Dimitrie O. Paun 01 Nov '02

01 Nov '02

On October 31, 2002 08:17 pm, Greg Turner wrote: > Inlined for your viewing pleasure. Cool, thanks! :) -- Dimi.

1 0

Re: Treeview notifications
by Dustin Navea 01 Nov '02

01 Nov '02

Unfortunately, no it didnt fix the problem. :( -Dustin --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > Dustin, Adrian, can you please try this one, and let me > know if it fixes your problems? > > ChangeLog > Fix some treeview notification codes between ANSI/Unicode mode. > __________________________________________________ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/

1 0

Re: So lets say we do it
by John K. Hohm 01 Nov '02

01 Nov '02

> Once we have that we need to make sure we have suitable defaults to > allow running at least the drives/paths control panel without registry > files at all. We also need the Wine dlls to register themselves > instead of having to merge winedefault.reg by hand. Then it should be > possible to write a .inf script to setup a new Wine install > automatically from scratch. Once upon a time (well okay, in July) I said I would make the Wine dlls self-registerable, and now I've gone and created bug #1117 to remind me to do it. I plan to use the (mostly-)static-array-driven, dumb but generic, regsvr_register and regsvr_unregister functions that are currently situated in dlls/comcat. I don't like the idea of copying around exact duplicates of regsvr.[hc], but they seem too small to put in their own libwine_regsvr.so; what do you recommend?

1 0

Re: wine/dlls/rpcrt4 ndr_marshall.c
by Greg Turner 01 Nov '02

01 Nov '02

On Thursday 31 October 2002 07:47 pm, Alexandre Julliard wrote: > Fix stupid clone of broken macro, found by Marcus. On Thursday 31 October 2002 07:17 pm, I wrote: > - fix stupid clone of broken macro, found by Alexandre. sheesh! I can't even get the fixer's fixed. oh well :( Like I said in the patch subject, I suck... -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

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