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

Re: [ddraw] asynchronous screen updates

by Lionel Ulmer

> Here are my changes: > > - User_add_dirty_rect is now an asynchronous equivalent of > User_copy_to_screen. It adds the rectangle to the list of dirty rectangles > and signal the update thread that there is some work to do. > - update thread calls User_get_dirty_rect to iterate over the list of dirty > rectangles > - current "naïve" algoritm keeps only one rectangle which is a union of all > dirty rectangles, so it tends to redraw too much, but better algoritms may be > implemented > - removed now unused lastlockrect variable, and the code which updates it > > I attached the patch for your reviews, comments, suggestions. The only comment I have on the patch is that you are using the rectangle from the 'User_DirectDrawSurface_unlock_update' code. The big problem here is that for old DirectX versions (versions 1 to 3), the lock rectangle was not repeated in the Unlock call (it was only present in the Lock code). So, basically, you will always force a full redraw for these old DirectX versions. So, the best would be to add the dirty rectangles in the Lock calls (if we are not in READONLY mode). A part from that, the patch looks nice. Same comments as in my other mails about contributors :-) Lionel PS: all these dirty region handling should be factorized as I did the same kind of hacks in the D3D code to speed up transfer between 2D and 3D buffers. -- Lionel Ulmer - http://www.bbrox.org/

Jan. 26, 2004

Re: DIB_DirectDrawSurface_BltFast signed/unsigned comparision bug

by Lionel Ulmer

> I just added explicit casting to int where needed. It didn't fix the mouse > trails, but previously missing mouseover effect on icons at the main screen > appeared, so I guess it is a change in the right direction :) While your patch is certainly OK, if 'ddesc.dwWidth-dstx' is lower than zero, it means that there is nothing to do (as the destination X coordinate is out of the screen). Same for the source rectangle. So could you try rewriting your patch with something like that : if (ddesc.dwWidth<=dstx) return DD_OK; (and same for Y and srcs). And check if it gives you the same result as your previous patch. Maybe it's some added code, but well, it will be a bit cleaner IMHO. Anyway, thanks for fixing bugs in the DDraw code, we certainly needs more contributors :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 26, 2004

Re: Strange debug message in programs/winedbg/info.c

by Sami Aario

Patch submitted. ----- Original Message ----- From: "Eric Pouech" <pouech-eric(a)wanadoo.fr> To: "Sami Aario" <sami.aario(a)surfeu.fi> Cc: <wine-devel(a)winehq.org> Sent: Saturday, January 24, 2004 10:57 PM Subject: Re: Strange debug message in programs/winedbg/info.c > Sami Aario a écrit : > > Hi, > > > > The debugger kept messing up my output because of a missing > > newline. This patch fixes that. However, the condition checks for > > first_dll, but the output says first_option. They can't both be right. > > So which one should it be? > > It should be first_dll in both cases. > A+ >

Jan. 26, 2004

Re: Lotus Notes broken in recent CVS

by Mike McCormack

Hi Paul, The purpose of patch 10547 was to link the load order of 16bit dlls and their 32bit parents. eg. commctrl will only be loaded as a native dll if comctl32 is a native dll. You can probably solve the problem by adjusting the DllOverrides section in your wine config file. To do this, you first need to find which 16 bit dll's load order changed due to the patch, then adjust the load order of it's parent dll. Mike Paul R Streitman wrote: > I tested the patches by taking an 01/03 CVS snapshot and replacing the > relevant parts from an 01/02 snapshot rather than trying to un-patch the > files. Using that technique, I found that the changes in patch 10547 > (which required patch 10552 to compile) cause the problem that I am seeing > with Lotus Notes. That problem still occurs with current CVS. > > Thanks, > Paul

Jan. 26, 2004

Re: imm32 ImmDisableIME stub concern

by Jason Edmeades

Alexandre Julliard wrote: >Jason Edmeades <us(a)the-edmeades.demon.co.uk> writes: > > >>However, looking at a history of the IMM32 spec file, it was added >>(version 1.10) and removed (version 1.11). Has anyone any idea why, >>and would anyone have any strong objections to me re-stubbing it? >> >> >It's apparently collateral damage of the removal of Hidenori's >code. Feel free to add it again. > > Thanks for the info - I'm putting together a set of patchs to fix the startup of the game in question, and will submit them once I have a little more progress to report. Jason

