October 2002 - Wine-Devel - list.winehq.org

Re: Wine 0.8 TODO v0.1

by Carlos Lozano

El jue, 31 de oct de 2002, a las 15:02, Alexandre Julliard escribio: > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > Now, again, what I mean by 0.8: > > -- Users can start using Wine > > -- works well for a fair number of apps > > -- no MS DLLs required (from real Windows) > > That alone should take a couple of years <g> It depends on the complex of the apps (winmx,icq or ie6,officeXP ;) and what you means by "works well" ;) 70-80% or 95-100% functionality?? A list of apps should be prepared at least several months before of a release, and sometime before of release's time freeze the advance and concentrate in stabilize this applications. It should be good select the apps seeing the DLLs needed. Hmm, surely after of the release the development should be divided in stable/unstable, because it should be a bad thing that 8.0 should run "Ex. ie5" and 8.1 no :/ 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

Oct. 31, 2002

Re: Wine 0.8 TODO v0.1

by Joerg Mayer

On Thu, Oct 31, 2002 at 05:38:10PM -0500, Dimitrie O. Paun wrote: > 4. Enlist some 'official' distribution maintainers > (at the minimum RedHat, Suse, UnitedLinux, Debian) Add Mandrake, remove UnitedLinux: UnitedLinux is a SERVER distro (or, to be more precise: the core of several server distros). Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Oct. 31, 2002

Re: Getting actively involved in the Wine project

by Francois Gouget

Hi Thomas, Thomas Wickline wrote: [...] > 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. I agree. Making Wine presentations at local LUGs can only be a good thing. It can dispel some myths and it might even help Wine recruit new developpers :-) CodeWeavers has actually done a few presentations on "CrossOver and Wine" at local LUGs. I did one recently at the Linux User Group Of Davis (LUGOD, a pretty nice LUG) quite recently. You can find the presentation online at the following URL. http://www.lugod.org/presentations/crossover/ Feel free to check it out and use it as inspiration if you want to make a presentation (credit to CodeWeavers appreciated if you use significant portions of it <g>). -- Francois Gouget fgouget(a)codeweavers.com

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 05:05 pm, Jeremy Newman wrote: > Oh pick ME ME ME! :-) OK mister, you're on! :) > I don't volunteer my weekends often, so speak now. IMO we need to reorganize the front page a bit more than that. Namely: -- the big "Navigation" box is wasted space, because 1. It contains items everybody expects as a left-hand menu 2. Contains no real content -- while pretty, the layout is a non-standard, and is a wee bit too far away from the "least surprise" principle -- the news/announcements need a bit more space So here is my suggestion: 1. Have a left-hand navigation menu, as follows: Home About Download Documentation Development Mailing Lists Screenshots Look at http://www.gimp.org. It's not the nicest, but the home page is simple, and has a link to almost all relevant info: Download, Mailing Lists, FAQ, Docs, Screenshots, etc. You need only *one* click. In our site, you need 3-4 clicks, scrolling, etc. Vast majority of people don't have such a long attention span. Look for example at http://mesa3d.sourceforge.net/, it's not pretty, but you can get to most stuff in *one* click. 2. The main area (in the middle) should be "Announcements" We should have there the last 2-3 announcements, and at the end a link to the archives. Each announcement gets a bold title, and a few lines of text. Here we'll have Wine releases (the few lines of text will contain the What's New stuff), WWN releases (for which we can lists the story titles), etc. I'll stop here. What do you think? -- Dimi.

Oct. 31, 2002

Re: Wine 0.8 TODO v0.1

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Now, again, what I mean by 0.8: > -- Users can start using Wine > -- works well for a fair number of apps > -- no MS DLLs required (from real Windows) That alone should take a couple of years <g> > -- User facing stuff (website, docs, etc.) are in > a decent state, to avoid scaring them away > What is NOT in 0.8: > -- stable server protocol: no binary compatibility > -- DLL separation: ditto IMO the goals for 0.9 will be reached before the ones for 0.8 so you might as well put everything together... > D. Stabilize utilities > 0. Get rid of the init directive from .spec files This requires dll separation... > E. Important fixes > Alexandre, what to you see here? I think the window management stuff is important, otherwise you can't install most apps without using desktop mode. But it's already in the 0.9 goals (and I'm working on it). -- Alexandre Julliard julliard(a)winehq.com

Oct. 31, 2002

Wine 0.8 TODO v0.1

by Dimitrie O. Paun

This is the initial TODO for Wine 0.8. I know, 0.8 has been released before, but that's ancient history. Whether or not it gets released with this version number is irrelevant. In fact, even if it never becomes a public release, it is an important point to reach toward 0.9, and so if we complete this work, it would have solved its purpose. Now, again, what I mean by 0.8: -- Users can start using Wine -- works well for a fair number of apps -- no MS DLLs required (from real Windows) -- User facing stuff (website, docs, etc.) are in a decent state, to avoid scaring them away What is NOT in 0.8: -- stable server protocol: no binary compatibility -- DLL separation: ditto That being said, this is my initial list. Comments, flames, suggestions, are appreciated. A. WineHQ work 0. Reorganize a bit the navigational menu 1. Add a screenshot link to the homepage 2. Create some really sexy screenshots 3. Rework the FAQ interface (static HTML, a la http://www.dvddemystified.com/dvdfaq.html, all on one page, with a clickable question list at the top) 4. Enlist some 'official' distribution maintainers (at the minimum RedHat, Suse, UnitedLinux, Debian) 5. Create nice page with apps that run virtually flawless They should not require MS dlls, tricks, etc. to run Small explanation, screeshot, optional link to download page, such as Tucows. B. Documentation work Andy, take it away! :) C. Wine configuration 0. Merge configuration into the registry 1. Write control panel applets for editing it 2. Have decent defaults so we can start control panel without prior configuration 3. Have wizard like app to autoconfigure wine (?) 4. Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg 5. Write .inf script to setup a new Wine installation D. Stabilize utilities 0. Get rid of the init directive from .spec files 1. Make sure the .spec file format is fairly stable 2. Ensure the various utilities' options are stable E. Important fixes Alexandre, what to you see here? -- Dimi.

Oct. 31, 2002

Re: So lets say we do it

by Andreas Mohr

On Thu, Oct 31, 2002 at 04:05:21PM -0600, Jeremy Newman wrote: > On Thu, 2002-10-31 at 15:30, Dimitrie O. Paun wrote: > > Agreed. I say, let's get some of the content in shape, and worry about > > the form a wee bit later. BTW, any web-design guys around, that may > > want to take on this task? > > Oh pick ME ME ME! :-) > > Wait a minute, I'm already in charge of that. Must have been slacking > off again. > > Here's my idea. On the front page, add a new box above the WNN box, > below the Latest Wine release box. This box would be a random screenshot > pulled from the AppDB, (or a predefined list of available screenshots). > I can whip up a new page/section/what have you called "Screenshots". > This requires a new button for the front page. It should be linked to on > the About page, and the screenshots page links back to the About page. A > little cross referencing if you will. > > Does this work for anyone. I can probably do this during the weekend in > my "off" hours. Two words: Earth-shattering idea ! :-) (oh wait, there's just been an earthquake in Italy :-\) That's a very good proposal. I guess all that's left for us to do is to make sure About looks terrib^H^Hific :) -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview

