Re: Unscientific test: wine is 0 for 3 on under $20 top sellers

/show_bug.cgi?id=6528 > Crazy Machines aborts silently on startup Kids games are hugely problematic in Wine - offhand I can't think of one that has worked. Even if they install they often won't run. Even if they run they often won't display correctly, or will have input problems. -- Troy Rollo - [EMAIL PROTECTED]

Re: Patchwork (was Re: Governance revisited)

On Thursday 28 September 2006 05:49, Mike McCormack wrote: > Seems like that is a system that doesn't scale well at all, as it > requires Alexandre to specifically respond to each and every patch. He still has to take an action to review each patch now, and presumably some action to remove it fr

Re: Patchwork (was Re: Governance revisited)

On Thursday 28 September 2006 05:49, Mike McCormack wrote: > Seems like that is a system that doesn't scale well at all, as it > requires Alexandre to specifically respond to each and every patch. He still has to take an action to review each patch now, and presumably some action to remove it fr

Re: Patchwork (was Re: Governance revisited)

On Tuesday 26 September 2006 22:55, Jeremy White wrote: > 1. We can write a utility that lets us compare a winehq commit > message to a wine-patches email and see if there is a 'match'. > 100% isn't required, but some nice non zero number is. > > A key requirement is t

Re: Tips for vim users