Jan. 26, 2004

Re: imm32 ImmDisableIME stub concern

by Alexandre Julliard

Jason Edmeades <us(a)the-edmeades.demon.co.uk> writes: > However, looking at a history of the IMM32 spec file, it was added > (version 1.10) and removed (version 1.11). Has anyone any idea why, > and would anyone have any strong objections to me re-stubbing it? It's apparently collateral damage of the removal of Hidenori's code. Feel free to add it again. -- Alexandre Julliard julliard(a)winehq.com

Jan. 26, 2004

RE: Lotus Notes broken in recent CVS

by Paul R Streitman

I tested the patches by taking an 01/03 CVS snapshot and replacing the relevant parts from an 01/02 snapshot rather than trying to un-patch the files. Using that technique, I found that the changes in patch 10547 (which required patch 10552 to compile) cause the problem that I am seeing with Lotus Notes. That problem still occurs with current CVS. Thanks, Paul z/OS core components development Internet: prs(a)us.ibm.com ----- Forwarded by Paul R Streitman/Poughkeepsie/IBM on 01/26/04 02:32 PM ----- "Robert Shearman" <R.J.Shearman(a)war To: Paul R Streitman/Poughkeepsie/IBM(a)IBMUS wick.ac.uk> cc: <wine-devel(a)winehq.org> Subject: RE: Lotus Notes broken in recent CVS 01/23/04 08:10 PM > Through iterative CVS pulls, I have established that the problem > I see with > Lotus Notes not working occurred between 01/02/2004 and 01/03/2004. I had > thought that the problem came up only in the last week, but I must have > been mistaken. The 01/03 CVS snapshot gives the symptoms that I mentioned > before (appended below), and I was able to send this note with the 01/02 > snapshot. As a wild guess, try backing out these patches in order, testing after each one: 1. http://cvs.winehq.com/patch.py?id=10552 2. http://cvs.winehq.com/patch.py?id=10547 3. http://cvs.winehq.com/patch.py?id=10546 Rob

Jan. 26, 2004

Re: Various MDI fixes [?? Probable Spam]

by Dmitry Timoshkov

"Rein Klazes" <rklazes(a)xs4all.nl> wrote: > Dmitry, > > After applying the two patches there is a new problem (with Agent 2.0 > beta). > > I'm using it with maximized mdi windows. If I open another window, it > opens maximized (as it should). Now if I return to the original window, > either by closing the current one (with the X button, or <ctrl>-F4) or > selecting it (<ctrl>-TAB or the Window-menu using <alt>-W,1) the size of > the original window is now <restored> and needs to be maximized again. > > Any idea? Looks like MDI code has too much hacks for child activation and switching between children. There are places when activation messages are sent manually instead of relying on (de)activation done by the system. That code needs a major clean up and an overhaul. I've added that into my task list and when I have a break from more important work I'll have a look at it. Feel free to beat me with that. -- Dmitry.

Jan. 26, 2004

Re: Dungeon Keeper thread(s) recently

by Carlos Lozano

Hello, > >>That's the situation. > >>Any ideas for a starting point for debugging? > > > > > >Good, it sounds similar to the problem what i had with Theme Hospital. > >Try this patch: > > > >http://62.93.166.115/updatesysmetrics.diff > > > > GREAT! That did it! Thanks! > > Keeper is playable now, only the two mousepointers are very > irritating, and I gotta get the sound going ;-) > > Will this patch go into the CVS or is it some kind of hack? I think that it will be not going to cvs soon :(. It has 2 patches in one. The first is from Alex Pasadyn, and it is related to resolution change. The second is mine, and simply reset the clip cursor values when the resolution is changed (it is what fixes the problem in theme hospital and dungeon keeper). (checked in windows with a testcase :) Alex needs to do some changes in his patch, for that it will get in the cvs. Regards, Carlos. -- ___ _ \ | / Consulting | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.ePSXe.com

Jan. 26, 2004

NtSetThreadExecutionState

by Fabian Cenedese