Oct. 31, 2002

Re: So lets say we do it

by Jeremy Newman

On Thu, 2002-10-31 at 15:30, Dimitrie O. Paun wrote: > Agreed. I say, let's get some of the content in shape, and worry about > the form a wee bit later. BTW, any web-design guys around, that may > want to take on this task? Oh pick ME ME ME! :-) Wait a minute, I'm already in charge of that. Must have been slacking off again. Here's my idea. On the front page, add a new box above the WNN box, below the Latest Wine release box. This box would be a random screenshot pulled from the AppDB, (or a predefined list of available screenshots). I can whip up a new page/section/what have you called "Screenshots". This requires a new button for the front page. It should be linked to on the About page, and the screenshots page links back to the About page. A little cross referencing if you will. Does this work for anyone. I can probably do this during the weekend in my "off" hours. I don't volunteer my weekends often, so speak now. -- __ _WebGeek/SysAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | / -_) | | / ' \/ _` | ' \ -= jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

Oct. 31, 2002

Re: RFC: msvcrt _popen/_wpopen/_pclose

by chrismorgan＠rcn.com

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); > } > > > >

Oct. 31, 2002

Re: Wine securityflaw.

by Raul Dias

Greg Turner <gmturner007(a)ameritech.net> wrote: >On Thursday 31 October 2002 08:10 am, Raul Dias wrote: >> My $0.02, >> >> A way to make it more secure is to catch key API calls and decide if >> the application is allowed to run it or not. > >not a bad idea. > >> Wine could implement a clean Security Layer: YES > >Clean, perhaps, but secure? That depends on what you are trying to >achieve: since the unix API is available to apps running under wine, >such measures will only secure applications which don't specifically >check for wine and circumvent its api-level security measures. > >So, for example, this could be used to protect a system against security >flaws in Internet Exploder or Outlook... but a malicious virus writer >could work around winapi-based security provisions, as discussed >earlier in this thread. In this case I agree that the OS should provide the security layer, not wine. Wine should provide security only for (or "at least for") WIN32 API flaws. []'s Raul Dias > >-- >gmt > >"The purpose of government is to rein in the rights of the people" > --President Bill Clinton, MTV interview, 1993 >

Oct. 31, 2002

Re: Warcraft III no go. (probs with 1.03 ?)

by Bobby Bingham

hmm ... i had 1.00 and 1.01 working fine, but then i updraded to 1.03 ... but it dies differently for me (AFAICS) ... it seems the cracked executable is missing some exported funtions that warcraft 3 1.03's game.dll requires .... i've tried this under windoze too, and it crashes for me immediately (with a dialog saying game.dll is linked to missing exports from war3.exe) under wine, it prints out: err:win32:PE_fixup_imports No implementation for War3.exe.697 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for War3.exe.696 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for War3.exe.702 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for War3.exe.699 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for War3.exe.700 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for War3.exe.701 imported from C:\Program Files\Warcraft III\game.dll, setting to 0xdeadbeef but it starts running. too bad it tries calling those exports when you want to start playing, and crashes with an access violation ... -- Bobby Bingham

Oct. 31, 2002

Re: Versions & mass-appeal

by Dimitrie O. Paun

On October 31, 2002 03:35 am, Johan Gill wrote: > Even with perfectly working builtin dlls, one needs overrides for the > native dlls that are proprietary, or the loading will fail. Or is this a > bug? This doesn't sound right. Can you give some examples of that happening? -- Dimi.

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 04:26 pm, Andreas Mohr wrote: > I wouldn't be 100% against placing a Screenshot link on the main page > - it's a mere 99% only. > But with the current menu infrastructure, I'm about 150% against it. > If we added a separate Screenshots menu item (which, by the way, I don't > think is needed, since we do have that nice About page), > then the whole page would grow overly long. Agreed. I say, let's get some of the content in shape, and worry about the form a wee bit later. BTW, any web-design guys around, that may want to take on this task? -- Dimi.

Oct. 31, 2002

RFC: msvcrt _popen/_wpopen/_pclose

by Jaco Greeff

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); }

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 04:18 pm, Andreas Mohr wrote: > Bl**dy b*tch ! :-)) Listen man, I don't like that! I mean, what's up with the stars?!? :))) > First you annoy the h*ll out of people, and then you behave as if nothing > had ever happened and the weather was fantastic... ;-) Oh, Andy dude, you are the toughest guy on Wine-devel, crushing poor newbies without remorse. And now, all of a sudden, you become this sensible, in-touch-with-your-feelings guy?!? ;-) (ROTFL) > (BTW: the weather here is awful :) See, and you blame poor me... :P -- Dimi.

Oct. 31, 2002

Re: XBox

by Francois Gouget

On 30 Oct 2002, Chris Thielen wrote: [...] > I'm sure an Xbox emulator will eventually come along, assuming there > aren't a few already in the works; they, however, under Linux at least, > would have to implement DirectX calls; it would be interesting to > frequently contact those developers as they would face many of the same > issues of implementing DirectX as the newly formed Wine DX group will. I > don't know of any emulators that support Xbox architecture, but I don't > think wine should be the project to do so, not unless an Xbox game runs > under (normal) Windows. I thought that the XBox was basically a stripped down version of the Win32 API + DirectX + some hardware and software modifications to make XBox games incompatible with regular Windows. I also thought one of Microsoft's goals was to lure PC game programmers to the XBox by making it very similar to writing games for a PC. So it seems like Wine would contain 90% of what's needed to make an XBox emulator (for Unix), thus making it a good starting place. Same as Wine would be a good starting place to write a WinCE emulator. Of course I don't have (and probably will never have) and XBox and have never programmed a game for the XBox so maybe others know better? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Oct. 31, 2002

