Re: How is Win/Dos syscalls implemented in Wine?
Well, while I agree with the general sentiment, this is technically not quite right. In i386 protected mode, you cannot jump directly to code with a different privilege level (it'd cause a GPF/SIGSEGV to try), it must be done through a gate (typically an interrupt). Passing through such a privilege-transition gate also implies switching to a similarly-privileged stack (before the return address is pushed), so you cannot push your own return address onto the kernel's privileged stack. And you probably can't even get the address of the kernel interrupt handler (the IDT can be protected from being read). This doesn't make Wine any more secure though, of course... I wasn't talking about jumping directly into the kernel I was referring to the trusted/untrusted DLL part. the int 80h instruction was in trusted code. I was trying to show that trusting DLLs (or code pages) to allow/disallow syscalls could be rather easily circumvented and was offering no protection (trusted int 80h insn in trusted code could be used easily by untrusted code) A+
Re: Segmentation Fault
Any extra command-line options that I should put on winedbg to help find out the problem? no. it seems however that: - debug info is not found. Either you did remove -g flags from compilation, or you have two wine trees (or installation), and lookup isn't done on the right tree (install) - your application dies before the debugger did finish its startup. you could also try to run your app from the debugger (winedbg your_app instead of wine your_app) what's strange however, if your wine always crashes at startup, how come winedbg can actually start up. something's really strange in your configuration A+
Re: How is Win/Dos syscalls implemented in Wine?
Sylvain Petreolle a écrit : I disagree here. one anti debug / hiding technique is : 1)set regs 1a) push 3) location on the stack. 2) jump to 80h then the iret instruction in int 80h will jump to 3) agreed (devil is in details) A+
Re: Wine securityflaw.
On Saturday 26 October 2002 11:43 pm, Francois Gouget wrote: On Sat, 26 Oct 2002, Greg Turner wrote: That is, wine emulates an OS with no security measures at the filesystem level, no security policy regarding what API's can be called (except as provided by the CPU itself), and so on. I agree that there is a problem of perception so I will quickly clarify the above sentence, lest it be mis-interpreted and contribute to that perception problem. When reading 'wine emulates an OS with no security measures at the filesystem level' I think most people will think that Windows applications running under Wine can read and modify any file on the Unix system, including system files and files not belonging to the user running the application. This is of course not the case! good call. thanks for that clarification. (however I will quickly point out that the NT security model suffers from a serious design flaw which lets processes escalate privileges in a way which is currently simply impossible in Wine, for more details see http://security.tombom.co.uk/shatter.html) seen this one, too. interesting article; there's an even more interesting follow up at http://security.tombom.co.uk/moreshatter.html. If were very careful to do everything just like windows I think we could reproduce these flaws in a year or two :) At http://security.tombom.co.uk/aboutfoon.html, the author (who calls himself Foon) boasts Able to program in 23 languages on 14 platforms, Foon takes an average of 3 days to learn a new programming language. ... That means he's spent exactly 69 days learning programming languages en toto. AFAIK the Win32 API (unlike the Unix API, see chroot) does not make it possible to prevent a process from accessing or modifying files belonging to the current user. This is another argument for a permissions mapping scheme instead of direct translation of Unix permissions to wine permissions, as I see it. Of course, this leads us back to the Wine Is Not an Emulator problem as previously discussed... so I guess I'm going in mental circles and, in a sense, contradicting myself... time to shut up and get back to work on RPC :) -- gmt The purpose of government is to rein in the rights of the people --President Bill Clinton, MTV interview, 1993
Re: dlls/user: w[v]snprintf[A|W] fixes
On 26 Oct 2002 14:57:53 -0700, Alexandre Julliard [EMAIL PROTECTED] wrote : The size is supposed to be hardcoded to 1024, that's how wsprintf works. You can't make it dynamic since the buffer is allocated by the application. From MSDN: Pointer to a buffer to receive the formatted output. The maximum size of the buffer is 1024 bytes. The question I need to ask myself now is what function reference did I compare this one to when I searched there?
Re: dlls/user: w[v]snprintf[A|W] fixes
Changelog: * dlls/user/wsprintf.c Jaco Greeff [EMAIL PROTECTED] - Changed the wsprintf[A|W] and wvsprintf[A|W] functions to determine the size of the destination buffer before writing to it. Previously the size was hardcoded to 1024 bytes. The size is supposed to be hardcoded to 1024, that's how wsprintf works. You can't make it dynamic since the buffer is allocated by the application. Seems to me (from info in a later post) that M$ wsprintf uses an internal temporary buffer that has a size of 1024 - thus resticting the user to a buffer size of 1024, The actual size of the user buffer cannot be determined - hence the common 'buffer overflow' issues with sprintf. The C standard now includes snprintf() where the application passes in the length of the target buffer. I guess M$ might follow :-) Some systems also have an asprintf() routine which will malloc() a buffer that the caller must free(). David -- David Laight: [EMAIL PROTECTED]
Re: License query
On Sunday 27 October 2002 01:56, you wrote: Matthew Bloch [EMAIL PROTECTED] writes: I'm porting a closed-source game to Linux, and as a stop-gap I'd like to get a version out using WINE until I can rewrite the Direct(Sound|Draw|3D) backends with SDL. After reading this post: http://lists.debian.org/debian-devel/2002/debian-devel-200205/msg02823.ht ml and then downloading the source from the winehq.com cvs, I'm confused as to my options. The LICENSE file implies that the ddraw DLL is transgaming's IP but the files themselves have LGPL declarations at the top. Everything in the winehq.com tree is under LGPL, and there is nothing in the LICENSE file about ddraw, it looks like you are confusing it with the one from the Transgaming tree. So if you want only LGPL code, make sure you only check things out from winehq.com. You're right, I still had the winex sources hanging around which was what confused me. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
Re: Wine securityflaw.
What is it with you people? I was just trying to make a point about the security risks about using wine at present. And you start flameing me? Instead of continuing this flame war I will try to express myself more clearly. Before I go into details of my idea, lets make a few things clear... I agree that focus of the Wines project, should be more towards running windows applications than on extreme security. I also agree that securing an environment usually means reducing the freedom and flexibility to do things. My intention was that some security should be offered in wine regarding the attacks. This would not neccesary need to be a mandatory solution, it should IMHO be an easily configured on/off option feature. My idea is to use ptrace in a supervisor process to trap all syscalls from the wine process, and use some kind of sanity checks for some of the syscalls. Watching the fork,exec,open,write and unlink syscalls and doing sanity checks could offer atleast some security. Could this work? Do you see this as a useful option? //Peter On Sunday 27 October 2002 03.06, Francois Gouget wrote: On Sun, 27 Oct 2002, Peter Andersson wrote: [...] I believe most wine users trust wine not to touch anything outside of its configured drive space. Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage. After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected. The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt. [...more snipped...] Certainly I would be surprised to see a Wine-aware virus tomorrow. In that sense I certainly would not expect this sort of thing to happen tomorrow. But you seem to be confused about the goal of Wine. The goal of Wine is to run Windows applications on Unix. Windows applications run through Wine should be able to do no more and no less than any other Linux application. Thus Wine is not more of a security risk than any other piece of (somewhat alpha) software. But the goal of Wine is *not* to build a sandbox or a virtual machine in which you can safely run malicious code. If that is what you want, then you should look at chroot, jail, User Mode Linux, VMWare or Plex86. You can even combine them with Wine to build sandboxes. For instance you could run Wine in a 'jail' environment and then a Wine-aware would be confined to that environment. That being said, yes it is possible to configure Wine such that Windows applications are confined to a small portion of your disk. It is a useful feature and, as far as I know, it should work against all current Windows viruses. Of course, when configured this way Wine is not very useable. You would not be able to use Word to edit your documents for instance... that is unless you menually copy the document to the Wine environment where any Windows virus will be able to munge it. You simply cannot have it both ways.
Re: How is Win/Dos syscalls implemented in Wine?
On Sun, 27 Oct 2002, Eric Pouech wrote: Well, while I agree with the general sentiment, this is technically not quite right. In i386 protected mode, you cannot jump directly to code with a different privilege level (it'd cause a GPF/SIGSEGV to try), it must be done through a gate (typically an interrupt). Passing through such a privilege-transition gate also implies switching to a similarly-privileged stack (before the return address is pushed), so you cannot push your own return address onto the kernel's privileged stack. And you probably can't even get the address of the kernel interrupt handler (the IDT can be protected from being read). This doesn't make Wine any more secure though, of course... I wasn't talking about jumping directly into the kernel Hm? I was replying to Sylvain, who was talking about that.
Re: Known listview bugs (take 2)
The fix in http://bugs.winehq.com/show_bug.cgi?id=924 looks good. Could sbd send it as a patch ? Thanks Juergen On Thu, 24 Oct 2002, Dimitrie O. Paun wrote: On October 24, 2002 04:00 pm, Francois Gouget wrote: Argh! I cheated. I used a slightly older Wine and copied the comctl32 dll there. Today I retested with CVS Wine plus the latest X11 patch and got it to work by just replacing the shell32 library with an older one Can you please search what broke shell32? This is Not Good (TM) Winzip was broken on 2002/07/23 by one of the following two patches: * http://cvs.winehq.com/patch.py?id=1027475763780155356581421 Juergen Schmied [EMAIL PROTECTED] - Cleaned up the implementation of shell folders and put them into separate files - Fixed some memory leaks - Some more fixes * http://cvs.winehq.com/patch.py?id=102747584224009388063951 Fixed duplication of definitions between shlwapi.h and obj_queryassociations.h I cannot compile Wine if I only apply the first one. I suspect there is a problem in the first one but unfortunately it is pretty large: ~4000 lines -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0 --- [EMAIL PROTECTED]
Re: How is Win/Dos syscalls implemented in Wine?
Hm? I was replying to Sylvain, who was talking about that. talking too much of security must have turned me paranoid ;-) A+
Re: Wine securityflaw.
On Sunday 27 October 2002 11:37, Peter Andersson wrote: What is it with you people? I was just trying to make a point about the security risks about using wine at present. And you start flameing me? I don't see any flames, just strong criticism of your idea for which you may not have thought all the issues through. WINE is not a sandbox as Alexandre pointed out, because writing a sandbox for any system is hard work: as proof look at the complexity of Valgrind, a program which emulates an x86-Linux system on top of another x86-Linux system for diagnostic purposes. Think how much harder it is to write the same kind of code for an OS when you've not got the same OS under your feet; it would be a slow-performing monster of a program. Given that WINE is not a sandbox, simplistically it's a translator of system calls binary formats, the risks of running a WINE-based program are exactly the same risks you run with any unknown binary code, so any checks on sanity of syscalls are better done in the kernel or general-purpose executable wrapper than in WINE specifically. I started a conceptually similar emulator project to WINE a while ago for another OS (riscose.sf.net): a program to run RISC OS binaries on Unix. The issues are the same: just because malicious code comes from an unfamiliar OS doesn't make its destructive capabilities any different from native code, so if you're looking to tighten security of WINE programs, look to the same methods you'd use to tighten security of *any* unknown program: run it as a different user, run it in a Usermode Linux instance (user-mode-linux.sf.net), use kernel patches to restrict its use of system calls. But WINE shouldn't be bothered with any of this. If you're interested in playing with this kind of work, I know someone has written a Python-based framework (called Subversion or Subterfuge or something like that, sorry, can't find a link...) which lets you run any Linux process with bits of Python code intercepting and changing or barring system calls on the fly. That could be used to prototype a much more general Linux security framework, and one that could be used for more projects than just WINE. cheers, -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026
Re: Wine securityflaw: Protect against root
Peter Andersson [EMAIL PROTECTED] writes: The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt. You should. If you run untrusted code under your account it can do anything that you are allowed to. This is exactly equivalent to running an untrusted Linux app. From a security standpoint there is absolutely no difference between a Windows binary running under Wine and a Linux binary running natively. You can use the DOS drive configuration to limit the potential problems a bug in a Windows app can cause; but it is impossible to protect against malicious code except by not running it. Wine is not, and cannot be, a sandbox for running untrusted code. Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens. No, we can't. I really agree that wine is safe enough. However, we should always remember that wine is bound to be used by former win users, who may have no concern about security. I often hear about people running wine as root or mapping '/' to a wine drive. I think that the wine code should protect the system from such _users_! Here is what I would do: Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a wine-developer will be able to cause wine to run as root. It has to be that hard to do so. We should then stop hearing claims that 'wine is unsafe'.
Re: Wine securityflaw: Protect against root
P. Christeas wrote: Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing. I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed). Since I know of no mail client for Linux that would set the X bit on an attachment, this would help protect users from themselves, while allowing those that need to be able to take the risks to do so. And as for making / available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now.
Re: Wine securityflaw: Protect against root
I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing. does rm have such an option ? rm doesn't, so I don't see any reason for this code bloat if you want to be paranoid (or you distro want to be), do it in wine script (or in the .winewrapper extension) I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed). that could bring some issues while trying to run a native executable from a mounted FAT driver (without the proper umask option for mount) (this could be circumvented by a drive configuration option in wine, but that would be a bit tricky to set for the average user) Since I know of no mail client for Linux that would set the X bit on an attachment, this would help protect users from themselves, while allowing those that need to be able to take the risks to do so. IMHO (regarding Klez), the main issue is the mail client not wine. It should protect/warn the user about this, not forward the blame on others And as for making / available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now. I think this a more interesting alternative. People did start working on that (especially for SMB shares mounting) A+
Re: It shouldn't be that easy
David D. Hagood wrote: P. Christeas wrote: Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing. I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed). Since I know of no mail client for Linux that would set the X bit on an attachment, this would help protect users from themselves, while allowing those that need to be able to take the risks to do so. And as for making / available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now. It should not be that easy. We can all understand that the 'klez' case wouln't have happened if wine had properly been configured. Windoze users are used to press 'OK' to all dialogs and grant privileges to any program asking for them. There is no practical reason a regular user would want to run Wine as root. That's what the *nix security model is all about. Wine developers should make sure there is no such need. The same applies for files. There is no reason a wine user would want to read/write protected files. If we make config available (the way you described it), wrong settings are bound to be made. We are just securing wine from its users.
Re: Wine securityflaw: Protect against root
Excuse me, but I don't think that any of these proposed methods will live up to any real malicious code. Personally, I believe we should make wine: A. Not require root B. As secure on it's own as possible (i.e. - not open to any problems not introduced by the hosted program). These two should allow securing Wine to the point where it is up to the packagers and to the people calling Wine to do their tasks, giving them the tools to do so. I don't believe we should, or even that we CAN, solve security problems introduced by insecure deployment. The only thing is that we should make secure deployment as easy as possible, not that we should make insecure deployment impossible. The later is both unobtainable, and will hurt usability. Shachar David D. Hagood wrote: P. Christeas wrote: Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing. I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed). Since I know of no mail client for Linux that would set the X bit on an attachment, this would help protect users from themselves, while allowing those that need to be able to take the risks to do so. And as for making / available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now.
Re: Wine securityflaw.
On October 27, 2002 06:37 am, Peter Andersson wrote: My idea is to use ptrace in a supervisor process to trap all syscalls from the wine process, and use some kind of sanity checks for some of the syscalls. Watching the fork,exec,open,write and unlink syscalls and doing sanity checks could offer atleast some security. Peter, You have not been flamed. Yet. But if you continue in this maner, you will. Really, the idea is silly. There is no 'security' issue. What you're talking about is nonsensical. So it would be a lot more productive to contemplate why this is so, rather than repeating the same stuff, over, and over. Could this work? No. Do you see this as a useful option? Absolutely not. The idea is so 'out there' that's almost hard to argue against it. Instead of 'some kind of sanity checks for some of the syscalls', please give us _ONE_ example of what those 'some's are. That is, describe an example of one sanity check, in one syscall. And we'll then tell you why that makes no sense. -- Dimi.
Re: Wine securityflaw: Protect against root
Eric Pouech wrote: does rm have such an option ? rm doesn't, so I don't see any reason for Actually, rm DOES have such an option: -i, --interactive prompt before any removal AND certain distros (RedHat for example) alias rm to rm -i by default. Also, I stated that the command line parameter to wine would be required to even start the process - in other words, if you didn't supply it, you would not get the dialog, wine would just terminate. AND, this would not necessarily have to be bloat in wine, it could be handled by a default wrapper - the wrapper checks UID and command flags, provides feedback if Wine needs to rebuild the font cache, etc. You represent one extreme of the spectrum - This isn't Wine's job, we shouldn't do anything. The other side - Wine should be safe. If things aren't safe, don't run, has also been represented here. I'm just suggesting a middle ground.
Re: Wine securityflaw: Protect against root
On Sun, Oct 27, 2002 at 07:51:01AM -0600, David D. Hagood wrote: I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed). Broken idea. This would stop any and all installers, as they first extract a compressed archive and then invoke *further* install helper programs. Windows is not Unix, period. That's why mapping to the X bit really doesn't make sense IMHO. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Wine securityflaw: Protect against root
Also, I stated that the command line parameter to wine would be required to even start the process - in other words, if you didn't supply it, you would not get the dialog, wine would just terminate. AND, this would not necessarily have to be bloat in wine, it could be handled by a default wrapper - the wrapper checks UID and command flags, provides feedback if Wine needs to rebuild the font cache, etc. that's what I suggested in my previous mail: 1/ don't do it inside wine binary 2/ if you really want to do it, do it from the wrapper (which is also well suited for distros specific configuration options) You represent one extreme of the spectrum - This isn't Wine's job, we shouldn't do anything. my point is: there is enough ways to do it (inside wine, inside linux...) to not need to add more stuff to wine binaries. what may lack indeed is the proper documentation (for packagers...) A+
Re: Known listview bugs (take 2)
El dom, 27 de oct de 2002, a las 13:14, Jürgen Schmied escribio: The fix in http://bugs.winehq.com/show_bug.cgi?id=924 looks good. Could sbd send it as a patch ? My patch with subject: (Day 26 oct) SHGFI_USEFILEATTRIBUTES support in SHGetFileInfoA fixes this problem (winzip is working again and really nice!!!) and some different issues relative to SHGFI_USEFILEATTRIBUTES. Regards, Carlos. -- ___ _ \ | / Infraestructuras | . |._ _ _| | ___ ___ ___http://www.andago.com | || ' |/ . |_ |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano ___'/ | \ -_) __/\__ \ -_) [ [EMAIL PROTECTED] ]\___|_| / _/\_\___| [ [EMAIL PROTECTED] ] http://www.epsxe.com
Re: Listview Z8
On October 27, 2002 11:28 am, Dimitrie O. Paun wrote: ChangeLog Mark immutable objects as const. Fix inconsisten *-style. This one, of course, is Z7, not Z8. Hmm, now I have problems with digits, on top of the alphabet... And NO, we used to do a _lot_ of math in Romania! :P -- Dimi.
Re: Listview Z8
Oh my god!!! he is running out of alphabet letters!!! ;-)
Shachar
Dimitrie O. Paun wrote:
ChangeLog
Mark immutable objects as const. Fix inconsisten *-style.
--- dlls/comctl32/listview.c.Z6 2002-10-27 10:29:52.0 -0500
+++ dlls/comctl32/listview.c 2002-10-27 11:24:45.0 -0500
-370,7 +370,7
static void LISTVIEW_GetOrigin(LISTVIEW_INFO *, LPPOINT);
static BOOL LISTVIEW_GetViewRect(LISTVIEW_INFO *, LPRECT);
static void LISTVIEW_SetGroupSelection(LISTVIEW_INFO *, INT);
-static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *, LPLVITEMW, BOOL);
+static BOOL LISTVIEW_SetItemT(LISTVIEW_INFO *, const LVITEMW *, BOOL);
static void LISTVIEW_UpdateScroll(LISTVIEW_INFO *);
static void LISTVIEW_SetSelection(LISTVIEW_INFO *, INT);
static void LISTVIEW_UpdateSize(LISTVIEW_INFO *);
-380,7 +380,7
static INT LISTVIEW_GetStringWidthT(LISTVIEW_INFO *, LPCWSTR, BOOL);
static BOOL LISTVIEW_KeySelection(LISTVIEW_INFO *, INT);
static UINT LISTVIEW_GetItemState(LISTVIEW_INFO *, INT, UINT);
-static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *, INT, LPLVITEMW);
+static BOOL LISTVIEW_SetItemState(LISTVIEW_INFO *, INT, const LVITEMW *);
static LRESULT LISTVIEW_VScroll(LISTVIEW_INFO *, INT, INT, HWND);
static LRESULT LISTVIEW_HScroll(LISTVIEW_INFO *, INT, INT, HWND);
static INT LISTVIEW_GetTopIndex(LISTVIEW_INFO *);
-469,7 +469,7
/*
* compares a Unicode to a Unicode/ANSI text string
*/
-static inline int textcmpWT(LPWSTR aw, LPWSTR bt, BOOL isW)
+static inline int textcmpWT(LPCWSTR aw, LPCWSTR bt, BOOL isW)
{
if (!aw) return bt ? -1 : 0;
if (!bt) return aw ? 1 : 0;
-517,7 +517,7
return buffers[index++ % DEBUG_BUFFERS];
}
-static inline char* debugrange(const RANGE* lprng)
+static inline char* debugrange(const RANGE *lprng)
{
if (lprng)
{
-527,7 +527,7
} else return (null);
}
-static inline char* debugpoint(const POINT* lppt)
+static inline char* debugpoint(const POINT *lppt)
{
if (lppt)
{
-537,7 +537,7
} else return (null);
}
-static inline char* debugrect(const RECT* rect)
+static inline char* debugrect(const RECT *rect)
{
if (rect)
{
-580,7 +580,7
return text;
}
-static char* debugnmlistview(LPNMLISTVIEW plvnm)
+static char* debugnmlistview(const NMLISTVIEW *plvnm)
{
if (plvnm)
{
-593,7 +593,7
} else return (null);
}
-static char* debuglvitem_t(LPLVITEMW lpLVItem, BOOL isW)
+static char* debuglvitem_t(const LVITEMW *lpLVItem, BOOL isW)
{
char* buf = debug_getbuf(), *text = buf;
int len, size = DEBUG_BUFFER_SIZE;
-629,7 +629,7
return text;
}
-static char* debuglvcolumn_t(LPLVCOLUMNW lpColumn, BOOL isW)
+static char* debuglvcolumn_t(const LVCOLUMNW *lpColumn, BOOL isW)
{
char* buf = debug_getbuf(), *text = buf;
int len, size = DEBUG_BUFFER_SIZE;
-670,7 +670,7
}
-static char* debuglvhittestinfo(LPLVHITTESTINFO lpht)
+static char* debuglvhittestinfo(const LVHITTESTINFO *lpht)
{
if (lpht)
{
-817,7 +817,7
return bResult;
}
-static void customdraw_fill(NMLVCUSTOMDRAW *lpnmlvcd, LISTVIEW_INFO *infoPtr, HDC hdc, LPRECT rcBounds)
+static void customdraw_fill(NMLVCUSTOMDRAW *lpnmlvcd, LISTVIEW_INFO *infoPtr, HDC hdc, const RECT *rcBounds)
{
ZeroMemory(lpnmlvcd, sizeof(NMLVCUSTOMDRAW));
lpnmlvcd-nmcd.hdc = hdc;
-1045,7 +1045,7
/***
* Creates an iterator over the items which intersect lprc.
*/
-static BOOL iterator_frameditems(ITERATOR* i, LISTVIEW_INFO* infoPtr, const RECT* lprc)
+static BOOL iterator_frameditems(ITERATOR* i, LISTVIEW_INFO* infoPtr, const RECT *lprc)
{
UINT uView = infoPtr-dwStyle LVS_TYPEMASK;
RECT frame = *lprc, rcItem, rcTemp;
-1130,7 +1130,7
/***
* Creates an iterator over the items which intersect the visible region of hdc.
*/
-static BOOL iterator_visibleitems(ITERATOR* i, LISTVIEW_INFO *infoPtr, HDC hdc)
+static BOOL iterator_visibleitems(ITERATOR *i, LISTVIEW_INFO *infoPtr, HDC hdc)
{
POINT Origin, Position;
RECT rcItem, rcClip;
-1705,7 +1705,7
* RETURN:
* None.
*/
-static void LISTVIEW_GetItemMetrics(LISTVIEW_INFO *infoPtr, LVITEMW *lpLVItem,
+static void LISTVIEW_GetItemMetrics(LISTVIEW_INFO *infoPtr, const LVITEMW *lpLVItem,
LPRECT lprcBox, LPRECT lprcState,
LPRECT lprcIcon, LPRECT lprcLabel)
{
-2018,7 +2018,7
* Success: TRUE
* Failure: FALSE
*/
-static BOOL LISTVIEW_MoveIconTo(LISTVIEW_INFO *infoPtr, INT nItem, LPPOINT lppt, BOOL isNew)
+static BOOL LISTVIEW_MoveIconTo(LISTVIEW_INFO *infoPtr, INT nItem, const POINT *lppt, BOOL isNew)
{
POINT old;
-3039,7 +3039,7
/***
* Tests wheather the item is assignable to a list with style lStyle
*/
-static inline BOOL is_assignable_item(LPLVITEMW lpLVItem, LONG lStyle)
+static inline BOOL is_assignable_item(const LVITEMW *lpLVItem, LONG lStyle)
{
if ( (lpLVItem-mask LVIF_TEXT)
(lpLVItem-pszText == LPSTR_TEXTCALLBACKW)
-3064,7 +3064,7
* SUCCESS : TRUE
* FAILURE : FALSE
*/
-static BOOL set_main_item(LISTVIEW_INFO *infoPtr, LPLVITEMW
Re: Listview Z8
On October 27, 2002 12:05 pm, Shachar Shemesh wrote: Oh my god!!! he is running out of alphabet letters!!! ;-) That's right. And we don't know what's going to happen, it's uncharted territory. So if you have listview problems, speak now!!! :) -- Dimi.
Re: Listview Z8
On October 27, 2002 12:14 pm, Shachar Shemesh wrote: àáâãäåæçèéëìîðñòôö÷øùú. Very useful `-) Very cool man, but, ..., hmm, ..., I don't have a Hebrew keyboard. ;) -- Dimi.
Re: Listview Z8
On Sun, Oct 27, 2002 at 07:14:41PM +0200, Shachar Shemesh wrote: I can offer you the Hebrew alphabet. Except à (Aleph), which was used to indicate the various infiinity levels, there are 21 brand new, never before used, ready for your viewing pleasure letters (the number grows to 26+aleph=27 if you want to count the different forms a letter may take, depending on it's place in the word). àáâãäåæçèéëìîðñòôö÷øùú. Very useful `-) What a weak and useless suggestion, this will run out of characters in no time at all ;-) Better use Chinese characters ! And if even those run out, then use Complex Chinese instead of Simplified Chinese ;-)) -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Found problem-causing patch for treeview
Ok, I finally found the patch that is causing treeview to not work on StarCraft (see bug #1073 for more info and the debug output) The hypermail link to the patch is: http://www.winehq.com/hypermail/wine-cvs/2002/03/0070.html I'm not sure which part of the patch caused it but that is the one causing it because cvs 1 second before that patch works fine, cvs the second of the patch does not. If someone could take a look at it and the debug output I would greatly appreciate it. I believe that this bug may also be whats causing native regedit to not show anything, but I'm not sure, that one could be listview related. -Dustin __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
Re: Found problem-causing patch for treeview
On Sunday 27 October 2002 01:23 pm, Dustin Navea wrote: I believe that this bug may also be whats causing native regedit to not show anything, but I'm not sure, that one could be listview related. It's listview related and fixed by Z0-6 (last I tested). -- gmt The purpose of government is to rein in the rights of the people --President Bill Clinton, MTV interview, 1993
search for Slava Monich
Hello I used to work with Slava Monich in the period 1992-1997 thereabouts. I am interested to find him now. I found his name on some Wine web pages from Google search on his name and after not finding anything furthermore specific I ask you for help. If you have any latest and greatest contact information for this gentleman, please let me know. I tried him at [EMAIL PROTECTED] but got denied. Thank you very much DHB
Re: Wine securityflaw.
On Sun, 27 Oct 2002, Peter Andersson wrote: What is it with you people? I was just trying to make a point about the security risks about using wine at present. And you start flameing me? We're not flaming you. We're just see big flaws with your proposal. We also proposed alternatives that seem to make more sense to us. Why don't you study how chroot or jail could be used in combination with Wine to build a sandbox? As far as I know no-one has tried that and it is possible that some changes in Wine could make things simpler to set up. Of course, we won't know until someone actually tries this. Also, I'm told that jail (available on FreeBSD) is much better than chroot. chroot only restricts access to files while I believe jail can also restrict access to other running processes and other system resources. Unfortunately I don't think a jail-like functionality is implemented on Linux. If you were to implement this I'm sure countless people would be grateful. http://docs.freebsd.org/44doc/papers/jail/jail.html Finally you could wrap it up by writing scripts that would make it easy to run Wine in a sandbox, and restore the sandbox to a clean state after a program has been run. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
Re: Wine securityflaw: Protect against root
On Sun, 27 Oct 2002, David D. Hagood wrote: P. Christeas wrote: Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing. I don't think this is necessary. Either the user is already logged in as root, as in 'I typed root when XDM asked me my login' (or the system logged me in as root like in Lindows), and then he has more important things to worry about. Or he logged in as a regular user and su-ed as root and is now running a Wine application. If he took the pain to su as root (and adjust $DISPLAY and permissions appropriately), then I would trust him to know what he is doing. Windows users don't su as root (they use the KDE/Mandrake/etc menu entries that automatically ask for the root password). Anyway, this idea is so trivial to implement in the Wine wrapper (a shell script) that it is really not an issue, and can be left to packagers (to add or remove). I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed). As someone else pointed out this would break a lot of programs. But there is an interesting aspect that I did not see mentioned before. The user reporting this says he was using KMail. I did some tests with KMail and whenever you open an attachement you get a warning that it may compromise your security. This may sound good but this happens for every single attachement: for text attachements, diff files, gifs, jpgs, everything. And this is a rule of security: if security measures get in the way they will be ignored. Here I'm sure KMail users just get the reflex of systematically clicking on Open don't even read the message after the first couple of times. To improve security KMail should issue warnings in a more discriminate manner (have a (user-configurable) list of known safe MIME types for instance). [...] And as for making / available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now. Again many people said Wine should not be configured to have access to your home directory or to /. But this would be a big usability problem and make Wine useless for all people using Wine in an office environment. In such an environment people need to open Word documents sent as attachement by collegues (/tmp/...), located on a file server (/mnt/server/), or documents they work on ($HOME/...). Remove the drives that let them access these documents and Wine becomes so cumbersome to use that it is unusable. In fact, arguing for the removal of these drives is a bit similar to arguing that Emacs should be run in a chroot-ed environment to protect you from malicious Lisp programs. Of course it means that you would have to copy files back and forth to edit them and thus no one is advocating that. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.
Re: Wine securityflaw.
On Sunday 27 October 2002 22.19, Francois Gouget wrote: On Sun, 27 Oct 2002, Peter Andersson wrote: What is it with you people? I was just trying to make a point about the security risks about using wine at present. And you start flameing me? We're not flaming you. We're just see big flaws with your proposal. We also proposed alternatives that seem to make more sense to us. Why don't you study how chroot or jail could be used in combination with Wine to build a sandbox? As far as I know no-one has tried that and it is possible that some changes in Wine could make things simpler to set up. Of course, we won't know until someone actually tries this. Finally someone that takes my concerns serriously, thank you! I agree. Using chroot could offer the functionality Im looking for. I will try the chroot model for now, I have a feeling that this wont be enough though, but we will see. Something in the chroot manside got me puzzled: ... ... ... Only the super-user may change the root directory. Note that this call does not change the current working directory, so that `.' can be outside the tree rooted at `/'. In particular, the super-user can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'. ... ... ... I will have to figure out the consequences of this odd behaviour, it certainly dont sound very safe at first look. Maybe jail is much better, but it seems to require porting as you said. //Peter
Re: Bug #321: dlls/msvct/vf[w]printf functions
On 27 Oct 2002 22:28:33 -, Jaco Greeff [EMAIL PROTECTED] wrote : Changelog: - Test case for the printf functions to test all known cases of formatting (test case based on example found on MSDN site) The test case is mostly the same as this example with \t replaced with spaces and some extra \n characters: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_printf.2c_.wprintf.asp Output from a test run attached to this mail. Greetings, Jaco printf.tst Description: Binary data
Re: search for Slava Monich
On Sun, Oct 27, 2002 at 03:21:31PM -0500, Doug Brown wrote: Hello I used to work with Slava Monich in the period 1992-1997 thereabouts. I am interested to find him now. I found his name on some Wine web pages from Google search on his name and after not finding anything furthermore specific I ask you for help. If you have any latest and greatest contact information for this gentleman, please let me know. I tried him at [EMAIL PROTECTED] but got denied. Nothing easier than doing: andi@note:/usr/local/src/wine$ grep -i monich ChangeLog |sort|uniq * windows/dialog.c: Slava Monich [EMAIL PROTECTED] * windows/dialog.c: Slava Monich [EMAIL PROTECTED] * windows/syscolor.c: Slava Monich [EMAIL PROTECTED] * windows/win.c: Slava Monich [EMAIL PROTECTED] * windows/winpos.c: Slava Monich [EMAIL PROTECTED] Slava Monich [EMAIL PROTECTED] Slava Monich [EMAIL PROTECTED] Contributions from 06/1999 to 07/2000. -- 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
Re: Listview Z8
Andreas Mohr wrote: What a weak and useless suggestion, this will run out of characters in no time at all ;-) Better use Chinese characters ! Bah! You are still weak! Better to use Klingon - I do beleive they've reserve some Unicode space for them!
Bad hand
Sorry everybody, My right hand hurts badly, I'll be off for a few days... -- Dimi.
[wine application] wineinput
http://opencjk.org/projects/wineinput/index-e.html
Re: Bug #321: dlls/msvct/vf[w]printf functions
Jaco Greeff [EMAIL PROTECTED] wrote:
Changelog:
* dlls/msvcrt/vfprintf.c, dlls/msvcrt/Makefile.in,
dlls/msvcrt/tests/printf.c, dlls/msvcrt/tests/Makefile.in: Jaco Greeff
[EMAIL PROTECTED]
- Full implementation to allow for %C %S in all printf related functions
- Test case for the printf functions to test all known cases of formatting
(test case based on example found on MSDN site)
I'm sorry for returning to that topic again and again, but it's really
does matter.
+static void test_printf(void)
+{
+ FILE* f;
+ char ch = 'a', *string = computer;
+ int count = -9234;
+ double fp = 251.7366;
+ wchar_t wch = L'w', *wstring = LUnicode;
+ void *p = 0x1234ABCD;
Please,
1. use explicit WCHAR type instead of wchar_t.
2. explicitly encode unicode strings.
wctomb(ch, wch);
3. directly use Win32 conversion APIs (WideCharToMultiByte in this case).
Take a look at other places in the Wine source how to do it properly.
Thanks.
--
Dmitry.
RPC test code?
OK, wine made it's first successful RPC's on my box today (yay!) Now, it's time to do a smidgen of housekeeping, and whip up a test. This is a bit tricky, I have a few open questions, which I will enumerate: 1) It feels like cheating to use the same process as client /and/ server. OTOH, it will be a bit cleaner to do it as such... any thoughts on this? specifically, 1a) Will wedging what is basically a winelib app into my test directory create a problem in the configure/make system? Is there a clean way to make sure I invoke the right winelib .exe.so file (the one in my test directory)? 1b) Are all the process-control API's I will need for this in place? (in particular I should kill off the server in case of a failure... will this be a problem? I guess probably not, or else I'd see a lot more wine's hanging around in my process table.) 1c) If the test fails in the winelib thingy, I have to propagate this back to the test; but relying on RPC for this (aside from being unimplemented ATM) is a catch-22, since error propagation might be broken (hence the need for a test)... I guess I can think of creative solutions to this like putting stupid temp files somewhere. Any better ideas? 1d) Anyone know of a problem with this I haven't thought of yet? 2) Whether I use threads or processes, I need some coordination to happen; I am very concerned about race conditions. I want my tests to run under the most absurd and grueling conditions, with NO race conditions. But I can't wrap my mind around how to avoid them ATM. For example: 2a) Should the rpc.c real test be the client or the server? I can imagine races either way. Let's say rpc.c is the client. This isn't so bad at a glance; I invoke the server thread/process, and poll RPC from time to time until it goes active (how I do this is another issue, but I'll think of something). Now I do my magic, and request a shutdown via RPC to the server... but, in two cases there is technically a race: first, while I'm invoking the server, I have to wait for it to start as discussed; second, after I send the Shutdown RPC to the server, I have to actually wait for the process/thread to terminate. In both cases, how long is long enough? What if the tests are running on some absurdly bogged down machine that's simultaneously compiling a matrix of 10,000 different wine's, for example? On the other hand, if I use some really liberal timeout like 30 minutes, then in a failure condition, my test would appear to hang, this isn't so great either. If rpc.c is the server, similar problems exist. 2b-?) uh, I guess I squeezed all of these questions into 2a. 3) MIDL? I still haven't figured out the legal ramifications of using midl-generated code. I'd rather not spend a month working on widl before generating a test... so do I need to code my stubs by hand? Even if I do, they're gonna come out looking more-or-less just like MIDL code... maybe I need to figure out the licensing restrictions on MIDL-generated code myself, but does anyone know offhand, I didn't see any obvious discussion of this on microsoft.com or in the platform sdk. ugh. thanks for taking the time to read this long-winded post. Any responses, assistance, flames, etc. are appreciated. -- gmt The purpose of government is to rein in the rights of the people --President Bill Clinton, MTV interview, 1993
Re: Listview Z8
Actually, I believe Klingon got rejected. Some junk about it not being a 'real' language or something. Try telling that to all the people that speak it though. Probably more than some of the other languages represented in Unicode. Maybe we should continue through the ASCII character set: 'X' 'Y' 'Z' '[' '\' ']' '^' '_' ... -- Jeff S. From: David D. Hagood [EMAIL PROTECTED] To: [EMAIL PROTECTED] Andreas Mohr wrote: What a weak and useless suggestion, this will run out of characters in no time at all ;-) Better use Chinese characters ! Bah! You are still weak! Better to use Klingon - I do beleive they've reserve some Unicode space for them! _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp
Re: Segmentation Fault
Oh, and one other thing. If I run the setup for who wants to beat up a millionaire (it's a WISE installer), the blue 'Initializing Wise Installation Wizard' screen comes up BEFORE wine faults. On Sun, 2002-10-27 at 21:14, Kye Lewis wrote: I don't know if this will help my Segmentation Fault at all, but when runing winedbg c:\\windows\\pbrush.exe, the Debugger actually waits for a command from me. If i take a step, it says: Single Stepping until exit from function, which has no line number information Stopped on breakpoint 1 at 0x0040100c (pbrush.exe.Entrypoint in c:\windows\pbrush.exe If i then step again Invalid address for breakpoint 0, disabling it . breakpoint 1 . . breakpoint 2 . Process of pid=0a24dbf0 has terminated a very odd thing happens if i run, and then step: another window pops up (gdb) and I get wine_dbg_cmd: Exception c0005 in the Wine Debugger the gdb window says 0x402e2b41 in nanosleep () from /lib/i686/libc.so.6 and stepping in that window steps me through function nanosleep (?!?!?!) it would seem that it starts to debug wine itself! unfortunately, this window doesn't allow copy and paste, so i'll have to type it out for you (it may be a little incorrect): __errno_location () at errno.c:48 48 return wine_errno_location(); (gdb) step thread_errno_location () at ../../include/winnt.h:1717 1717__asm__(.byte 0x64\n\tmov1 (0x18),%0 : =r (teb)); (gdb) step Program recieved signal SIGSEGV, Segmentation fault thread_errno_location () at ../../include/winnt.h:1717 1717__asm__(.byte 0x64\n\tmov1 (0x18),%0 : =r (teb)); (gdb) step Program recieved signal SIGCONT, Continued 0x40305134 in read () from /lib/i686/lib.so.6 etc... etc... etc... and it goes through a whole heck of code... The only thing that comes up in the console is Can't attach process 8072d90: error 5 Thanks, Kye Lewis [EMAIL PROTECTED]
Re: Bug #321: dlls/msvct/vf[w]printf functions
Dmitry Timoshkov wrote: + wchar_t wch = L'w', *wstring = LUnicode; + void *p = 0x1234ABCD; 1. use explicit WCHAR type instead of wchar_t. 2. explicitly encode unicode strings. Agreed, that one is directly from the MS site (link attached to a previous mail) and I've used it as such as a test case. It is very ugly, and in addition you get millions of warnings just compiling it. I wanted to make sure that we get as close to a real-world example working hence not stuffing around (making it real-wine-code) too much. The point has been proven, real-world code works, I'll fix that up to be compilant. wctomb(ch, wch); 3. directly use Win32 conversion APIs (WideCharToMultiByte in this case). Damnit, must have missed that one. I'm sure I had WideCharToMultiByte before. Take a look at other places in the Wine source how to do it properly. I know how to do it properly, reasons for the irritations explained above. Back to the real question: is there anything else missing that should be looked at in the patch? (Apart for the ugly test case and char conversion.) Greetings, Jaco