Hi (Message bounced the first so I try again.) ----- The following addresses had permanent fatal errors ----- "|spamscan /var/lib/mailman/mail/wrapper-hq post wine-devel" (reason: User unknown) (expanded from: <wine-devel(a)winehq.org>) ----- Transcript of session follows ----- 550 5.1.1 "|spamscan /var/lib/mailman/mail/wrapper-hq post wine-devel"... User unknown Reporting-MTA: dns; wine.codeweavers.com Received-From-MTA: DNS; mxout.hispeed.ch Arrival-Date: Mon, 26 Jan 2004 07:53:28 -0600 I'm trying to run the Windows xcopy (no, don't ask :) It needs two more dlls (ulib.dll, ifsutil.dll) and then is almost happy. The only thing left it complains about is this: err:module:import_dll No implementation for ntdll.dll.NtSetThreadExecutionState imported from L"C:\\windows\\system\\ifsutil.dll", setting to 0xdeadbeef Can anybody help me with a stub? Maybe this gets things further. Thanks bye Fabi

Jan. 26, 2004

Re: Dungeon Keeper thread(s) recently

by Frank.Schruefer＠t-online.de

>> >>That's the situation. >>Any ideas for a starting point for debugging? > > > Good, it sounds similar to the problem what i had with Theme Hospital. > Try this patch: > > http://62.93.166.115/updatesysmetrics.diff > GREAT! That did it! Thanks! Keeper is playable now, only the two mousepointers are very irritating, and I gotta get the sound going ;-) Will this patch go into the CVS or is it some kind of hack? -- Regards, Frank Schruefer

Jan. 26, 2004

Wrong LANG message

by Fabian Cenedese

Hi When I start wine I always get a message about several possible language ids and that I need to set LANG to the specific sub id. But even after that I still get this message. I need to set LANGUAGE to the sub id, then wine keeps quiet. So either my setup is quite wrong or this message needs to be changed to set LANGUAGE. Thanks bye Fabi

Jan. 26, 2004

Re: Wine in gdb brokenness

by Boaz Harrosh

Found it! - run a wineapp do a ps see if you have wine-pthread or wine-kthread running - Lets say it is wine-pthread than at gdb do - (gdb) file wine-pthread and off you go. what happened is that gdb got the processes switched on him mid run. I think there should be a way to follow the next process but I couldn't figure how. In any way what I did was link -s my wine to wine-ptread (didn't want to change all these kdevelop projects :) ). Maybe there should be an Installation option that Auto-detects the Auto-detected-wine variant and soft link to it. Gregory M. Turner wrote: >On Saturday 13 December 2003 10:39 am, Mike Hearn wrote: > > >>Hi, >> >>Running wine in gdb appears to be broken with latest CVS: >> >>(gdb) file wine >>Reading symbols from wine...done. >>Using host libthread_db library "/lib/tls/libthread_db.so.1". >>(gdb) run >>Starting program: /opt/wine/bin/wine wine >>[Thread debugging using libthread_db enabled] >>[New Thread -1084455552 (LWP 30661)] >>[New Thread -1084458064 (LWP 30662)] >>Cannot find user-level thread for LWP 30661: generic error >> >>This is on fedora core 1. It looks like it might be the NPTL runtime >>detection stuff, does anybody have any ideas? >> >> > >heh, same here :P > > >

Jan. 26, 2004

Re: Various MDI fixes

by Rein Klazes

On Mon, 26 Jan 2004 16:56:59 +0800, you wrote: > > Hello, > > I didn't break this patch into smaller parts. I think the changes > are self explaining enough and quite straightforward. > > This patch fixes a bug with MDI menus reported by Duane Clark and > a couple of other minor problems I found while debugging that issue > (a not working system menu in a maximized child is a more noticeable one). > > Please apply this patch after the WM_MDISETMENU/WM_MDIREFRESHMENU fix > for Visio. Dmitry, After applying the two patches there is a new problem (with Agent 2.0 beta). I'm using it with maximized mdi windows. If I open another window, it opens maximized (as it should). Now if I return to the original window, either by closing the current one (with the X button, or <ctrl>-F4) or selecting it (<ctrl>-TAB or the Window-menu using <alt>-W,1) the size of the original window is now <restored> and needs to be maximized again. Any idea? Rein. -- Rein Klazes rklazes(a)xs4all.nl

Jan. 26, 2004

Re: Dungeon Keeper thread(s) recently

by Carlos Lozano