Re: So lets say we do it

by Andreas Mohr

On Thu, Oct 31, 2002 at 03:20:34PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 03:11 pm, Andreas Mohr wrote: > > Why, the current rate is avalanche-like ;) > > > > I'm growing ever more astonished about the increase in wine-patches per > > day... > > Same here. It's quite amazing! But can we sustain the rate for a year? I might be willing to bet that it might actually increase even more, now that more and more companies go The Linux Way... > > But of course you're sorta right, we're still quite far off the mark. > > Yes, but it's been my experience that there's nothing like a good, > focused TODO list to get people working on what's needed. And this > is were I'm aiming with these emails... Very true. We should make sure that the Contribute page links more or less directly to one page listing the requirements for a specific version (that'd be the Bugzilla 0.9 and 1.0 pages, I guess). But AFAIK the Contribute page already does this. BTW, I just updated the Contribute page quite a lot. -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 03:33 pm, Andreas Mohr wrote: > (OK, if you're overly pessimistic, then you'll probably tell me now that > nobody will ever work on updating foreign languages, despite of such > a marvellous infrastructure) No, all I am saying is that's a lot of effort, for not that huge gain. IMO there is a lot to gain on the docs front by just working on the English docs, that's all. And it's not nearly as complicated, requires no infrastructure, etc. Once we tackle that, we can start thinking about localizing the docs (even though I would suggest waiting for things to stabilize, since it's a lot of work, and there's no point in tracking a rapidly changing Wine in a gazillion languages). > Hmm, WAIT... didn't I say somewhere that I wouldn't work on docu > any more ? > I guess I didn't :) Oh, come on man! Pretty please? :))) -- Dimi.

Oct. 31, 2002

Re: So lets say we do it

by Andreas Mohr

On Thu, Oct 31, 2002 at 03:17:26PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 03:09 pm, Andreas Mohr wrote: > > Well, that maintenance would e.g. include the localization work I > > suggested, having a *separate* CVS containing all localized Wine Guides, > > and having automatically updated docu maintenance web pages > > for every language involved. > > But this is probably a bit too much. I mean, yeah, would be great to > have the guides localized, and what not, but that's a _lot_ of work, > and we don't seem to be able to maintain the English ones, let alone > other languages. Localizing the guides right now would just compound > the problem by just ending up with more unmaintained documentation. And here AGAIN I have to disagree with you :) Given a *correct* and *working* framework, the docu simply would not be rendered unmaintained. Every change in the English docu would keep sitting (or rotting) on the various foreign language translation pages until this change has been applied to the respective language and the item has been closed. (OK, if you're overly pessimistic, then you'll probably tell me now that nobody will ever work on updating foreign languages, despite of such a marvellous infrastructure) > What would be more productive, at this point, is a clear, and focused > TODO list for the current documentation, broken down into two sections: > 1. What is out of date (and needs fixing) > 2. What is missing (and needs writing) > Now, you being the guy that know the docs best, ..., eh, ..., maybe > you can help create such a list ;) Once it's done, maybe people will > start picking an item at a time, etc. What do ya say? Hmm, WAIT... didn't I say somewhere that I wouldn't work on docu any more ? I guess I didn't :) I could do that, but don't count on it, since my time is limited. (heck, I can't even keep up with the Wine mails that keep flooding my inbox !) (not to mention that it's me today who's to blame quite a lot for this mail situation today :) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 03:11 pm, Andreas Mohr wrote: > Why, the current rate is avalanche-like ;) > > I'm growing ever more astonished about the increase in wine-patches per > day... Same here. It's quite amazing! But can we sustain the rate for a year? > But of course you're sorta right, we're still quite far off the mark. Yes, but it's been my experience that there's nothing like a good, focused TODO list to get people working on what's needed. And this is were I'm aiming with these emails... -- Dimi.

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 03:09 pm, Andreas Mohr wrote: > Well, that maintenance would e.g. include the localization work I > suggested, having a *separate* CVS containing all localized Wine Guides, > and having automatically updated docu maintenance web pages > for every language involved. But this is probably a bit too much. I mean, yeah, would be great to have the guides localized, and what not, but that's a _lot_ of work, and we don't seem to be able to maintain the English ones, let alone other languages. Localizing the guides right now would just compound the problem by just ending up with more unmaintained documentation. What would be more productive, at this point, is a clear, and focused TODO list for the current documentation, broken down into two sections: 1. What is out of date (and needs fixing) 2. What is missing (and needs writing) Now, you being the guy that know the docs best, ..., eh, ..., maybe you can help create such a list ;) Once it's done, maybe people will start picking an item at a time, etc. What do ya say? -- Dimi.

Oct. 31, 2002

Re: So lets say we do it

by Andreas Mohr

On Thu, Oct 31, 2002 at 03:07:15PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 03:00 pm, Andreas Mohr wrote: > > > Not yet too late for another 'Halloween' release though ;) > > > > Yep... > > > > ...next year ! ;) > > I don't want to jinx it, but at the rate we're going, we'd be > lucky to do a 1.0 'Halloween' release next year :/ Why, the current rate is avalanche-like ;) I'm growing ever more astonished about the increase in wine-patches per day... But of course you're sorta right, we're still quite far off the mark.

Oct. 31, 2002

Re: So lets say we do it

by Andreas Mohr