On Tuesday 26 September 2006 09:34, Troy Rollo wrote: > On Monday 25 September 2006 19:47, n0dalus wrote: > > At the bottom of my ~/.vimrc (create it if it doesn't exist): > > if !exists("loaded_vimrc_autocmd") > > let loaded_vimrc_autocmd=1 > > a

Patchwork (was Re: Governance revisited)

ainers are the critical pressure-point. -- Troy Rollo - [EMAIL PROTECTED]

Re: Governance revisited

would also result in some lag between updates to Wine and updates to the merged tree. -- Troy Rollo - [EMAIL PROTECTED]

Re: Tips for vim users

p=4 > endif You might want to add "shiftwidth=4" so autoindent works correctly. -- Troy Rollo - [EMAIL PROTECTED]

Re: Governance revisited (Wineconf report)

be better to ask them than to speculate? (query sent) It may well be that the PPC64 project was merged into the PPC one, which is seemingly more up to date: <http://patchwork.ozlabs.org/> -- Troy Rollo - [EMAIL PROTECTED]

Re: Governance revisited

Now in the case of Ge where he was patching core functions of > ntdll,kernel32,wineserver,etc I guess it would still fall to julliard to > reply personally but in the case of other modules It's also remains a haphazard process where things can (and so will) fall through the cracks. -- Troy Rollo - [EMAIL PROTECTED]

Re: Governance revisited

elopment: > the need to compete, and show that you can do it better than the other > guy. This is something that abates with maturity... at least for people who don't get stuck in a One True View Of The World mind-set. > Bottom line, I don't know. At most I can say that sometimes I wish > Alexandre would be a bit more impulsive, and just let (a selected few) > things in that people want. I don't think this is necessary, at least -- Troy Rollo - [EMAIL PROTECTED]

Re: Governance revisited (Wineconf report)

t time a new contributor submits something to wine-patches (or even to existing contributors when there have been changes to the guidelines). -- Troy Rollo - [EMAIL PROTECTED]

Re: Governance revisited (Wineconf report)

is often a larger design element involved than Win32 were you are just trying to find the best way to implement the same functionality Windows has. -- Troy Rollo - [EMAIL PROTECTED]

Re: How to use a windows dll in linux

ils. I suspect the "difficulty" associated with having a Linux executable that calls Windows DLLs using Wine has been due the assumption that "main()" in the executable would be executed before Wine - by throwing out this assumption the problem may be a whole lot easier to solve. -- Troy Rollo - [EMAIL PROTECTED]

Re: DIB Engine

ting Alexandre to accept it, and considering the amount of work involved you *really* want to be certain it's going to be accepted before doing it. -- Troy Rollo - [EMAIL PROTECTED]

Default background erase code does not respect WM_CLIPSIBLINGS

. This looks like one of those cases where there are probably a lot of wrong ways to fix it and only one right way, and so needs to be fixed by somebody familiar with the code involved. -- Troy Rollo - [EMAIL PROTECTED] #define STRICT #include #include static HINSTANCE hInst; static HWND

Re: LOSTWAGES: Replace references to CVS with Git

ided you are asking something not already answered in the Wiki you'll normally get a response and the Wiki will be adjusted accordingly. -- Troy Rollo - [EMAIL PROTECTED]

Re: winnt32.exe on AMD64

directly, however the languages that would be inputs to the code generators are largely already defined (IDL and Wine's spec files). No doubt it would be easier to wait for gcc to support the Win64 calling convention, but that is not the only option. -- Troy Rollo - [EMAIL PROTECTED]

Re: winnt32.exe on AMD64

ld not need to go through the thunks. Many of the issues involved have already been dealt with for 16<->32 thunking and cross-process COM calls. It's not ideal, but it should be possible. -- Troy Rollo - [EMAIL PROTECTED]

Re: winnt32.exe on AMD64

vailable (plus I think Alexandre still wants compiler-neutrality as far as is possible). -- Troy Rollo - [EMAIL PROTECTED]

Re: git annoyances: how to force git to fetch a particular file

ve made changes in the working copy but need to revert it to what is in the repository (equivalent to svn revert): git checkout HEAD file-name -- Troy Rollo - [EMAIL PROTECTED]

Re: Slow EULA display patch

On Saturday 01 July 2006 15:59, Krzysztof Foltman wrote: > Well, *great* to see that solved in the Wine core, but I still think I > have a bug in RichEdit, because the original (native) riched20 works > fast, despite the bug you just fixed. All that means is that the native rich edit control doesn

Re: wine autorun utility

seeks to provide. Only once the native Windows executable has been identified as the only (or best) target for autorun would Wine become involved, when the program in the desktop environment invoked Wine to run the executable. -- Troy Rollo - [EMAIL PROTECTED]

Re: wine autorun utility

ronment, but a developer should. Wine is for making Windows applications (and native applications coded to the Windows API) run - I am not aware of any developer who thinks it should be a complete reimplementation of Windows. -- Troy Rollo - [EMAIL PROTECTED]

Re: urlmon: Implement URLDownloadToCacheFile

oned in the cache index. You should be calling CreateUrlCacheEntryW to get the file name for the new file. -- Troy Rollo - [EMAIL PROTECTED]

Re: Wine developers?

On Wednesday 28 June 2006 02:11, Mike Hearn wrote: > On Mon, 26 Jun 2006 08:27:10 +1000, Troy Rollo wrote: > > On Friday 23 June 2006 22:50, Mike Hearn wrote: > >> careful, none of us are lawyers here. > > > > That's not entirely true. > > We have IP lawye

Re: Wine developers?

On Friday 23 June 2006 22:50, Mike Hearn wrote: > A very specific legal interpretation that would require the > company behind Thinstall to want to hurt the Wine project be careful, > none of us are lawyers here. That's not entirely true. -- Troy Rollo - [EMAIL PROTECTED]

Very large fonts cause loss of connection to X server

t thing is just not to upload the glyph but mark it internally as having been uploaded. Presumably that will prevent the loss of connection without breaking WYSIWYG display strategies that involve calculating positions using large fonts in a screen DC. -- Troy Rollo - [EMAIL PROTECTED]

Re: Fonts getting corrupted in x11drv

On Thursday 25 May 2006 20:51, Saulius Krasuckas wrote: > BTW, now the issue is seen on my box too. Heh, it reminds my of my own > bugreport [*]. Could this be related, Troy? > > > [*] http://bugs.winehq.org/show_bug.cgi?id=5248 No, your problem is definitely different. -- Troy

Re: Fonts getting corrupted in x11drv

On Thursday 25 May 2006 19:47, Huw Davies wrote: > Nice catch! This should fix it. Indeed it does. -- Troy Rollo - [EMAIL PROTECTED]

Fonts getting corrupted in x11drv

e a horrible hack. Perhaps find_in_cache should only return bitmap fonts if the device can use them. If the caller then finds there is no bitmap font that matches it can then look for scalable fonts in the cache. -- Troy Rollo - [EMAIL PROTECTED] #define STRICT #include #include #include

Re: Bug ownership question

d to the bug at <http://bugs.winehq.org/show_bug.cgi?id=5285> it may be that nothing needs to be changed. You may get better results by asking about it on this list rather than in bugzilla. -- Troy Rollo - [EMAIL PROTECTED]

Re: Programatically minimising window gets incorrect results.

This modified hack fixes both cases, but presumably is going to break unmanaged windows. -- Troy Rollo - [EMAIL PROTECTED] diff --git a/dlls/x11drv/window.c b/dlls/x11drv/window.c diff --git a/dlls/x11drv/winpos.c b/dlls/x11drv/winpos.c index 5fdde83..f164b00 100644 --- a/dlls/x11drv/winpos.c

Re: Programatically minimising window gets incorrect results.

ves the same results as mine (mine just stopped X11DRV_ShowWindow from doing extra stuff after XIconifyWindow). -- Troy Rollo - [EMAIL PROTECTED]

Programatically minimising window gets incorrect results.

window yet. -- Troy Rollo - [EMAIL PROTECTED] #define STRICT #include #include LRESULT WINAPI WndProc( HWND hWnd, UINT wMsg, WPARAM wParam, LPARAM lParam) { switch(wMsg) { case WM_LBUTTONDOWN: ShowWindow(hWnd, SW_SHOWMINIMIZED); return 0; case WM_RBUTTONDOWN: ShowWindow(hWnd

Re: World of Warcraft (WoW) patch/more address space layout stuff

nowledge of allocated space. If the allocation fails because something is mapped there already we would display a FIXME and then use a search algorithm to identify the allocated block (or grovel at /proc, but Alexandre has indicated before he prefers not to do that). -- Troy Rollo - [EMAIL PROTECTED]

Re: sfd2ttf

of the final TTF file, with a Wine internal tool written to compile that to TTF and another to convert the original TTF to that format. -- Troy Rollo - [EMAIL PROTECTED]

Re: SOC: Integrate DIB Engine

are familiar with all of the integer-only algorithms for drawing graphics primitives or have a good text book handy that has all the algorithms in it. -- Troy Rollo - [EMAIL PROTECTED]

Re: Coverity doing scans of Wine codebase!

double-check the decision or to fix the bug. -- Troy Rollo - [EMAIL PROTECTED]

Re: Coverity doing scans of Wine codebase!

r keep the extra-defensive code? -- Troy Rollo - [EMAIL PROTECTED]

Re: Invisible fonts regression

e willing to just say "20051205 or higher" somebody will have to figure out which of those is the first viable version. -- Troy Rollo - [EMAIL PROTECTED]

Re: Invisible fonts regression

On Thursday 06 April 2006 12:31, Troy Rollo wrote: > On Thursday 06 April 2006 11:06, Tom Spear (Dustin Booker, Dustin Navea) > > wrote: > > I dont know if this will help, but it is worth a shot... Install > > fontforge from fontforge.sourceforge.net > > Actually it

Re: Invisible fonts regression

/share/wine/fonts or making it inaccessible. -- Troy Rollo - [EMAIL PROTECTED]

Re: richedit20: Implement EM_FORMATRANGE

is not worth worrying about. -- Troy Rollo - [EMAIL PROTECTED]

Re: Update on Software Freedom Law Center work

On Monday 03 April 2006 11:46, Jan Zerebecki wrote: > On Mon, Apr 03, 2006 at 09:58:26AM +1000, Troy Rollo wrote: > Is there a case possible where neither can be constructed without > hassle? Think something like: insurance against GPL violators. The insurance company has to b

Re: Update on Software Freedom Law Center work

ountry is a different legal right. Even if a document purports to assign worldwide copyrights, if it is not in the form required by the law of some countries, then the original copyright holder will retain copyright in those countries. -- Troy Rollo - [EMAIL PROTECTED]

Re: Improper message recursion revealed by recent desktop window changes

by the earlier one. I will investigate further. -- Troy Rollo - [EMAIL PROTECTED]

Improper message recursion revealed by recent desktop window changes

ication work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to change I thought it best left to people with more familiarity with it. -- Troy Rollo - [EMAIL PROTECTED]

New Linux System calls (*at) in 2.6.16

stem calls but take a file descriptor for a directory that becomes the base point for relative paths. -- Troy Rollo - [EMAIL PROTECTED]

Re: Question about copyright lines

nt future users of materials in identifying when a work enters the public domain. -- Troy Rollo - [EMAIL PROTECTED]

Re: Winelib

it only involved libraries, nobody links to static libraries anymore so you would still need external libraries. -- Troy Rollo - [EMAIL PROTECTED]

Re: Possibly crazy idea to deal with memory layout problems once and for all

On Saturday 18 February 2006 22:47, Mike McCormack wrote: > It has a few problems though. Firstly, we'd miss mmaps done with system > calls. Yes, but how many apps actually do this? > Secondly, we'd have to make assumptions about what areas of > memory the kernel would let us map, and what are

Re: Possibly crazy idea to deal with memory layout problems once and for all

On Saturday 18 February 2006 15:21, Vitaliy Margolen wrote: > more specific about what is the real problem here? From what I know this > patch is to fix WoW (Blizard's bad assumption about place where memory > will be allocated). And possible few other games (that make the same > exact assumption).

Possibly crazy idea to deal with memory layout problems once and for all

I have been looking at a problem that has arisen in recent versions, particularly when using some D3D games, in which the virtual address space above TASK_UNMAPPED_BASE becomes fragmented to the extent that eventually you get an out of memory condition, even though you still have well over a gi

Re: user: Fix return type of GetDlgItemText{A,W}

On Tuesday 14 February 2006 11:59, Troy Rollo wrote: > ChangeLog: > user: Fix return type of GetDlgItemText{A,W} Please disregard this one - the argument types are wrong too. I will follow up with a consolidated patch fixing both -- Troy Rollo - [EMAIL PROTECTED]

Re: Implement DVD_ReadStructure

be an acceptable state. Now excuse me while I update my filters to take account of your new email address. -- Troy Rollo - [EMAIL PROTECTED]

Re: Implement DVD_ReadStructure

On Thursday 09 February 2006 00:28, Detlef Riekenberg wrote: > Am Sonntag, den 05.02.2006, 22:01 +1100 schrieb Troy Rollo: > > ChangeLog: > > Implement DVD_ReadStructure > > > > --- /dev/null 2006-02-03 18:20:42.451563144 +1100 > > +++ wine-git/in

Regression caused by "ntdll: Check file size when mapping image sections to avoid SIGBUS errors."

f (map_file_into_view( view, fd, 0, header_size, 0, VPROT_COMMITTED | ... This change prevents Wine from loading Win32 executables that are less than 64K long. header_size is 65536, but st.st_size is less than that. -- Troy Rollo - [EMAIL PROTECTED]

Re: Question regarding the Wine Vs WineLib performance

commercial use, and a free download for non-commercial (which by Intel's definitions means only developers who are not being paid) use. -- Troy Rollo - [EMAIL PROTECTED]

Re: Licensing question

n reveals about deficiencies in the documentation). -- Troy Rollo - [EMAIL PROTECTED]

Re: SPARC assembly won't compile, problems with NT headers

calculate the whole thing at load time. -- Troy Rollo - [EMAIL PROTECTED]

Re: SPARC assembly won't compile, problems with NT headers

On Fri, 23 Dec 2005 19:18, Alexandre Julliard wrote: > Troy Rollo <[EMAIL PROTECTED]> writes: > > This will work if (and only if) the value of SizeOfImage is unimportant > > for Winelib executables. Of course in that case there is probably some > > merit in setting it to

Re: URLMON: Removed not used code.

es you have removed are there for whoever eventually completes the implementation to build on. I am also not sure why you think the INTERNET_SCHEME_FILE case is unused. -- Troy Rollo - [EMAIL PROTECTED]

Re: SPARC assembly won't compile, problems with NT headers

t for Winelib executables. Of course in that case there is probably some merit in setting it to zero anyway since at least that would make it obvious that it has no meaningful value if somebody reads it later. -- Troy Rollo - [EMAIL PROTECTED]

SPARC assembly won't compile, problems with NT headers

his location and have winegcc modify the executable image to insert the correct values after the linker has created it. Does anybody have any objections to this solution or another approach to suggest? -- Troy Rollo - [EMAIL PROTECTED]

Re: has the LGPL licence fell through ?

tlement. A person who has copyright in the code has to then take enforcement action for breach of copyright and breach of contract in order to enforce it. If a person with copyright in the code receives the compiled code, then the rights are, more conveniently, coincident in the same person. -- Troy Rollo - [EMAIL PROTECTED]

Re: has the LGPL licence fell through ?

rence do you expect that to make? > If your wondering why I'm ranting : > http://news.inq7.net/infotech/index.php?index=1&story_id=60585 What version of Wine is their stuff based on? -- Troy Rollo - [EMAIL PROTECTED]

Re: wine command is not working in crontab

On Sat, 19 Nov 2005 06:37, Paul Millar wrote: > I used to use Xvfb (from XFree86) as the (virtual) frame-buffer device and > have some scripts to support that. Unfortunately, that had a nasty habit > of crashing whenever one tried any openGL/glx stuff and the XF86 people > weren't interested in fi

Re: GetOpenFileNameA has trouble with UTF-8 locale and UTF-8 encoded pathname

On Tue, 22 Nov 2005 19:35, Michael Jung wrote: > Are you saying that on an asian system CP_ACP is actually a double byte > encoding? Is anybody on the list using an asian locale on her system? Does > it break the unixfs extension? The Chinese, Japanese and Korean code pages ( 932, 936, 949 and 95

Re: GetOpenFileNameA has trouble with UTF-8 locale and UTF-8 encoded pathname

On Tue, 22 Nov 2005 06:54, Alexandre Julliard wrote: > 2) is the right behavior. The A functions always return strings in the > Ansi codepage, not in the Unix one. There is no Windows locale that > uses UTF-8 as Ansi codepage, so if a UTF-8 string is returned to the > application that's a bug. Thi

Unix Path APIs implementation available

An implementation of UNIX path APIs is available from: svn://troy.wine-branches.troy.rollo.name/troy/branches/unix-path-apis This is an SVK branch, so if you use SVK you will be able to merge it into your own branch. The implementation is also merged into the following trunks: s

Lockbox IPC implementation available - may be useful for wineserver "kernel" handles

A couple of years back I described an IPC mechanism called "Lock boxes" that might be useful for creating a faster wineserver. An implementation of this for Linux is now available:

Re: Help with WINE and POSIX threading

On Thu, 27 Oct 2005 22:19, Marcus Meissner wrote: > dlopen() is possible from within a WINE context. I don't believe this is true. LoadLibrary does a bunch of stuff dlopen won't - resolving imports, such as loading dependent DLLs and calling DLLEntry. While you can call dlopen, you must also cal

Re: wine / Linux kernel interaction

On Fri, 21 Oct 2005 15:20, Damjan Jovanovic wrote: > --- Troy Rollo <[EMAIL PROTECTED]> wrote: > > On Thu, 20 Oct 2005 17:15, Damjan Jovanovic wrote: > > > Because the scanner, like too many others, is > > > unsupported by SANE. > > > > Which scanner?

Re: wine / Linux kernel interaction and TWAIN

On Fri, 21 Oct 2005 12:12, Randall Walls wrote: > I own a HP scanjet 3570c that has no support under SANE, and I would > love to get it working. It comes with it's own graphics front end > program, but I have yet to get it working under wine. Actually it does, it's just that only two people have

Re: wine / Linux kernel interaction

On Thu, 20 Oct 2005 17:15, Damjan Jovanovic wrote: > Because the scanner, like too many others, is > unsupported by SANE. Which scanner?

Re: Linking wine *dll.so libraries with Linux applications ?!

>OK, then you will need to use the longjmp method. I missed a step... Before calling Win32 entry points (other than those in the Win32 kernel) you will need to call LoadLibrary on the library they are in. This will ensure that Wine has initialised anything in the library that needs to be init

Re: Linking wine *dll.so libraries with Linux applications ?!

On Thursday 20 October 2005 22:45, Alexander Efremov wrote: > The > architecture is somethink like > > |Linux Executable| --uses--> |Linux *.a and *.so libraries| + > > + |my Linux *.so library| --uses--> |Other Linux *.a and *.so > libraries + WineLib avifil32.dll.so| OK, then you will need to us

Re: Linking wine *dll.so libraries with Linux applications ?!

On Thu, 20 Oct 2005 13:12, Rob D wrote: > As a developer of several applications that need to run on Windows and > *nix, I am VERY interested in knowing more about the possible ways to > accomplish this, and would be more than willing to help update whatever > stuff is required. There is an old pa

Re: Linking wine *dll.so libraries with Linux applications ?!

On Thu, 20 Oct 2005 03:05, Vitaliy Margolen wrote: > Wednesday, October 19, 2005, 10:47:11 AM, Alexander Efremov wrote: > > Hello, > > > > is it possible to link Win32 Wine libraries (*.dll.so) with a Linux > > application. Suppose we have a simple Linux gcc program main.cc > > Yes. It is called wi

Re: DefDlgProc* broken for (at least) WM_GETTEXT

On Fri, 14 Oct 2005 07:19, Troy Rollo wrote: > On Thursday 13 October 2005 19:22, Alexandre Julliard wrote: > > It's probably easier to add a parallel set of CallDlgProc functions, > > especially since this will require fewer changes to the assembly > > thunks. > >

Re: DefDlgProc* broken for (at least) WM_GETTEXT

On Thursday 13 October 2005 19:22, Alexandre Julliard wrote: > It's probably easier to add a parallel set of CallDlgProc functions, > especially since this will require fewer changes to the assembly > thunks. I'll submit it both ways and you can pick one.

Re: DefDlgProc* broken for (at least) WM_GETTEXT

On Thursday 13 October 2005 18:24, Alexandre Julliard wrote: > Troy Rollo <[EMAIL PROTECTED]> writes: > > So, what I propose to do is: > > > > 1. make __wine_call_wndproc_32A and __wine_call_wndproc_32W static (and > > hence not exported) > > You can'

DefDlgProc* broken for (at least) WM_GETTEXT

The DefDlgProc16, DefDlgProcA and DefDlgProcW call CallWindowProc16, CallWindowProcA and CallWindowProcW to pass messages to the dialog procedures. The problem with this is that a dialog procedure is not a window procedure, despite having a similar signature. The dialog procedures return a BOOL

Re: Test If Running Under Wine

On Wed, 12 Oct 2005 10:41, cdr wrote: > This is naive and far from practical. To me, it's self-evident that an > application will want know which run-time OS it's running under for many > reasons; it's completely inappropriate for the run-time OS supplier to > discourage it from doing so. I would

Re: [comctl32] Fix SEGV in file dialogs (bug 3366)

On Wed, 12 Oct 2005 06:05, Alexandre Julliard wrote: > I think it would be a lot cleaner to put the IsWindow test in the > notify functions and make them return FALSE (or some appropriate code) > when the window is destroyed. Then all you have to do in the callers > is check the result instead of d

Re: Listview: refcount the infoPtr (Dropped patch)

On Tue, 27 Sep 2005 08:00, Dimi Paun wrote: > Do we need to do this for other controls too? > > ChangeLog > Add refcounting to the listview to support destroying of > the control from within notification messages. Th

Re: Wine CVS as of 9/25/2005 Kills Notes

On Tue, 27 Sep 2005 12:06, Kevin DeKorte wrote: > Actually I retested with a clean CVS build and setting usp10.dll to be > native and then running wine nlnotes it crashes with the following ... > fixme:uniscribe:ScriptCacheGetHeight 0xa60,0x61c0d0f0,0x4190ea8c > fixme:uniscribe:ScriptCacheGetHeight

Re: Wine CVS as of 9/25/2005 Kills Notes

On Tue, 27 Sep 2005 10:50, Kevin DeKorte wrote: > On Monday 26 September 2005 05:43 pm, Troy Rollo wrote: > > Does it work if you just delete usp10.dll.so from your > > /usr/local/lib/wine (or equivalent) directory? > > Yes OK, then a correct fix would involve implementing (

Re: Wine CVS as of 9/25/2005 Kills Notes

On Tue, 27 Sep 2005 08:53, Kevin DeKorte wrote: > Here is a patch that fixes the "Call from 0x4154ba5c to unimplemented > function usp10.dll.ScriptCacheGetHeight, aborting" Problem > > But it crashes now with this message Does it work if you just delete usp10.dll.so from your /usr/local/lib/wine

Re: appdb developers please read

On Thu, 8 Sep 2005 23:06, Francois Gouget wrote: > If it's something Alexandre uses to apply patches, then his requirement > that it be usable from his desktop environement (Emacs) precludes a > web-based system. Not really. A web based system could provide an alternative interface that allows fo

Re: Suggestions for improvement of the emulator

On Thu, 8 Sep 2005 04:42, Jeremy White wrote: > But the best way to persuade me (and others) of that is to highlight > the patches. Show me patches you've submitted, along > with arguments for them, and persuade me that he has > been wrong to refuse them. I said I wouldn't comment further, but I

Re: Suggestions for improvement of the emulator

The only reason I had not made some of these comments earlier was that I knew that they would not be well received, and that there would be at least some unconstructive responses. A prerequisite for having a productive discussion of this kind is being able to recognise the possible validity of a

Re: Suggestions for improvement of the emulator

On Tue, 6 Sep 2005 09:59, Ivan Leo Puoti wrote: > committed. Also I've recently noticed that very few of the patches being > submitted are being committed, mainly because Alexandre appears to be > *very* busy with some work (mac support maybe?), He may well be very busy with something else, but at

Re: Suggestions for improvement of the emulator

On Mon, 5 Sep 2005 20:30, Francois Gouget wrote: > What makes you say that? > What would need changing to efficiently accomodate more developpers? I should preface this by saying that I don't mean any criticism or offence by this. You asked the question and the following reflects my observation

Re: Suggestions for improvement of the emulator

On Mon, 5 Sep 2005 06:24, Alex Tanner wrote: > If all the companies worked together on a > single WinXP-Pro-emulating flavour of Wine, the > manpower problem would be solved. Not really. Firstly there is not (yet) enough commercial interest in contributing to Wine development to provide the manpo

Re: include/guiddef.h: C++ compatibility patch (with MSVC++ support)

On Friday 02 September 2005 19:53, Dmitry Timoshkov wrote: > There are 2 problems with this patch: you forgot to provide a definition > for EXTERN_C, I "forgot" nothing. It's defined in both basetyps.h and winnt.h, which is sufficient for it to have built the whole of WINE after a "make clean" a

Re: include/guiddef.h: C++ compatibility patch

On Thu, 1 Sep 2005 14:30, Steven Edwards wrote: > Well yes some of us do. I work to keep the Wine SDK compatible with > the PSDK because we have developed a MSVC backend in the ReactOS build > system and one day (God willing) I will get the ReactOS Project to use > Wine headers rather than w32api

Re: include/guiddef.h: C++ compatibility patch

On Wednesday 31 August 2005 19:10, Dmitry Timoshkov wrote: onst GUID name > > PSDK has 'extern' for both C and CPP cases, just the CPP one has 'extern > "C"'. We have to use the same approach. Why? We have to get the same *result*, but that doesn't mean we have to have the same *code*. 'extern "

Re: include/guiddef.h: C++ compatibility patch

> takes us into more dangerous territory (see Feist Publications v Rural > Telephone Service). Correction... Computer Associates v Altai (lesson: don't sent email requiring some precision before being fully awake). -- [EMAIL PROTECTED] - Sydney, Australia pgpXTslsdgefs.pgp Description: PGP

  1   2   3   >