Hello, > I'll elaborate this a bit: > > - I have two mouse pointers. > - The first is trapped in the upper left corner and looks like a standard > mousepointer. When the mouse is moved down or right it follows a bit and > then always jumps back to it's corner. > - The second one is the Dungeon Keeper mouse pointer (some picture of a > monsters head). This one moves down and right if the mouse is moved in > this directions but doesn't move up or left. > Except this the mousepointer behaves absolutely normal. > > > That's the situation. > Any ideas for a starting point for debugging? Good, it sounds similar to the problem what i had with Theme Hospital. Try this patch: http://62.93.166.115/updatesysmetrics.diff Regards, Carlos. -- ___ _ \ | / Consulting | . |._ _ _| | ___ ___ ___ http://www.andago.com | || ' |/ . |<_> |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|<___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano <___'/ | \ -_) __/\__ \ > < -_) [ carlos.lozano(a)andago.com ]\___|_| ____/ _/\_\___| [ calb(a)epsxe.com ] http://www.ePSXe.com

Jan. 26, 2004

Re: wine/dlls x11drv/x11drv_main.c x11drv/x11drv.s ...

by Aric Stewart

Ok patch submitted... I did not add the 0xe001 to Chinese and Korean because i have not tested those yet. It was in response to behavior in Office 2k Japanese. I highly suspect that adding the 0xe001 is correct for Korean and CHinese also but wanted to do some more testing in those locals before making that change. Once that is made then we can probably remove this chunk of code. Which would be nice. -aric Dmitry Timoshkov wrote: > "Alexandre Julliard" <julliard(a)winehq.org> wrote: > > >>Log message: >>Aric Stewart <aric(a)codeweavers.com> >>Use X11 XIM callbacks to enable full IME support. >>Correct some timing issues with XIM input. >>Start to provide the framework for the MSIME messages. > > >> langid = PRIMARYLANGID(LANGIDFROMLCID(layout)); >> if (langid == LANG_CHINESE || langid == LANG_JAPANESE || langid == LANG_KOREAN) >>- layout |= 0xe001 << 16; /* FIXME */ >>+ layout = 0xe001 << 16; /* FIXME */ > > > The above change looks wrong. This thrashes low 16 bits of layout id. > Moreover, 0xe001 was added already in the global keyboard table list > for Japanese kbd layout (btw, why not for Chinese and Korean?). >

Jan. 25, 2004

Re: wine/dlls x11drv/x11drv_main.c x11drv/x11drv.s ...

by Aric Stewart

Doh! and i thought i had cleaned up all my shotgun attempts to get Japanese office 2000 working again. Yes. this needs to be fixed. I will make the patch to return this to normal and submit it asap. -aric Dmitry Timoshkov wrote: > "Alexandre Julliard" <julliard(a)winehq.org> wrote: > > >>Log message: >>Aric Stewart <aric(a)codeweavers.com> >>Use X11 XIM callbacks to enable full IME support. >>Correct some timing issues with XIM input. >>Start to provide the framework for the MSIME messages. > > >> langid = PRIMARYLANGID(LANGIDFROMLCID(layout)); >> if (langid == LANG_CHINESE || langid == LANG_JAPANESE || langid == LANG_KOREAN) >>- layout |= 0xe001 << 16; /* FIXME */ >>+ layout = 0xe001 << 16; /* FIXME */ > > > The above change looks wrong. This thrashes low 16 bits of layout id. > Moreover, 0xe001 was added already in the global keyboard table list > for Japanese kbd layout (btw, why not for Chinese and Korean?). >

Jan. 25, 2004

Re: An MDI regression

by Dmitry Timoshkov