On Thu, Oct 31, 2002 at 02:58:12PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 02:44 pm, Andreas Mohr wrote: > > For christ's sake, IF YOU CAN'T STAND THE DOCU, THEN *IMPROVE IT*. > > Well, that's a good point. And I did a bit, but not nearly as much > as you. > > > I did. (past tense) > > But maybe then it seems like I didn't... > > Hey, I've never complained about the work you did on the docs! Not directly, yes. > All I am saying is that the docs are, in part, out of date, > and I'm not pointing a finger at you, as it isn't your responsibility > to keep them up-to-date. *I* didn't keep the ones I wrote up-to-date, > so I don't dare point my finger at anyone :) Heh. > The docs are huge, and requite work, which should be tackled by > more than one person. No matter how much you work on them, if > you are alone, you'll always be behind. So don't take my comments > as an attack against you, the one actually working on the docs; > quite the opposite, it's a comment to the community for not helping > on the said maintenance. Well, that maintenance would e.g. include the localization work I suggested, having a *separate* CVS containing all localized Wine Guides, and having automatically updated docu maintenance web pages for every language involved. So far there still is nobody who has stepped up to the plate of implementing such a database-driven web page framework... (I could complain here again, but this time I better won't :) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 03:00 pm, Andreas Mohr wrote: > > Not yet too late for another 'Halloween' release though ;) > > Yep... > > ...next year ! ;) I don't want to jinx it, but at the rate we're going, we'd be lucky to do a 1.0 'Halloween' release next year :/ -- Dimi.

Oct. 31, 2002

Re: So lets say we do it

by Andreas Mohr

On Thu, Oct 31, 2002 at 07:08:07PM +0100, Marcus Meissner wrote: > On Thu, Oct 31, 2002 at 08:24:28AM -0800, Alexandre Julliard wrote: > > So no, I'm not going to make a general public release just yet... > > Not yet too late for another 'Halloween' release though ;) Yep... ...next year ! ;)

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 02:44 pm, Andreas Mohr wrote: > For christ's sake, IF YOU CAN'T STAND THE DOCU, THEN *IMPROVE IT*. Well, that's a good point. And I did a bit, but not nearly as much as you. > I did. (past tense) > But maybe then it seems like I didn't... Hey, I've never complained about the work you did on the docs! All I am saying is that the docs are, in part, out of date, and I'm not pointing a finger at you, as it isn't your responsibility to keep them up-to-date. *I* didn't keep the ones I wrote up-to-date, so I don't dare point my finger at anyone :) The docs are huge, and requite work, which should be tackled by more than one person. No matter how much you work on them, if you are alone, you'll always be behind. So don't take my comments as an attack against you, the one actually working on the docs; quite the opposite, it's a comment to the community for not helping on the said maintenance. -- Dimi.

Oct. 31, 2002

Re: So lets say we do it

by Johan Dahlin

Em Qui, 2002-10-31 às 16:38, Dimitrie O. Paun escreveu: > On October 31, 2002 01:21 pm, Alexandre Julliard wrote: > > Sometime in June, I don't have the exact date of the first release > > unfortunately. Release 0.0.2 was on June 25. > > Too far away for 0.8, too close for 1.0. Maybe 0.9, if we're lucky. > Maybe it's better to call the next version 0.9. I checked up, 0.8 is already released :) It was the last version to be released before switching to the snapshot style version numbering. (the first snapshot was released February 1994) > -- > Dimi. > -- Johan Dahlin <jdahlin(a)async.com.br>

Oct. 31, 2002

Re: Debugging advice

by Michael Wetherell

On Thursday 31 October 2002 1:53 am, Matthew Bloch wrote: > Okay, but presumably it's easier (as in not impossible!) for me to debug a > program with GDB if I'm using a elf binary as opposed to a PE binary, which > is mostly my object here. gdb does have support for PEs (since there are Windows versions of gdb). Unix builds don't usually have it compiled in, though you only need to change one line of the gdb souce to enable it, see: http://groups.google.com/groups?hl=en&lr=&selm=6xUt8.14322%24sL6.2032145%40… gdb doesn't support any of the debugging formats used by MS tools, but you can instead compile your program with a version of gcc that targets Win32 (some GNU/LInux distros have mingw32 as a package). I made some notes about debugging threads this way here: http://www.winehq.com/hypermail/wine-devel/2002/06/0051.html Alternatively, Eric Pouech made a gdb remote stub out of winedbg, see: http://www.winehq.com/hypermail/wine-patches/2002/07/0080.html http://www.winehq.com/hypermail/wine-patches/2002/07/0081.html

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 02:44 pm, Andreas Mohr wrote: > Gee, thanks ! > You know how many man-weeks (err, months ?) I've been putting into it, > right ? I was referring to the interface, not the content. In fact, I think the web-interface makes a disservice to the content. In fact, I am saying quite the opposite: we should bring that content to more to the front, right now it's hidden way too deep inside the site. -- Dimi.

Oct. 31, 2002

Re: So lets say we do it

by Andreas Mohr

On Thu, Oct 31, 2002 at 01:19:33PM -0500, Dimitrie O. Paun wrote: > On October 31, 2002 11:24 am, Alexandre Julliard wrote: > > You forgot a few things here: > > Yes, and no: it was getting late, hand was all funny, > email was getting too long... :) > > > First it doesn't even start because they don't have a config file. OK, > > Hear, hear! BTW, we should move configuration out of documentation/samples Hmm, why ? Where should it be then ? Having sample config in such a directory has a pretty long tradition. One thing that comes to my mind here is Debian. > > Then they finally manage to run the installer but it > > puts stuff in RunOnce that never gets run so the app doesn't work. > > See, I wasn't even aware of that! Hmm, my problem :-\ > > Then they finally make the app run but can't print anything. And > > True. I second that (at least sometimes). > > when they ask for help they get told to fight the FAQ-O-Matic crap to > > maybe finally find an answer telling them they are an idiot. > > That FAQ-O-Matic should just be 'rm -rf'. It's crap. We either have > a carefully hand-written FAQ, or nothing at all. Gee, thanks ! You know how many man-weeks (err, months ?) I've been putting into it, right ? I guess I hereby declare that I'll stop ALL documentation work. Obviously it's not too appreciated, given the constant and very annoying whining. Not to mention that I've been constantly working "behind the fact". For christ's sake, IF YOU CAN'T STAND THE DOCU, THEN *IMPROVE IT*. I did. (past tense) But maybe then it seems like I didn't... Boy, that'll give me quite some free time for RL work... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 01:21 pm, Alexandre Julliard wrote: > Sometime in June, I don't have the exact date of the first release > unfortunately. Release 0.0.2 was on June 25. Too far away for 0.8, too close for 1.0. Maybe 0.9, if we're lucky. -- Dimi.

Oct. 31, 2002

Re: winapi_check question...

by Greg Turner

