Re: usp10: Add funtionality for ScriptStringAnalyse
Ta, I will redo the patch. =-O Jeff Detlef Riekenberg wrote: Jeff wrote: +if (psssa-pssap-psva) +HeapFree(GetProcessHeap(), 0, psssa-pssap-psva); +if (psssa-pssap-piAdvance) +HeapFree(GetProcessHeap(), 0, psssa-pssap-piAdvance); +if (psssa-pssap-pGoffset) +HeapFree(GetProcessHeap(), 0, psssa-pssap-pGoffset); +if (psssa-pssap-pwOutGlyphs) +HeapFree(GetProcessHeap(), 0, psssa-pssap-pwOutGlyphs); A NULL-Pointer is handled by HeapFree() and we cleaned up similar unneeded "if " - tests recently. Thanks.
Re: Re: Drive mapping of Z:
Hi Marcus, you wrote: (Maybe it's possible just to leave out the Z: mapping?) rm ~/.wine/dosdevices/z: You can also adjust the wineprefixcreate script not to create it anymore. as we've heard from our Austrian colleague, this is not improving sec (which was a freshening shock for me). Furthermore, on this machine it's impossible to remove the softlink mapping to Z:. It points to //. This was not done manually nor intentionally. So I wondered wether this is part of WINE's normal behaviour or something different. Kind regards, schollsky
Re: Re: Drive mapping of Z:
On Mon, Jul 24, 2006 at 11:25:17AM +0200, [EMAIL PROTECTED] wrote: Hi Marcus, you wrote: (Maybe it's possible just to leave out the Z: mapping?) rm ~/.wine/dosdevices/z: You can also adjust the wineprefixcreate script not to create it anymore. as we've heard from our Austrian colleague, this is not improving sec (which was a freshening shock for me). Furthermore, on this machine it's impossible to remove the softlink mapping to Z:. It points to //. This was not done manually nor intentionally. So I wondered wether this is part of WINE's normal behaviour or something different. Since the symlink is in a directory controlled by the user, the user should be able to remove it. If not, something is broken. ls -la ~/.wine ls -la ~/.wine/dosdevices Ciao, Marcus
Re: Re: Drive mapping of Z:
Le lundi 24 juillet 2006 à 11:25 +0200, [EMAIL PROTECTED] a écrit : Hi Marcus, you wrote: (Maybe it's possible just to leave out the Z: mapping?) rm ~/.wine/dosdevices/z: You can also adjust the wineprefixcreate script not to create it anymore. as we've heard from our Austrian colleague, this is not improving sec (which was a freshening shock for me). Furthermore, on this machine it's impossible to remove the softlink mapping to Z:. It points to //. This was not done manually nor intentionally. So I wondered wether this is part of WINE's normal behaviour or something different. Try: rm ~/.wine/dosdevices/z\: signature.asc Description: Ceci est une partie de message numériquement signée
Re: Drive mapping of Z:
Marcus Meissner wrote: as we've heard from our Austrian colleague, this is not improving sec (which was a freshening shock for me). Since the symlink is in a directory controlled by the user, the user should be able to remove it. If not, something is broken. ls -la ~/.wine ls -la ~/.wine/dosdevices Ciao, Marcus Is there a Linux hardening guide that we can recommend that people use to make their systems safe? Jeff
Re: Drive mapping of Z:
On Mon, Jul 24, 2006 at 08:58:05PM +1000, Jeff Latimer wrote: Marcus Meissner wrote: as we've heard from our Austrian colleague, this is not improving sec (which was a freshening shock for me). Since the symlink is in a directory controlled by the user, the user should be able to remove it. If not, something is broken. ls -la ~/.wine ls -la ~/.wine/dosdevices Ciao, Marcus Is there a Linux hardening guide that we can recommend that people use to make their systems safe? ? WINE is for executing binary programs the user downloads. You can only make it safer be deinstalling. ;) Ciao, Marcus
Re: [kernel] Add dummy HeapSetInformation, take 2
Dan Kegel [EMAIL PROTECTED] wrote:
Changelog:
include/winnt.h: add enum HEAP_INFORMATION_CLASS
kernel/heap.c: add dummy HeapSetInformation()
+enum _HEAP_INFORMATION_CLASS {
+ HeapCompatibilityInfo
+};
PSDK uses Information not just short Info at the end.
--
Dmitry.
Re: Drive mapping of Z:
Stefan Dösinger wrote: Disabling the Z:\ drive won't help security in THEORY... because windows applications can still do Linux syscalls (int 0x80) which they can use do do anything native apps do, like accessing files outside wine drive mappings. But in PRACTICE, it would help a lot to hinder total system destruction once viruses start running correctly on Wine. (Especially for users like me, who always runs Wine as the root user ;-).)
Re: Drive mapping of Z:
On Mon, Jul 24, 2006 at 02:49:57PM +0200, Molle Bestefich wrote: But in PRACTICE, it would help a lot to hinder total system destruction once viruses start running correctly on Wine. (Especially for users like me, who always runs Wine as the root user ;-).) you complain about security in wine and run it as root? even if i have the strongest doubts, that there is need for running wine as root - at least do a chroot or use systraceorwhattheyarenamednowadays. it makes hardly sense to suggest security measures for wine while running it as root - this is like suggesting, that vi should no longer be able to modify files, because started as root your could modify every file on the system. -- cu pgpFru9d6eGfv.pgp Description: PGP signature
Re: usp10: Implement and test ScriptCacheGetHeight. (rediffed)
Hi, On Sun, Jul 23, 2006 at 12:58:06PM +0200, Hans Leidekker wrote: On Sunday 23 July 2006 11:26, Jeff Latimer wrote: Interesting. I have not had any problem with them. They also compile and run under Windows. Have you got anymore info, a trace? It doesn't look very useful to me: Unhandled exception: page fault on read access to 0x70697263 in 32-bit code (0x70697263). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:70697263 ESP:406fd240 EBP:530a EFLAGS:00010282( - 00 - RIS1) EAX:0001 EBX:20474e49 ECX:5c5c5c5c EDX:405e85bc ESI:20746f6e EDI:78383025 Stack dump: 0x406fd240: 72745374 41676e69 796c616e 53206573 0x406fd250: 20627574 756f6873 7220646c 72757465 0x406fd260: 5f45206e 49544f4e 204c504d 20746f6e 0x406fd270: 78383025 530a 70697263 72745374 0x406fd280: 4f676e69 53207475 20627574 756f6873 0x406fd290: 7220646c 72757465 5f45206e 49544f4e That's all very, very char'ish. 0x70697263 is pirc, the whole stack is in ASCII range, too (run hexedit on an empty file to verify). Andreas Mohr
Re: Drive mapping of Z:
On 7/24/06, Michael Stefaniuc [EMAIL PROTECTED] wrote: [cut] That's plain wrong. I guess Wine needs a patch to make it stop working as uid 0 ... Some interesting security features could be: * Built-in option to execute Wine in a jail, like using chroot command, over a WINEPREFIX; * Block root or a warning when doing this as an oficial option at execution or compilation time; * A interative warning or something like firewall popup warning about apps running under Wine accessing files outside of the WINEPREFIX. My 2 cents. Augusto Arcoverde da Rocha
Re: svrapi: realizes library svrapi.dll (3 of 20 functions).
Konstantin Petrov wrote:
Your Patch is much to large.
dlls/svrapi/Makefile,
dlls/svrapi/libsvrapi.def,
This files are created automatic by the build-system.
+16 stdcall NetShareAdd (str long str long) WIN98_NetShareAdd
+17 stdcall NetShareDel(str str long) WIN98_NetShareDel
+18 stdcall NetShareEnum(str long ptr long ptr ptr) WIN98_NetShareEnum
+19 stub NetShareGetInfo
+20 stub NetShareSetInfo
Are the ordinals needed / Which app import this Functions by Ordinal?
--- /dev/null 2006-07-03 10:36:18 +0400
+++ dlls/svrapi/svrapi_main.c 2006-07-24 15:08:49 +0400
I suggest to send a Patch, that has only DllMain in this File to
reduce the size.
Add a stub with description in a separate Patch.
+//SHPWLEN is not known !!
C++ - Comments are not allowed in wine (it's not portable)
+#define SHPWLEN LM20_PWLEN
+typedef struct _share_info_1 {
+ char shi1_netname[LM20_NNLEN+1];
+ char shi1_pad1;
+ unsigned short shi1_type;
+ char* shi1_remark;
+} share_info_1;
+typedef struct _share_info_50 {
+ char shi50_netname[LM20_NNLEN+1];
+ unsigned char shi50_type;
+ unsigned short shi50_flags;
+ char* shi50_remark;
+ char* shi50_path;
+ char shi50_rw_password[SHPWLEN+1];
+ char shi50_ro_password[SHPWLEN+1];
+} share_info_50;
This seems to be the wrong location here. (svrapi.h)
Should be the first patch (only this include-file)
+BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID
fImpLoad)
+{
+TRACE(%p 0x%lx %p\n, hinstDLL, fdwReason, fImpLoad);
+
+switch(fdwReason) {
Do not forget DLL_WINE_PREATTACH
+
+ FIXME(Stub (%s %d %p %d %p %p)\n, (pszServer ?
pszServer:NULL), sLevel, pbBuffer,
+ cbBuffer, pcEntriesRead, pcTotalAvail);
you need debugstr_a()
+ if (pbBuffer != NULL)
+ HeapFree(GetProcessHeap(), 0, pbBuffer);
HeapFree() handles NULL; we removed similar unneeded if recently.
+ if(pszServer != NULL) return NERR_NetNameNotFound;
Many Functions in other dll's handle an empty Servername as an alias for
the local Computer (the same way as an NULL-Parameter).
Did you test this?
+ // if ((sLevel == 50) (cbBuffer ==
sizeof(share_info_50))) //in real
Why do you not use this code, when it reflects the windows-behavior?
--
By By ...
... Detlef
Re: Drive mapping of Z:
Augusto Arcoverde da Rocha wrote: Some interesting security features could be: * Built-in option to execute Wine in a jail, like using chroot command, over a WINEPREFIX; * Block root or a warning when doing this as an oficial option at execution or compilation time; * A interative warning or something like firewall popup warning about apps running under Wine accessing files outside of the WINEPREFIX. Wine's dlls and libraries all exist outside of WINEPREFIX, so doing the above would mean that Wine wouldn't be able to open it's own builtin dlls. You're trying to turn Wine into something it isn't. Use Qemu, Xen or some other virtualization solution if you don't trust the programs you want to run. Mike
Re: Drive mapping of Z:
Christoph Frick wrote: Molle Bestefich wrote: But in PRACTICE, it would help a lot to hinder total system destruction once viruses start running correctly on Wine. (Especially for users like me, who always runs Wine as the root user ;-).) you complain about security in wine and run it as root? even if i have the strongest doubts, that there is need for running wine as root Hehe. It won't work as non-root, and I could waste days finding out whatever's wrong with my X configuration (which is the default as it comes with Gentoo, btw). I have a *lot* of much more productive ways that I can spend that time ;-). at least do a chroot or use systraceorwhattheyarenamednowadays. Hmm. Thanks for the tip. it makes hardly sense to suggest security measures for wine while running it as root - this is like suggesting, that vi should no longer be able to modify files, because started as root your could modify every file on the system. Granted, wine is as fucked as everything else when running as 'root', so it would seem like the wrong place to fix things. OTOH, if sandboxing the rest of your Linux system from Windows bugs introduced through Wine is as easy as disabling drive Z: (and for the most part, it is!), then we should certainly make sure that it can be done and can be done easily. Michael Stefaniuc wrote: I guess Wine needs a patch to make it stop working as uid 0 And the point of fucking with people like this would be... The sheer fun of fucking with people that you don't happen to agree with? :-)
Re: Drive mapping of Z:
you complain about security in wine and run it as root? even if i have the strongest doubts, that there is need for running wine as root It won't work as non-root, and I could waste days finding out whatever's wrong with my X configuration (which is the default as it comes with Gentoo, btw). ?! You're saying that you can't get wine to work for you as non-root? Do other X applications work for you as non-root? Did you try that with a fresh test user? Cheers, Kuba
Repetitve fixme for each file accessed.
I keep getting stub fixme's for each and every single file that is access in Wine, especially via an installer. THe fixmes look like: fixme:sfc:SfcIsFileProtected ((nil), LC:\\Program Files\\GeneXproTools 4\\SampleRuns\\XOR.gep) stub Does this have anything to do with the ClamAV integration I've heard you guys talking about? -- The real problem with C++ for kernel modules is: the language just sucks. -- Linus Torvalds
Re: Possible bug in Wine or NDISWRAPPER
Francois Gouget wrote: On Tue, 11 Jul 2006, gslink wrote: The most common problem with Ndiswrapper is that it requires more than a 4k stack. The result you are getting may be coming from a stack overflow caused by a combination of Wine and Ndiswrapper. The 4k stack issue you are talking about is a kernel stack. Wine is a user space application so anything Wine does with its stacks will have no impact on the kernel stack. Now it is possible that Wine makes system calls that cause the kernel to recurse and blow its stack, but these calls could just as well happen in any run-of-the-mill Linux application. And in any case, this would be a kernel bug. What you say is correct but the result is the same. The combination of NDISWRAPPER and any other program fails. In this case it is Wine. This is not the fault of Wine in any way but it happens. It is a good idea to keep this behavior in mind as NDISWRAPPER is not the only program that uses too much stack under some conditions and blows Wine.
Re: Repetitve fixme for each file accessed.
Segin wrote: fixme:sfc:SfcIsFileProtected ((nil), LC:\\Program Files\\GeneXproTools 4\\SampleRuns\\XOR.gep) stub This indicates, that the Installer is correct. When an Installer does not give the fixme, it's outdated / incomplete. Does this have anything to do with the ClamAV integration I've heard you guys talking about? No. :sfc: is the dllname, and when you look at the only source-file, you will find: * Implementation of the System File Checker (Windows File Protection) (I added this to wine) -- By By ... ... Detlef
Re: Possible bug in Wine or NDISWRAPPER
On 7/24/06, gslink [EMAIL PROTECTED] wrote: What you say is correct but the result is the same. The combination of NDISWRAPPER and any other program fails. In this case it is Wine. This is not the fault of Wine in any way but it happens. It is a good idea to keep this behavior in mind as NDISWRAPPER is not the only program that uses too much stack under some conditions and blows Wine. NDISWRAPPER is not a program. It is a kernel driver. There is a huge difference: there's no protection to keep kernel driver bugs from killing the kernel or apps. And indeed, that's what you're seeing here. There should be *absolutely no* userspace app that can crash Wine (except by using up all swap space). Were there one, it would not be the app's fault, but rather a kernel bug. If you want to use NDISWRAPPER, you probably have to configure your kernel with larger kernel thread stacks. See http://lwn.net/Articles/149977/ - Dan
Re: Repetitve fixme for each file accessed.
On 7/24/06, Detlef Riekenberg [EMAIL PROTECTED] wrote: Segin wrote: fixme:sfc:SfcIsFileProtected ((nil), LC:\\Program Files\\GeneXproTools 4\\SampleRuns\\XOR.gep) stub (I added this to wine) Please turn it into a TRACE instead of a FIXME.
Re: Drive mapping of Z:
Molle Bestefich wrote: you complain about security in wine and run it as root? even if i have the strongest doubts, that there is need for running wine as root It won't work as non-root, Wine works always as non-root. and I could waste days finding out whatever's wrong with my X configuration (which is the default as it comes with Gentoo, btw). I'm using wine with Ubuntu 5.04 without Problems. Your System is really broken / wrong configured, when wine does not work as normal user. fug : This is not a Mailing-List for such words -- By By ... ... Detlef
Re: Possible bug in Wine or NDISWRAPPER
Dan Kegel wrote: On 7/24/06, gslink [EMAIL PROTECTED] wrote: What you say is correct but the result is the same. The combination of NDISWRAPPER and any other program fails. In this case it is Wine. This is not the fault of Wine in any way but it happens. It is a good idea to keep this behavior in mind as NDISWRAPPER is not the only program that uses too much stack under some conditions and blows Wine. NDISWRAPPER is not a program. It is a kernel driver. There is a huge difference: there's no protection to keep kernel driver bugs from killing the kernel or apps. And indeed, that's what you're seeing here. There should be *absolutely no* userspace app that can crash Wine (except by using up all swap space). Were there one, it would not be the app's fault, but rather a kernel bug. If you want to use NDISWRAPPER, you probably have to configure your kernel with larger kernel thread stacks. See http://lwn.net/Articles/149977/ - Dan You miss my point. Somebody puts a defective driver in Linux and Wine gets the blame. If you recompile your kernel with a larger stack you will have no problems. This particular stack bug has been responsible for numerous complaints about several programs that ran perfectly. It is not confined to NDISWRAPPER. If Wine or some other program starts doing this kind of thing it is best to look in the kernel. The problem is that it is hard to detect. I suspect we will be seeing more of this problem because when it happens it makes whatever program the user is running seem defective. If you can't figure out what is wrong with Wine then this is one place to look because there may not be anything wrong with Wine.
Re: wcmd: strip quotes around executable and retry on error
On 7/21/06, Francois Gouget [EMAIL PROTECTED] wrote: On Tue, 11 Jul 2006, Thomas Kho wrote: [...] A fake notepad.exe is currently created in c:\windows\system32. I don't think there's duplication of CreateProcess because CreateProcess considers the filename of the executable to be the first quoted term in the commandline. In contrast, cmd.exe also considers the first space-separated word of that quoted string as the filename of the executable when the entire quoted term is not an executable. CreateProcess does that too: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp It doesn't follow the ambiguous file name searching for CreateProcess. I just re-read the cmd.exe help output and realized that it spells out the logic for quotes when /c is specified. My patch was overarching in also affecting commands entered at the command prompt; it should only affect the command line passed in as an argument with the /c flag. Tommy
Re: Possible bug in Wine or NDISWRAPPER
You miss my point. No, it's more likely we're in violent agreement.
[OT] X environment not working as non-root
Do other X applications work for you as non-root? Can't remember, but my gut feeling is 'no'. (It's probably something really simple too, I just don't have the time, energy nor do I even want to figure out how this crap works - for the time being, I'm not into X hacking, so for me it's a tool that should just work, and if it doesn't, the worst I'm going to do about it is hate it real good.) I think that your X server works just fine. It's probably that you don't have your default desktop environment set up properly. There should be a configuration utility to set up just that. Cheers, Kuba
Re: Drive mapping of Z:
On Monday 24 July 2006 13:25, Molle Bestefich wrote: Kuba Ober wrote: ?! You're saying that you can't get wine to work for you as non-root? Do other X applications work for you as non-root? Can't remember, but my gut feeling is 'no'. Then it's really off-topic then. If you'd be willing to give me a regular clean user ssh account on that machine, I can try and figure things out. Just make the /var/log/*X* and /var/log/*x.org* readable by that user, and make /etc/X11/* writable. We can agree on some time so that I can open a text chat session to you and you could restart X as necessary. Just make sure you have nchat (or similar text chat) installed. Besides, it may be something as simple as not having your windowing environment properly set up, as opposed to there being anything wrong with X server itself. Likely the window manager and the environment from xfce, kde or gnome doesn't start up. Let me know off-list if you want to get it fixed. Since it's ridiculous to get wine involved in your system's obious misconfiguration, I'm willing to fix it for you. In fact I only feel like doing it for you because it's so ridiculous to drag this problem onto this list as to be funny in an obscene way, if you get my idea ;) Cheers, Kuba
Re: Repetitve fixme for each file accessed.
fixme:sfc:SfcIsFileProtected ((nil), LC:\\Program Files\\GeneXproTools 4\\SampleRuns\\XOR.gep) stub (I added this to wine) Please turn it into a TRACE instead of a FIXME. If it's a stub isn't it a FIXME? Otherwise it'd only make sense to me if it were a long-term WONTFIX type of thing. Or if it's not a stub anymore then of course you're right and it needs to be merely a trace. Cheers, Kuba
Re: Repetitve fixme for each file accessed.
On 7/24/06, Kuba Ober [EMAIL PROTECTED] wrote: fixme:sfc:SfcIsFileProtected ((nil), LC:\\Program Files\\GeneXproTools 4\\SampleRuns\\XOR.gep) stub Please turn it into a TRACE instead of a FIXME. If it's a stub isn't it a FIXME? That is standard practice for extremely intrusive and frequent FIXME's, I think. It's a practical thing.
Re: Cursor patches
Another update. - The patches don't use INVALID_HANDLE_VALUE anymore (I was using that in some of the other patches as well). - riff_find_chunk() compares DWORDs - Code using get_cursor_frame() now has some error handling, in case the handle is invalid - Warnings should be fixed now, although I don't get the second one myself. cursor_patches_20060724.tar.bz2 Description: BZip2 compressed data
Re: Cursor patches
On 25/07/06, H. Verbeet [EMAIL PROTECTED] wrote: Another update. Ignore that. It doesn't actually work.
Re: Cursor patches
On 25/07/06, H. Verbeet [EMAIL PROTECTED] wrote: On 25/07/06, H. Verbeet [EMAIL PROTECTED] wrote: Another update. Ignore that. It doesn't actually work. In riff_find_chunk(): *((DWORD *)ptr) + 2 == chunk_id Should be: *((DWORD *)ptr + 2) == chunk_id
How do I get the unix filename for a wine handle?
Currently I'm working on a scan-after-write functionality: Whenever a file was changed the virusscanner checks the file. My plan is to hook in NtWriteFile() (dlls/ntdll/file.c), because whenever a windows program writes to a file this function is called. why not scan-before-write? you have a hook into the write process, why not block the write if you have a hit?
Broken character models in dx8/9 games in wined3d
I've spent a couple of days researching the issue of broken/upside-down character/object models in Wine in almost all newer games when you have vertex shaders enabled (Civ4, Half Life 2, Oblivion, Max Payne 2, etc.). I think I've boiled it down to a single case: When device-renderUpsideDown is set in the case where vertex shaders are enabled. That flag gets set in device.c:7395 when the current renderTarget is not on the current swapchain. The comments in the source say that the upside-downedness is produced by glCopyTexImage, so it sets a flag to flip everything over. In the case w/o shaders, there is code in drawprim.c which loads the WORLDVIEW and PROJECTION matrices and then multiplies those matrices by one which inverts the y coordinates when that flag is set. That seems to work in the case without vertex shaders, but when shaders are enabled, they bypass the WORLD, VIEW, and PROJECTION matrices entirely. The shader case was written when only software shaders worked, but that is no longer true. It loads identity matrices and performs the y flip, but that code is entirely irrelevant since the vertex shader doesn't reference those matrices; it only uses constants that are passed by the app, which we can't perform any type of fixup on since we don't know which constants will be used for which calculation. So, I think what we need to do is prevent ourselves from having to do any flipping whatsoever. That's the part that I'm not sure how to do and is the reason for this email. Can we load the textures in system memory first, perform a software reversing process, then load that up with glCopyTexImage instead? Will we need to do that type of fixup every time the app locks/unlocks/changes part of the texture? Or, is there a better way? I think I've figured out the problem, it's just the next step of fixing it that I'm unsure of. :-) From a few hackish tests, I've been able to fix some of the issues where the only thing wrong was that the images were upside-down with this hack (for GLSL shader mode only): diff --git a/dlls/wined3d/vertexshader.c b/dlls/wined3d/vertexshader.c index 84f90f5..d0325d9 100644 --- a/dlls/wined3d/vertexshader.c +++ b/dlls/wined3d/vertexshader.c @@ -719,6 +719,7 @@ #endif shader_addline(buffer, gl_FogFragCoord = clamp(gl_FogFragCoord, 0.0, 1.0);\n); } +shader_addline(buffer, gl_Position = gl_Position * gl_ModelViewProjectionMatrix;\n); shader_addline(buffer, }\n\0); TRACE(Compiling shader object %u\n, shader_obj); This works because the gl_ModelViewProjectionMatrix is just a matrix which reverses the y position when This-renderUpsideDown == TRUE, otherwise it's the identity matrix. Here are a few comparison screenshots: Oblvion: - Before: http://www.cmhousing.net/wine/oblivion2.png After: http://www.cmhousing.net/wine/oblivion_sortacorrect3.png Civ4: - Before: http://www.cmhousing.net/wine/civ4_before.png After: http://www.cmhousing.net/wine/civ4_leaderhead.png Half Life 2: - After: http://www.cmhousing.net/wine/hl2_rightsideup.png (the bottom got screwed up, but normally the guy on the picture is upside-down) Many of the character models and other objects are still broken even with that hack, but that's because we should be flipping more than just the final position - we should be flipping a whole row of constants that the app is using before it starts its calculations. Instead of trying to do that, we should fix the root of the problem IMHO. Anyway, any ideas are welcome. :-) Jason
Re: Broken character models in dx8/9 games in wined3d
On 7/24/06, Jason Green [EMAIL PROTECTED] wrote: I've spent a couple of days researching the issue of broken/upside-down character/object models in Wine in almost all newer games when you have vertex shaders enabled (Civ4, Half Life 2, Oblivion, Max Payne 2, etc.). Yes, I remember some talk on IRC, and wanted to comment, but will do now. I think I've boiled it down to a single case: When device-renderUpsideDown is set in the case where vertex shaders are enabled. That flag gets set in device.c:7395 when the current renderTarget is not on the current swapchain. The comments in the source say that the upside-downedness is produced by glCopyTexImage, so it sets a flag to flip everything over. In the case w/o shaders, there is code in drawprim.c which loads the WORLDVIEW and PROJECTION matrices and then multiplies those matrices by one which inverts the y coordinates when that flag is set. That seems to work in the case without vertex shaders, but when shaders are enabled, they bypass the WORLD, VIEW, and PROJECTION matrices entirely. The shader case was written when only software shaders worked, but that is no longer true. It loads identity matrices and performs the y flip, but that code is entirely irrelevant since the vertex shader doesn't reference those matrices; it only uses constants that are passed by the app, which we can't perform any type of fixup on since we don't know which constants will be used for which calculation. Yeah, I've noticed all this with Star Wars Battlefront. See bug 5247. Without vertex shaders, I have a very simple hack to fix the one issue of an upside down skybox. What I did should be quite obvious to you. With vertex shaders (note: I make brief mention in bug comments about how to get them working with dri, you might remember this from IRC too) having them enabled, the problem gets a little worse as certain parts of the skybox are correctly up and others upside down. If you apply the hack, then *everything* got flipped -- those that were correct were now upside down, and vice-versa. Also parts of the box got shifted a bit. This is with ARB shaders BTW. I'll post screen shots when I get the chance. I wonder if there was a reason for the flip code because it does flip some things correctly. So, I think what we need to do is prevent ourselves from having to do any flipping whatsoever. That's the part that I'm not sure how to do and is the reason for this email. That I'd agree with. There are certainly things it does wrong. But I think I need to go back studying the code before I make any recommendations. :) I'll try to get back to you later. Jesse
Re: Drive mapping of Z:
On 7/24/06, Stefan Dösinger [EMAIL PROTECTED] wrote: Disabling the Z:\ drive won't help security because windows applications can still do Linux syscalls (int 0x80) which they can use do do anything native apps do, like accessing files outside wine drive mappings. Is there a way to disable this as well? n0dalus.
Re: Drive mapping of Z:
n0dalus [EMAIL PROTECTED] wrote: On 7/24/06, Stefan Dösinger [EMAIL PROTECTED] wrote: Disabling the Z:\ drive won't help security because windows applications can still do Linux syscalls (int 0x80) which they can use do do anything native apps do, like accessing files outside wine drive mappings. Is there a way to disable this as well? If you carefully re-read the above conversation and clearly recognize Wine as a native application, then the answer is yes: just stop using Wine along with other native applications. -- Dmitry.
Re: Drive mapping of Z:
Monday, July 24, 2006, 10:00:44 AM, Molle Bestefich wrote: Christoph Frick wrote: you complain about security in wine and run it as root? even if i have the strongest doubts, that there is need for running wine as root Hehe. It won't work as non-root, and I could waste days finding out whatever's wrong with my X configuration (which is the default as it comes with Gentoo, btw). That just shows how much you know your system. Wait, do you even know that you running Linux and not winbloze? I have a *lot* of much more productive ways that I can spend that time ;-). Of course bitch on wine-devel about your ignorance and inability to learn. Then write more off-topic stuff. Then bitch some more using words that 10 year olds will feel really proud to say in the public (when no one knows who they are). Granted, wine is as fucked as everything else when running as 'root', so it would seem like the wrong place to fix things. Then why are you running everything as root? Or right I forgot. It's not root, it's Administrator... I think the only cure for you that you will understand is 'rm -rf /' (man rm for what it's doing). Then unplug that thing that you just worked with, and throw it out the window. Since you don't have basic understanding of what the hell that thing is anyway. Why bother? Or better then that go and buy xbox. It can play games too. Vitaliy.
Re: Drive mapping of Z:
On 7/24/06, Vitaliy Margolen [EMAIL PROTECTED] wrote: Or better then that go and buy xbox. It can play games too.Vitaliy.I wouldnt advise that, because an xbox can run linux too, and since the original xbox runs on PC hardware, i wouldbt be at all surprised to see someone try to get wine working on it.. in which case they would come here for help (groan).. -- ThanksTomCheck out this new 3D Instant Messenger called IMVU.It's the best I have seen yet! http://www.imvu.com/catalog/web_registration.php?userId=1547373
Re: Drive mapping of Z:
Molle Bestefich wrote: (It's probably something really simple too, I just don't have the time, energy nor do I even want to figure out how this crap works - for the time being, I'm not into X hacking, so for me it's a tool that should just work, and if it doesn't, the worst I'm going to do about it is hate it real good.) Why in the world would run Gentoo when you want something that 'just works'? Gentoo is a great distribution but you are not its target audience. Go install Ubuntu or SuSE.
Re: Drive mapping of Z:
n0dalus [EMAIL PROTECTED] wrote: I mean, is there a way for wine to stop applications it runs from making those syscalls while still being able to make them itself? No, and the reason why already has been pronounced. -- Dmitry.
Lotus Notes 7 success!
Thanks to a few targeted patches written by Stefan Siebert and James Hawkins, and of course decades of effort by the whole Wine team, Lotus Notes 7 trial version now installs and runs! See http://wiki.winehq.org/LotusNotes for details. I just spent an hour or so playing with Notes as a plain old email client. It had a few mysterious crashes, but in general seemed usable. (Not that I'd ever use it after getting used to gmail, but that's another story.) I filed bug http://bugs.winehq.org/show_bug.cgi?id=5752 about a strangeness in the email client. - Dan
Re: Win64 patch 3/6 (resend)
Ge van Geldorp [EMAIL PROTECTED] wrote:
--- a/include/wine/server_protocol.h
+++ b/include/wine/server_protocol.h
@@ -33,6 +33,9 @@ struct reply_header
struct request_max_size
{
int pad[16];
+#ifdef _WIN64
+int pad64[10];
+#endif
};
Why is this required? Is that due to asserts in server/request.c,
open_master_socket() ? Is changing 'int' to 'long' a better fix?
Also probably the fix should go in server/protocol.def instead.
--
Dmitry.
Re: wine's fullscreen code has no effect on metacity
Havoc Pennington [EMAIL PROTECTED] wrote: Dmitry Timoshkov wrote: It's OK that a WM constrains windows to be placed inside of its work area but still allows to place them into a fullscreen state on request. How would you suggest to properly inform a WM that a window needs to be in a fullscreen state? Does metacity ignore ClientMessage/_NET_WM_STATE_FULLSCREEN request due to 'fullscreenable = 0' or something else? I'm not next to the machine where I had the log unpacked, so I'm not sure, but yeah if fullscreenable=0 when the client message is received then that would cause it to be ignored. I think some tweaking to when fullscreenable is set would be well worth trying out as a solution. Anything else I can do to help fixing this problem? Do you need any further testing/logs/investigation on the Wine side? Thanks. -- Dmitry.
Re: Remove unused ignore field in widl structures
On Mon, Jul 24, 2006 at 11:49:35AM -0700, Dan Hipschman wrote: This field is superfluous: [widl]$ find -name *.[chly] | xargs fgrep -n ignore ./parser.y:1049: t-ignore = parse_only; ./parser.y:1126: f-ignore = parse_only; ./widltypes.h:208: int ignore, is_const, sign; ./widltypes.h:238: int ignore, idx; ./parser.tab.c:3841: t-ignore = parse_only; ./parser.tab.c:3918: f-ignore = parse_only; This patch has been obsoleted by the patch, widl [1/2]: Fix redefinition of types in output (take 2), here: http://www.winehq.org/pipermail/wine-patches/2006-July/028998.html, which rather than removing the ignore field, puts it to use.