"Duane Clark" <dclark(a)akamail.com> wrote: > A minor regression in the MDI code. I am not sure which patch it was, > but it is something in the last couple of weeks. Open most any MDI > application (I've tried 3) including Pegasus mail. Maximize one of the > windows, and take a look at the menus. Even better, after doing that, > drag the entire application to a different size. The effect is rather > impressive. Looks like that it's due to my recent MDI work. Thanks for the bug report, I'll try to fix it soon. -- Dmitry.

Jan. 25, 2004

An MDI regression

by Duane Clark

A minor regression in the MDI code. I am not sure which patch it was, but it is something in the last couple of weeks. Open most any MDI application (I've tried 3) including Pegasus mail. Maximize one of the windows, and take a look at the menus. Even better, after doing that, drag the entire application to a different size. The effect is rather impressive.

Jan. 25, 2004

imm32 ImmDisableIME stub concern

by Jason Edmeades

Hello, Debugging a game, it crashes because it calls a currently unimplemented function, ImmDisableIME. Ordinarily this wouldnt be worrying, and I could stub it (which i have). The game gets far further now, and displays a blank screen and corrupt graphics, rather than just terminating. :-) However, looking at a history of the IMM32 spec file, it was added (version 1.10) and removed (version 1.11). Has anyone any idea why, and would anyone have any strong objections to me re-stubbing it? Jason

Jan. 25, 2004

Re: New Open Source License: Single Supplier Open Source License

by Richard Schilling

I've now moved this thread to the wine-license list. I probably should have posted there in the first place - an oversight on my part. Sorry. Anyway . . . > this license they can. > > Under GPL and BSD the developer has absoutely no control or means to keep > their work an open source because they > > cannot remove distribution from people who don't comply. > Sorry for the language but this is pure bullshit. The Free Software Foundation > has enforced the GPL many times, forcing proprietary vendors to GPL the code of > works deviated from GPL'ed code, and has always reached a settlement before > getting to court, that shows how good the GPL is. I have not heard nor read of such cases. At least there is nothing on their website. Can you provide links and/or references to them? I will also point out that the FSF wants to remove patent and Copyright laws that are currently in effect in the U.S. My goal is to provide Open Source software within the framework of those laws rather than try to have them changed. > IMHO you're quite confused, and don't have a good idea about what open source is > all about. You license closely remembers the shared source license. Could you please point out what part of a shared source license resembles the shared source license? Richard

Jan. 25, 2004

Fwd: [Bug 1952] half-life, unreal tournament: video runs too 1.5x too fast

by hatky

Sound like a valid claim that wine does not update the cpu speed on speed step speed change.... ---------- Forwarded Message ---------- Subject: [Bug 1952] half-life, unreal tournament: video runs too 1.5x too fast Date: Saturday 24 January 2004 20:30 From: Wine Bugs <wine-bugs(a)winehq.org> To: wine-bugs(a)winehq.org http://bugs.winehq.org/show_bug.cgi?id=1952 lesha(a)netman.ru changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|FIXED | ------- Additional Comments From lesha(a)netman.ru 2004-24-01 14:30 ------- I finally know exactly what was going on. Someone knowledgeable needs to decide if this is a problem Wine should fix. My laptop has SpeedStep, and if you power it up without AC power, it will boot in 1200 Mhz, and /proc/cpuinfo will list 1200 mhz. Turning on AC power switches back to 1700Mhz (or manual acpi adjustments). However, /proc/cpuinfo reflects only 1200. Wine apparently uses CPU cycles for timing (IMO, a lousy idea). Thus, when I had gone through power up without AC, later switched to AC, Wine thinks that my Mhz rating is lower than it is, and I get a speed increase of 42%. If I now use ACPI to reconfigure as 1200 Mhz, I end up with normal speeds again. So, really, ACPI could be considered at fault for not updating cpuinfo. But maybe /proc/cpuinfo isn't even the right place to read this information. Or at least, maybe one shouldn't rely on reported MHz for timing. For instance, the native shooters (Prboom, Quake3) don't mind at all if I switch the CPU frequency mid-game. Opinions? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. ------------------------------------------------------- -- Hatky. Hebrew tranlator of http://www.mandrakelinux.com/he/ Helper of http://www.phpnuke-israel.org Worshiper of http://www.winehq.org

Jan. 25, 2004

Re: Dungeon Keeper thread(s) recently

by Frank.Schruefer＠t-online.de

Lionel Ulmer wrote: >>- I have two mouse pointers. >>- The first is trapped in the upper left corner and looks like a standard >> mousepointer. When the mouse is moved down or right it follows a bit and >> then always jumps back to it's corner. >>- The second one is the Dungeon Keeper mouse pointer (some picture of a >> monsters head). This one moves down and right if the mouse is moved in >> this directions but doesn't move up or left. >> Except this the mousepointer behaves absolutely normal. >> >> >>That's the situation. >>Any ideas for a starting point for debugging? > > > Well, this looks like a dinput bug in the handling of relative mouse > grabbing when computing the coordinates of the middle of the screen. Hy Lionel, DINPUT.DLL is not reported as being loaded (using +loaddll) so I think it's nothing to do with it. > > To make a long story short, X does not really provide any way to get > relative mouse movements (I do not despair to one day check-out the fd.o X > server and add an extension to do that). So we need to 'warp' the mouse to > the middle of the window each time it moves and compute from absolute mouse > events the relative ones. Interesting you mention warping ... if found that X11DRV_SetCursorPos is called very often, obviously by a timer (of the game) or reset after every mousemotion event. It looks like the prog is constantly setting the mouse pointer (#1) back to 0,0. So I made the SetCursorPos doing nothing. Then the situation changed as follows: - The pointer #1 is now movable freely on the screen. - If the mouse is moved right or down there are XMotionEvent's generated, and the game mouse pointer (#2) is moving down/right. - If the mouse is moved left/up the game mouse pointer is still moving down/right. Also it's moving only if #1 was moved previously out of it's left upper corner (so xpos>0 or ypos>0). - No more MotionEvents have been going on while the mouse wasn't moved. (Before they've been coming constantly). So X is obviously not generating any events if the mouse is at 0,0 and moved further left/up. Well, guess it's because that would be out of the client area. I don't know all implications of commenting out the SetCursorPos code but it seems that even if X would send those events there's still some other problem. Maybe one is: Why are there motion events generated by SetCursorPos if the pointer wasn't actually moved, neither the position actually changed? Well, that's what I've been able to find out so far ... > > Anyway, this whole DInput code worked one day (when it used direct X calls > and was full of hacks) and was a bit broken by the DLL separation work > (basically, to support this properly we cannot use plain Win32 calls as it's > done now but need to hook directly at the low level input system). > > Lionel (back from one week snowboarding in the Alps and still handling > the mail backlog :-) ) Hope you had some good rides there :-) > > PS: will look too at the DDraw bug Jason reported. > > PS2: was not able to run 'kddata.exe' properly (got hangs in Wine in random > places), but unzipping directly with unzip worked better :-) > -- Thanks, Frank Schruefer

Jan. 25, 2004

Re: Winedbg: Parse symbols in libc, libpthread, etc

by Eric Pouech

> I'm not sure which you mean by the main module loaded linked list, but I > guess you mean the one we get the rest of the modules from. On my system > (Fedora Core 1), the modules directly linked to wine-pthread/wine-kthread > don't appear in the main module list (i.e. don't get listed at all when you > run, for example, winedbg notepad). That's very strange. I checked for example for gdb does and it never accesses the l_ld field, and assumes every loaded shared module is present in the unique ELF module list that we're already scanning. I could understand that we have some too strict tests somewhere, but I don't understand how it could be that we have to call DEBUG_WalkList recursively. So, could look at the entries in the dbg_hdr.r_map list and see whether or not the main libraries appear (will some unsupported flags for example). >>(I'm currently working on fixing some of >>the issues of the debugger: get around WINELOADER issue, report >>unsupported debug format (like Dwarf2...)). > > > Cool. If this patch will get in your way, just let me know. it actually does, but I'll submit a merged form A+

Jan. 25, 2004

Re: shell32 patch 20

by Jakob Eriksson

Dmitry Timoshkov wrote: >"Jakob Eriksson" <jakov(a)vmlinux.org> wrote: > > > >>Depending on how you define break, that argument can be used to stop >>almost any patch to Wine, if the goal happens to be cross compilation. >> >> > >What way will you decide to go, if in the next Platform SDK release >Microsoft will remove some of the existing APIs and simultaneously add >some previously undocumented? Rewrite all the affected parts of your code? > > I haven't thought about that. Guess we will have to consider that problem when it appears. (Have they ever deprecated functions so you can't use them, by the way? I get warnings on some, but it still links.) >>I understand your fight against code duplication and such, but IMHO cross >>compilation is something that needs to happen. >> >> > >I wonder then, how you are going to cross compile most of the kernel parts >of ReactOS code. If you would rely only on the documented APIs and headers >ReactOS would not be in the state it is now. > > > No, kernel parts are of course often not possible to share, since they are implemented on very different subsystems: PC hardware "API" vs UNIX system API. But AFAIK shell32 is a user-space DLL and it should be possible to make it so that it can be shared unmodified between Windows, ReactOS and Wine. (Or VC++, mingw and wines build system.) If I am wrong in this assumption just ignore my whole argument. /Jakob

Jan. 25, 2004