On Thursday 31 October 2002 12:54 pm, Patrik Stridvall wrote: > Greg wrote: > > On Thursday 31 October 2002 09:20 am, Patrik Stridvall wrote: > > > Ignore it. > > > > OK. You promise it won't screw up the actual documentation bot? > > Promise? Hmm. All code have bugs you know and winapi_check is > designed to be ad hoc and thus inherently buggy... :-) > > But seriously, I wouldn't worry about it. BUT I CANT SLEEP!!!! (j/k, it's already forgotten) > Anyway. A real fix to the code you be nice. but I /am/ being nice ;) > Presumable the type CLIENT_CALL_RETURN haven't > been declared properly. no can do, it's that way because of an obscure gcc vs. msvc call convention mismatch for function calls with struct return-types. anyhow, CLIENT_CALL_RETURN is just a stupid union for casting between longs and ptr's, so, to me, it's just not worth the effort to understand the problem. Basically, I just did what Alexandre told me to, and called it "fixed" :) A real fix probably involves some crazy wrapper/thunking technique, assembly code, wierd gcc command-line options, an extention to the .spec format, and/or obscure #pragma's -- quite possibly beyond my abilities, and definitely beyond my level of motivation, given the (presumed) non-severity of this particular instance of the problem... maybe, however, there are some more pressing reasons to solve this, in which case I'd be happy to look at it a bit more carefully (but still skeptical of my ability to solve it). -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Dimitrie O. Paun

On October 31, 2002 01:46 pm, Greg Turner wrote: > In support of attached patches: Most are irrelevant. The point is not to transport the patch to Alexandre. If so, you might as well send it directly to him. Point is to get peer review, and maybe comments. For this purpose, inlining the patch is the preferred methods, hands down. Reasons have been hashed already multiple time, please read the archives. There are good reasons why people with a lot of experience handling patches (e.g. Alexandre, Linus, etc.) prefer this method. -- Dimi.

Oct. 31, 2002

Re: Wine securityflaw.

by David Fraser

Geoff Thorpe wrote: >On Thursday 31 Oct 2002 10:00 am, Greg Turner wrote: > > >>On Thursday 31 October 2002 08:10 am, Raul Dias wrote: >> >> >>>My $0.02, >>> >>>A way to make it more secure is to catch key API calls and decide if >>>the application is allowed to run it or not. >>> >>> >>not a bad idea. >> >> >> >>>Wine could implement a clean Security Layer: YES >>> >>> >>Clean, perhaps, but secure? That depends on what you are trying to >>achieve: since the unix API is available to apps running under wine, >> >> > >This subject interests me a great deal so please humour me as I try to >wrap my head around the wine-specifics well enough to get an >accurate(ish) picture of this. I'm a security person, but no win32 >expert and even less of a PE/ELF hacker... > >First I can understand the point made that, at the end of the day, the >only *actual* security you can force on a wine-loaded application is >whatever security the operating system forces on *all* applications >(wine-loaded or otherwise) running as the same user. Ie. even if a win32 >application loaded under wine couldn't directly call ioctl(), unlink(), >or fopen(), the binary code could still *reimplement* those functions in >assembly. I also realise that other assembly hacks (or just >trail-and-error "luck" virii) could scan the process's memory space >looking for likely function pointers, file-descriptors, etc and start >meddling with them directly to bypass the wine-implemented win32 API. >Does that seem a reasonable understanding of the situation? > >My next question is this: why is the unix API available to >wine-loaded PE apps/libs? I can't see a single compelling reason for >this, though I'm prepared to be illuminated otherwise. If we discard >memory-scanning and other assembly tricks for a moment and consider just >the case of PE apps/libs generated from "clean C" (and "clean >compilers"); then preventing any direct binding of any wine-loaded PE >images to native ELF images, *except* those implemented by wine, >immediately raises the bar. Of course, I'm assuming this is *possible* >with the PE (and ELF) format(s)? > >My problem with discarding the "clean" security layer because it isn't >perfectly impenetrable in a technical sense, is that it is purely an >abstract technical-only view of things, and Wine's role (and >threat-model for its future success) is anything but purely technical. >Jeremy, I'd be particularly interested if you have any thoughts on this. >AFAICS, this idea is not just a question of security by obscurity - >there are technical and "political" issues involved too. > >First, not linking PE images to non-wine ELF images allows one to define >a security policy in wine for win32/PE executable code akin to a "rules >for Win32 programs" config. One possibility here is the kind of thing >Raul was discussing. Buggy programs aren't programs that try to detect >if they're running in wine and if so do damage - buggy programs are >programs using the win32 API written by careless win32 bunnies. *Those* >programs could be subject to a policy configuration that would allow you >to selectively restrict things in a way that will *always* be better >than what MS-windows provides - whether the programs are horribly buggy >or really solid. In other words, a configurable real-world >control/protection against potentially buggy win32 code (that would be >equally buggy on MS-windows and Wine after all). > >Second, if the PE loader doesn't blindly link PE apps/libs to native >libraries, then bypassing the wine-implemented win32 API (and thus the >policy configuration) would require an *explicit* workaround on the part >of the programmer. Putting in assembly code to prime registers and fire >interrupts that (a) on linux would getenv("HOME") and unlink() the >result, and (b) on windows would probably just crash with a BSOD is what >the security community call a "virus". :-) It doesn't have to be >difficult for the programmer to do it, it just has to require him/her to >be malicious and unambiguously *intend* to do it. Writing and >distributing one of these things opens you up to criminal prosecution in >many jurisdictions, and also allows McAfee and friends to assign a >signature to corresponding binaries and get them classified as a virus >(and their authors classified as bad people). > >Or put another way - as Wine converges on "beta" or "release" level and >Wine + XXX/OS (where XXX=Linux,FreeBSD,etc) becomes not only a >competitor to MS-windows, but in fact offers considerable advantages, >where then will the *threats* to wine lie?? I would certainly like to >(a) see the flexibility of being able to apply a "soft" security policy >for win32 applications in the wine-implemented win32 API, (b) force >win32 developers who are "anti-wine" and "pro-monopoly" to have to >expose themselves to criminal possibilites if they want to bypass >wine-based execution configuration and controls (or worse, if they want >to package anti-wine trojans). > > > >>So, for example, this could be used to protect a system against >>security flaws in Internet Exploder or Outlook... but a malicious virus >>writer could work around winapi-based security provisions, as discussed >>earlier in this thread. >> >> > >Yes, and I think the point that's worth making is that writing a >malicious virus against wine is not only a crime in the sense that >normal virus-writing is a crime, but also has >anti-trust/anti-competition overtones ... when you try to imagine which >companies would most like their win32-based applications to *NOT* run on >wine (and perhaps even hurt wine users), you might understand where I'm >coming from. > >In lieu of "pure" security enforcements (which would require >virtualisation anyway which Wine is not in the business of), I think a >"win32-API-based" security approach is worthwhile. If I can write win32 >apps that link directly to libc, I could elect to replace the >file-management subsystem of my app with a POSIXy layer that is only >used on wine "for performance reasons only, honest!". This would mean >(a) Wine's file-system configuration can be bypassed, and (b) I could >(perhaps deliberately) embed nasty corruption bugs in my POSIX subsystem >but have my win32 subsystem very stable. This program would just be >"unstable on wine" but not "anti-competitive" nor "criminal". But if you >don't let applications do this in wine's PE-loader (or at least let it >be controllable in the config) then acheiving the same result would >require me to write a genuine virus instead (and so open myself to >anti-trust/criminal accusations). > >Thoughts? > >Cheers, >Geoff > > I think this is missing the point. The way to make something secure isn't to make big software companies worry about anti-trust, or virus writers worry they might get sued for writing a virus. Big companies aren't likely to write wine-specific special workarounds that do nasty things, and virus writers couldn't care less. Any security improvements should be normal UNIX ideas like letting a wineserver do certain priviledged tasks running as a special user, while standard wine programs run as a different, non-priviledged user. In other words, the kernel layer in Windows should have higher priveledges than standard user processes, but not run as root. David

Oct. 31, 2002

Re: SetWindowHookEx

by Shachar Shemesh

I sent Alexandre the App privately. I originally wanted to CC the list (the app can be distributed under either GPL or LGPL), but the mail was rejected. I would hereby like to appologize for trying to attach more than the set limit of 40Kb of a zip file to the list. My appologies. In leu of such atrocities which I would not like to commit, and I would like to thank the moderator for stopping that mail, I have placed on a web site, and am hereby making both source and a compiled binary available in a zip file (no wonder it was more than 40Kb, what was I thinking trying to send it to the list) at http://www.consumer.org.il/personal/xeyes.zip. D/L size is 49Kb. Thanks, Shachar Alexandre Julliard wrote: >Shachar Shemesh <wine-devel(a)sun.consumer.org.il> writes: > > > >>So you mean to say that my windows X-Eyes implementation won't work on >>WINE????? Damn. >> >>Anyone knows of any Unix port of that program? >> >> Shachar >> >>No, wait. I'm using a mouse hook. Maybe it'll work after all. >> >> > >At this point probably not, but if you could send me that app I'd be >interested to play with it. > > >

Oct. 31, 2002

Re: So lets say we do it

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > On October 31, 2002 11:24 am, Alexandre Julliard wrote: > > First it doesn't even start because they don't have a config file. OK, > > Hear, hear! BTW, we should move configuration out of documentation/samples I don't think that would really help rpm users... IMO the whole concept is flawed (try editing the config while the wineserver is still running ;) configuration should be stored in the registry and there should be control panel applets to configure the various parts of Wine, which would allow changing things on the fly. 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. -- Alexandre Julliard julliard(a)winehq.com

Oct. 31, 2002

RE: winapi_check question...

by Patrik Stridvall

> On Thursday 31 October 2002 09:20 am, Patrik Stridvall wrote: > > Greg wrote: > > > winapi_check tells me: > > > > > > ndr_stubless.c:86: rpcrt4: LONG_PTR WINAPIV > > > NdrClientCall2(PMIDL_STUB_DESC,PFORMAT_STRING,...): argument 1 > > > documentation: \ > > > /* CLIENT_CALL_RETURN */ > > > > This is because winapi_check misparser the line: > > LONG_PTR /* CLIENT_CALL_RETURN */ > > RPCRT4_NdrClientCall2(PMIDL_STUB_DESC pStubDesc, PFORMAT_STRING > > pFormat, va_list args) > > > > Ignore it. > > OK. You promise it won't screw up the actual documentation bot? Promise? Hmm. All code have bugs you know and winapi_check is designed to be ad hoc and thus inherently buggy... :-) But seriously, I wouldn't worry about it. Anyway. A real fix to the code you be nice. Presumable the type CLIENT_CALL_RETURN haven't been declared properly. > > > how shall I deal with these? > > > > Fix them as above or do as everybody elses do wait for me to fix it. > > :-) > > heh. Well, maybe I can set an example for those deadbeats :) :-)

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Greg Turner

On Thursday 31 October 2002 12:04 pm, Jaco Greeff wrote: > On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes > > And plain inlined patches are preferred against attachments. Just rabble-rousing here, but, until Alexandre stops accepting them, I plan to attach all my patches. I /am/ willing to mark them as "prefer inline display" or whatever it's called, which my mailer lets me do, but personally, I prefer not even to do this unless they're very, very small (one hunk). Since I've been doing lots of bullet-lists lately, here's a couple more: In support of attached patches: o Easier to separate out and organize in a filesystem o Less likely to munge international characters o No possibility to confuse carriage-returns from the e-mail with carriage-returns from the patch o Easier to view with syntax highlighting o Usually not automatically included in replies o Specifies a file-name for the patch o Doesn't /ever/ line-wrap (!) o No cut-and-paste to apply the patch o Allows us to turn on auto-line wrapping in our e-mail clients, which, in turn, makes wine-devel more readable (sometimes). o pretty icons in some clients ;) In support of inline patches o easier to read for some people I say, tough cookies. Stop using elm (or yahoo) and get a real reader :P (evil haloween laughter) -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

Oct. 31, 2002

Re: SIGSEGV in IDirectDrawImpl_EnumDisplayModes

by Lionel Ulmer

> Sorry, that was the method I posted, I happened to paste the wrong function > name; this is the entire function with line 852 marked: Care to give me the actual data type of 'mp_directDraw' ? It seems that as you supposed, it does not use the correct function pointer when you use 'mp_directDraw->CreateSurface' and call instead 'EnumDisplayModes' thus, of course, leading to a crash as the callback function is not filled in properly. The only thing I find strange is that you call CreateSurface with the 3rd argument being NULL and we should see that in the trace for 'EnumDisplayModes'... Lionel -- Lionel Ulmer - http://www.bbrox.org/

Oct. 31, 2002

Re: So lets say we do it

by Rick Romero

On Thu, 2002-10-31 at 12:19, Dimitrie O. Paun wrote: > On October 31, 2002 11:24 am, Alexandre Julliard wrote: > > You forgot a few things here: > > > [...] it doesn't work because the drives are wrong. > > Yep. wineinstall? > > > Then they don't have the proper registry (winedefault.reg? what's that?) > > :))) > I hate to jump in again, but isn't wine a little backwards from other releases when dealing with a fresh tar.gz install? I realize wineinstall will do the work for you, but aren't people just used to ./configure - make - make install? I think they do that, then they're stuck. configure always tells you to do a 'make depend && make', why not throw in a little blrub "Hey, if you're running this for the first time, run wineinstall instead." ? Or is wineinstall not doing what I think it is (setting up initial environment)? Ok, I'll be quiet for a few months again :) Rick > -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 Rick(a)valeoinc.com

Oct. 31, 2002

Some other problems ...

by Paul Millar

Hi everyone, Just a couple of problems I've noticed. They look like they're due to some broken build dependencies. 1. I have a copy of wine on my laptop which I do "cvs update" every few days. After updating today, I did the usual "./configure --enable-opengl && make depend && make" and left it to compile. But, when I tried the result, I got a client/server mismatch for SERVER_PROTOCOL_VERSION. One was claimed to be v88 whilst the other was v89. Doing a "make distclean" then repeating the build "fixed" the problem. Patch http://cvs.winehq.com/patch.py?id=6064 (committed last Tuesday) bumped the SERVER_PROTOCOL_VERSION up to 89. So it looks like some of the binaries weren't updated during the build. I tried altering the version (manually) and rebuilding, but wine rebuilt correctly. 2. WRT hit a problem last night where "make test" failed. The log included messages like: gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -D_REENTRANT -o registry.o registry.c LD_LIBRARY_PATH="../../../library:../../../unicode:$LD_LIBRARY_PATH" ../../../tools/winebuild/winebuild -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -o advapi32_test.exe.spec.c -exe advapi32_test.exe -mcui registry.o testlist.o -L../../../dlls -ladvapi32 -lkernel32 -lntdll gcc -shared -Wl,-Bsymbolic advapi32_test.exe.spec.o registry.o testlist.o -o advapi32_test.exe.so -L../../../library -lwine -lm advapi32_test.exe.spec.o: In function `__wine_exe_main': /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/advapi32_test.exe.spec.c:116: undefined reference to `main' registry.o: In function `test_enum_value': /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:69: undefined reference to `winetest_set_ok_location' /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:69: undefined reference to `winetest_ok' /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:78: undefined reference to `winetest_set_ok_location' [... etc ...] The later build had six tests that succeded. These were the new scanf tests introduced into that build by patch http://cvs.winehq.com/patch.py?id=6107 I've just done a "make distclean" followed by a normal rebuild and test. Its currently running through the regression tests, but so far it seems to be working. These are vague reports of unrepeatable problems ... never a good thing! I'm quite busy right now (real work and everything), so I don't have time to investigate this myself. Just posting this hoping the cause its obvious to someone else :^) ---- Paul Millar

Oct. 31, 2002

Re: So lets say we do it

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > On October 31, 2002 11:40 am, Carlos Lozano wrote: > > 10th Anniversary (??-??-2003)? sounds to a good date. > > Cool! :) Alexandre, when is that? Sometime in June, I don't have the exact date of the first release unfortunately. Release 0.0.2 was on June 25. -- Alexandre Julliard julliard(a)winehq.com

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 11:24 am, Alexandre Julliard wrote: > You forgot a few things here: Yes, and no: it was getting late, hand was all funny, email was getting too long... :) > First it doesn't even start because they don't have a config file. OK, Hear, hear! BTW, we should move configuration out of documentation/samples > [...] it doesn't work because the drives are wrong. Yep. wineinstall? > Then they don't have the proper registry (winedefault.reg? what's that?) :))) > Then they finally manage to run the installer but it > puts stuff in RunOnce that never gets run so the app doesn't work. See, I wasn't even aware of that! > Then they finally make the app run but can't print anything. And True. > when they ask for help they get told to fight the FAQ-O-Matic crap to > maybe finally find an answer telling them they are an idiot. That FAQ-O-Matic should just be 'rm -rf'. It's crap. We either have a carefully hand-written FAQ, or nothing at all. > So no, I'm not going to make a general public release just yet... I am not even suggesting it. I just went through the exercise so we can extract a TODO... -- Dimi.

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Jaco Greeff

On Thu Oct 31 20:04:30 2002, "Jaco Greeff" <jaco(a)puxedo.org> wrote : > On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes > <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote : > > Jaco> ... Tests that will fail > > Jaco> with current implementation are temporarily commented out > > > > Don't comment them out, matrk them "todo". Look at the syntax in > > documentation/testing. > > I've marked the code with a "FIXME". Sorry, I misunderstood the first time around, will something like todo("linux") { do(something() == 1, "whatever"); } do the trick? But unsure about the definition I should use, I can see "cygwin", "freebsd", etc. This one will fail on all non-Windows platforms. Greetings, Jaco

Oct. 31, 2002

Re: Wine securityflaw.

by Geoff Thorpe

On Thursday 31 Oct 2002 10:00 am, Greg Turner wrote: > On Thursday 31 October 2002 08:10 am, Raul Dias wrote: > > My $0.02, > > > > A way to make it more secure is to catch key API calls and decide if > > the application is allowed to run it or not. > > not a bad idea. > > > Wine could implement a clean Security Layer: YES > > Clean, perhaps, but secure? That depends on what you are trying to > achieve: since the unix API is available to apps running under wine, This subject interests me a great deal so please humour me as I try to wrap my head around the wine-specifics well enough to get an accurate(ish) picture of this. I'm a security person, but no win32 expert and even less of a PE/ELF hacker... First I can understand the point made that, at the end of the day, the only *actual* security you can force on a wine-loaded application is whatever security the operating system forces on *all* applications (wine-loaded or otherwise) running as the same user. Ie. even if a win32 application loaded under wine couldn't directly call ioctl(), unlink(), or fopen(), the binary code could still *reimplement* those functions in assembly. I also realise that other assembly hacks (or just trail-and-error "luck" virii) could scan the process's memory space looking for likely function pointers, file-descriptors, etc and start meddling with them directly to bypass the wine-implemented win32 API. Does that seem a reasonable understanding of the situation? My next question is this: why is the unix API available to wine-loaded PE apps/libs? I can't see a single compelling reason for this, though I'm prepared to be illuminated otherwise. If we discard memory-scanning and other assembly tricks for a moment and consider just the case of PE apps/libs generated from "clean C" (and "clean compilers"); then preventing any direct binding of any wine-loaded PE images to native ELF images, *except* those implemented by wine, immediately raises the bar. Of course, I'm assuming this is *possible* with the PE (and ELF) format(s)? My problem with discarding the "clean" security layer because it isn't perfectly impenetrable in a technical sense, is that it is purely an abstract technical-only view of things, and Wine's role (and threat-model for its future success) is anything but purely technical. Jeremy, I'd be particularly interested if you have any thoughts on this. AFAICS, this idea is not just a question of security by obscurity - there are technical and "political" issues involved too. First, not linking PE images to non-wine ELF images allows one to define a security policy in wine for win32/PE executable code akin to a "rules for Win32 programs" config. One possibility here is the kind of thing Raul was discussing. Buggy programs aren't programs that try to detect if they're running in wine and if so do damage - buggy programs are programs using the win32 API written by careless win32 bunnies. *Those* programs could be subject to a policy configuration that would allow you to selectively restrict things in a way that will *always* be better than what MS-windows provides - whether the programs are horribly buggy or really solid. In other words, a configurable real-world control/protection against potentially buggy win32 code (that would be equally buggy on MS-windows and Wine after all). Second, if the PE loader doesn't blindly link PE apps/libs to native libraries, then bypassing the wine-implemented win32 API (and thus the policy configuration) would require an *explicit* workaround on the part of the programmer. Putting in assembly code to prime registers and fire interrupts that (a) on linux would getenv("HOME") and unlink() the result, and (b) on windows would probably just crash with a BSOD is what the security community call a "virus". :-) It doesn't have to be difficult for the programmer to do it, it just has to require him/her to be malicious and unambiguously *intend* to do it. Writing and distributing one of these things opens you up to criminal prosecution in many jurisdictions, and also allows McAfee and friends to assign a signature to corresponding binaries and get them classified as a virus (and their authors classified as bad people). Or put another way - as Wine converges on "beta" or "release" level and Wine + XXX/OS (where XXX=Linux,FreeBSD,etc) becomes not only a competitor to MS-windows, but in fact offers considerable advantages, where then will the *threats* to wine lie?? I would certainly like to (a) see the flexibility of being able to apply a "soft" security policy for win32 applications in the wine-implemented win32 API, (b) force win32 developers who are "anti-wine" and "pro-monopoly" to have to expose themselves to criminal possibilites if they want to bypass wine-based execution configuration and controls (or worse, if they want to package anti-wine trojans). > So, for example, this could be used to protect a system against > security flaws in Internet Exploder or Outlook... but a malicious virus > writer could work around winapi-based security provisions, as discussed > earlier in this thread. Yes, and I think the point that's worth making is that writing a malicious virus against wine is not only a crime in the sense that normal virus-writing is a crime, but also has anti-trust/anti-competition overtones ... when you try to imagine which companies would most like their win32-based applications to *NOT* run on wine (and perhaps even hurt wine users), you might understand where I'm coming from. In lieu of "pure" security enforcements (which would require virtualisation anyway which Wine is not in the business of), I think a "win32-API-based" security approach is worthwhile. If I can write win32 apps that link directly to libc, I could elect to replace the file-management subsystem of my app with a POSIXy layer that is only used on wine "for performance reasons only, honest!". This would mean (a) Wine's file-system configuration can be bypassed, and (b) I could (perhaps deliberately) embed nasty corruption bugs in my POSIX subsystem but have my win32 subsystem very stable. This program would just be "unstable on wine" but not "anti-competitive" nor "criminal". But if you don't let applications do this in wine's PE-loader (or at least let it be controllable in the config) then acheiving the same result would require me to write a genuine virus instead (and so open myself to anti-trust/criminal accusations). Thoughts? Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Jaco Greeff

On Thu, 31 Oct 2002 11:04:48 -0600, Greg Turner <gmturner007(a)ameritech.net> wrote : > On Thursday 31 October 2002 10:34 am, Jaco Greeff wrote: > > - Tests that will fail with current implementation are temporarily > > commented out > > Is there a middle ground for tests that are expected to fail? If not, > IMO maybe there should be: It kinda defeats the purpose of a test > framework if we just comment out tests that don't work... Agreed. It will pass shortly though :) At this point the test will help anybody wishing to verify my latest msvcrt patch. Plus, it really should pass. The part that does fail is on Unicode printing, which give me one of a few choices: 1. Don't send in a test; 2. Be stubborn and let the test fail for everybody doing a make test; 3. Send in a really crippled test case; 4. Combination of 3 + 4 so people can easily have the framework to test if progress have been made. That is the reason why I've commented it out, hopefully shortly it will be fully featured. Greetings, Jaco

Oct. 31, 2002

Re: So lets say we do it

by Marcus Meissner

On Thu, Oct 31, 2002 at 08:24:28AM -0800, Alexandre Julliard wrote: > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > So the 5% left, install wine, install a Win-app, and play around. > > Great, it works! > > You forgot a few things here: As for the SuSE wine RPMS: > First it doesn't even start because they don't have a config file. OK, > they copy one from somewhere, it doesn't work because the drives are > wrong. Been there, done that. Not very good, it is still using winesetuptk which might be too much in way of configuration. > Then they don't have the proper registry (winedefault.reg? > what's that?) Merged automatically with startup script. > Then they finally manage to run the installer but it > puts stuff in RunOnce that never gets run so the app doesn't > work. Ok, this one is still missing. > Then they finally make the app run but can't print anything. Two edged sword. CUPS works fine here, however if all applications are ready to print with WINEPS and winspool.drv is another issue. > And > when they ask for help they get told to fight the FAQ-O-Matic crap to > maybe finally find an answer telling them they are an idiot. Yep. But this one is harder, what do you think needs to be there? > So no, I'm not going to make a general public release just yet... Not yet too late for another 'Halloween' release though ;) Ciao, Marcus

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Jaco Greeff

On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote : > Jaco> ... Tests that will fail > Jaco> with current implementation are temporarily commented out > > Don't comment them out, matrk them "todo". Look at the syntax in > documentation/testing. I've marked the code with a "FIXME". I don't want the test sequence to fail for this issue which is solved by my msvcrt patch. The way I've done it allows others to verify the new vfprintf patch with minimal work. > And plain inlined patches are preferred against attachments. I'm doing this via a mail web interface, it has the ugly habit of doing line-wraps. I also prefer inline patches (like to see what is going on without have to save etc.), it is just not entirely possible for me at this point. *sigh* Greetings, Jaco

Oct. 31, 2002

Re: So lets say we do it

by Dimitrie O. Paun

On October 31, 2002 11:40 am, Carlos Lozano wrote: > 10th Anniversary (??-??-2003)? sounds to a good date. Cool! :) Alexandre, when is that? -- Dimi.

Oct. 31, 2002

Re: dlls/msvcrt/tests: printf

by Greg Turner

On Thursday 31 October 2002 10:34 am, Jaco Greeff wrote: > - Tests that will fail with current implementation are temporarily > commented out Is there a middle ground for tests that are expected to fail? If not, IMO maybe there should be: It kinda defeats the purpose of a test framework if we just comment out tests that don't work... but OTOH, its pretty unfair to the other tests to have the whole "make test" fail because of some known issue. -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

Oct. 31, 2002