Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs
On Thu, Dec 06, 2012 at 10:26:28PM +0400, Pavel Shilovsky wrote: Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this change can benefit cifs and nfs modules. While this change is ok for network filesystems, itsn't not targeted for local filesystems due security problems (e.g. when a user process can deny root to delete a file). Share flags are used by Windows applications and WINE have to deal with them too. While WINE can process open share flags itself on local filesystems, it can't do it if a file stored on a network share and is used by several clients. This patchset makes it possible for CIFS/SMB2.0/SMB3.0. I don't think introducing user visible flags that are only supported on a single network filesystem is a good idea. I'm not even sure adding these flags does make a lot of sense, but assuming we'd actually want this (and I'd like some more detailed explanation) I think we'd at least need to make sure that: a) opening files with the new modes gives a proper error message if not supported b) there needs to be local support for them as well c) we need to think really hard when they should be supported, and need a good rational for it. I can't see how we could do it unconditionally for all users as that would introduce easy denial of services attacks the way I understand the semantics (correct me if I'm wrong). So a mount option like you currently do probably is the least bad even if don't fell overly happy about that version. What is the reason your special wine use case can't simply use a userspace cifs client? Given that wine uses windows filesystem semantics and cifs does as well tunnelling it through a Posix-like API inbetween is never going to be perfect.
Re: Forward SHLocalAlloc to kernel32 LocalAlloc
since v5 this is SHCreateDesktop 200 stdcall -noname SHCreateDesktop(ptr) see http://www.geoffchappell.com/viewer.htm?doc=studies/windows/shell/shell32/api/index.htm Am 07.02.2010 14:29, schrieb Vladimir Pankratov:
Re: mshtml: allow REG_EXPAND_SZ values for GeckoCabDir
Hi Juan,
No, I used RegGetValue which expands them for me.
Christoph
Juan Lang schrieb:
Hi Christoph,
-/* @@ Wine registry key: HKCU\Software\Wine\MSHTML */
-res = RegOpenKeyW(HKEY_CURRENT_USER, mshtml_keyW, hkey);
-if(res != ERROR_SUCCESS)
-return FALSE;
-
file_name = heap_alloc(size+sizeof(GECKO_FILE_NAME));
-res = RegQueryValueExA(hkey, GeckoCabDir, NULL, type,
(PBYTE)file_name, size);
+/* @@ Wine registry key: HKCU\Software\Wine\MSHTML */
+res = RegGetValueA(HKEY_CURRENT_USER, mshtml_keyA, GeckoCabDir,
RRF_RT_ANY, type, (PBYTE)file_name, size);
This change is unrelated to the subject. One change per patch, please.
+if(res != ERROR_SUCCESS || (type != REG_SZ type != REG_EXPAND_SZ)) {
heap_free(file_name);
return FALSE;
}
If you're allowing REG_EXPAND_SZ, oughtn't you call
ExpandEnvironmentVariablesA as well?
--Juan
Re: Use environment variable WINE_NO_MENU_ENTRIES to prevent menu icon and menu entry creation.
Thank you.
I have fixed it and resent the patch to wine-patches.
Also I have shortened the environment variable to WINENME.
Christoph Korn
Detlef Riekenberg schrieb:
On Do, 2009-02-05 at 18:02 +0100, Christoph Korn wrote:
int PASCAL WinMain (HINSTANCE hInstance, HINSTANCE prev, LPSTR
cmdline, int show)
{
+if(getenv(WINE_NO_MENU_ENTRIES))
+{
+return 0;
+}
+
LPSTR token = NULL, p;
Declaring a variable after code is C99 and not allowed in Wine.
Re: wine.budgetdedicated.com down?
The latest ubuntu packages are available here: https://launchpad.net/~ubuntu-wine/+archive/ppa Christoph Korn Matt Perry schrieb: On Sun, Feb 1, 2009 at 8:54 AM, Dan Kegel d...@kegel.com wrote: I can't download debian wine packages from wine.budgetdedicated.com today... Would it be possible to host the Wine packages somewhere with higher availability? Maybe at winehq.org, or apply for hosting at ibiblio.org or mirrors.kernel.org?
Re: Fix wine-bugs mailing list traffic message.
Ok, I did not know there was a CVS/GIT cleanup. Maybe the message is irrelevant anyway. Best regards Christoph Korn Jerome Leclanche schrieb: It's not hundreds / day (as it's been the past few days due to the CVS/GIT cleanup), but it's definitely not 10/day either. I would say 60-70 per day is common, but I don't run statistics (nor try to). On Tue, Jan 20, 2009 at 5:26 PM, Francois Gouget fgou...@free.fr wrote: On Tue, 20 Jan 2009, Christoph Korn wrote: Only a small fix. I subscribed to the wine-bugs mailing list because it was listed as medium traffic. But I got hundreds of mails in about two hours or so. Usually it's a medium traffic mailing list (I believe), but occasionally (2/3 times a year) someone does a big cleanup touching hundreds of bugs and that's when you get a lot of emails... -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.
Re: Opengl32: add a test case for WGL_ARB_create_context/opengl3 [try2]
On Fri, Oct 10, 2008 at 10:42:05AM +0200, Roderick Colenbrander wrote: +/* Try to create an OpenGL 3.0 contet */ content? context? -- cu pgpP3eMPpyjbs.pgp Description: PGP signature
Re: mmio: Do not zero current file position whenever mmioSetBuffer is called
On Tue, Jun 03, 2008 at 07:57:00PM -0700, Matthew D'Asaro wrote: Instead I set wm-info.lBufOffset to wm-info.lDiskOffset because the buffer is flushed at the beginning of a call to mmioSetBuffer so wm-info.lDiskOffset is synchronized with wm-info.lBufOffset and so wm-info.lDiskOffset contains the correct current file position. The test for mmio still passes with this patch. wouldn't that indicate, that the current patch does not cover that case? can you add a test for it? -- cu pgpbJjlUNATaz.pgp Description: PGP signature
Re: [dinput] move the common joystick_map_.* methods from joystick_linuxinput.c into device.c
On Sat, Apr 26, 2008 at 08:39:19AM -0600, Vitaliy Margolen wrote: Christoph Frick wrote: diff --git a/dlls/dinput/device.c b/dlls/dinput/device.c index 5f927d0..baca0b3 100644 --- a/dlls/dinput/device.c +++ b/dlls/dinput/device.c @@ -1400,3 +1400,54 @@ HRESULT WINAPI IDirectInputDevice8WImpl_GetImageInfo(LPDIRECTINPUTDEVICE8W iface Please don't. Device is common for everything (keyboard, mouse, joysticks). Joystick specific code should not be there. i dont like it in joysticks_linuxinput. it stands there right before the bigbig ifdef and the only reason it is there, is because it was written for that file in the first place. any suggestions where to move it? on the other hand my other patch does not depend on the move - just on the functions - so we just keep in the linux file until we get the common joystick class. -- cu pgpIe0pxjbGtg.pgp Description: PGP signature
Re: [dinput] initial support for BSD's usbhid joysticks
On Sat, Apr 26, 2008 at 08:57:28AM -0600, Vitaliy Margolen wrote:
Please use 4 spaces indentation, no tabs.
what happened to original author decides? ;)
i will run the uncopied parts through indent once i find the -unreadable
flag for it...
+ snprintf(buf, MAX_PATH, FMT_UHIDDEVS, i);
+ buf[MAX_PATH - 1] = 0;
snprintf always writes terminating '\0' character at the end of the
string. You don't need to explicitly do that yourself.
ack
+ if ((fd = open(buf, O_RDWR | O_NDELAY, 0)) == -1) {
+ TRACE(Unable to open %s read/write: %s\n, buf,
strerror(errno));
+ continue;
+ }
Do you really have to open it read/write? Shouldn't read only be
enough for not FF joystick?
i tested beforehand with usbhidctl - and it needed r/w for just getting
the state there. so i assumed it is needed. i will just try it out.
The only way I can think of to remove code duplication is to create
base joystick class. There were no reason for that with only 2
joystick drivers. With third one should really do it.
Four with an potential xinput implementation.
Some of the functions had subtle changes; but i guess they could be
unified. if there where no FF the interface would be quite small:
- find them
- (un)acquire
- poll
I can not think of stuff, that get/setProperty would really need a
special implementation for. A common JoyDev struct could hold all vital
data; we could keep a private area for the driver around.
But i guess I can go with the release before this changes. We can cope
with the dups later on.
so my next steps are:
- fix above mentioned problems
- test with a TM cougar (6 axes, 28 buttons)
- test more games (GPL, NR2003 - especially ones, that needed patches in
the linux parts some time ago: IL2 and RBR)
i head for a release on monday - if there are no show stoppers ahead,
of course.
BTW: no complains about the autoconf additions?
--
cu
pgpToltWujSYd.pgp
Description: PGP signature
Re: Dan Kegel : winecfg: Restrict dpi slider to sane values.
On Sat, Apr 26, 2008 at 12:54:14PM -0600, Vitaliy Margolen wrote: For anyone who wants more then 150 they can change that in the registry. Honestly I've yet to see a single device with such a high DPI! for the fun of it - i run wine at 144 it is one less than i need: 0:32 !1 [EMAIL PROTECTED]:~% grep DPI /var/log/Xorg.0.log (--) NVIDIA(0): DPI set to (147, 145); computed from UseEdidDpi X config (15 notebook with 1920x1200) -- cu pgp8VZ7auvFi8.pgp Description: PGP signature
Re: dinput: Limit number of supported axis and buttons
On Thu, Apr 24, 2008 at 08:06:07AM -0600, Vitaliy Margolen wrote: +FIXME(Can't support %d axis. Clamping down to 16\n, newDevice-axes); FIXME(Can't support %d axes. Clamping down to 16\n, newDevice-axes); -- cu pgpCuOEwa3C1c.pgp Description: PGP signature
Re: dinput: Limit number of supported axis and buttons [try 2]
On Thu, Apr 24, 2008 at 09:04:11AM -0600, Vitaliy Margolen wrote: ok, don't beat me on this one (i guess i could have asked this also for try one): +FIXME(Can't support %d axes. Clamping down to 16\n, newDevice-axes); ... +WARN(Can't support %d buttons. Clamping down to 128\n, newDevice-buttons); why is axes a FIXME and buttons a WARN? -- cu pgp3Au79OUy5f.pgp Description: PGP signature
Re: ws2_32: Work around the host name resolving to 127.x.x.x when using that for binding.
On Mon, Apr 14, 2008 at 11:04:52PM +0200, Kai Blin wrote: Binding to a specific address is the only easy way of detecting which interface an UDP packet was received on since recvfrom() only gives source address, not destination. Listening on 0.0.0.0 would make impossible to tell which interface a packet was received on. Furthermore, a program that explicitely tries to bind to each interface would fail all but the first bind and possibly bail out. Probably many games that use UDP would break. does then windows actually handle also the other way around? like i listen on 127.0.0.1:12345 in windows and i will not be able to connect to 192.168.1.1:12345 on the same machine? i know it is supported - but i have the nagging doubt, that it will not work the same way as in unix but wine maps this behaviour as as unix would do it the same way. IANAE... Which, as Christoph noted, cause windows apps to bind to loopback addresses, breaking the networking. This only started to happen recently as recently Linux distros started mapping the machine's hostname to a loopback address. I don't think Wine ever used the registry for anything like that. not wine in its guts - the apps. wine now uses the /etc/hosts to determine the ip of the machine and put this informations in the places, where windows keeps them. one of this places was the registry (.../nettrans/tcpip/... or something). some apps use this informations. maybe -- cu pgpnaAc15HyTf.pgp Description: PGP signature
Re: ws2_32: Work around the host name resolving to 127.x.x.x when using that for binding.
On Mon, Apr 14, 2008 at 04:05:23PM +0200, Kai Blin wrote:
Hi Kai, et all,
+static const char magic_loopback_addr[] = {127, 12, 34, 56};
in the past wine used to work quite well with the ip-address configured
using the places in the windows registry (msdn or something similar kept
an howto for setting the ips in win98 and 2k (and look alikes)). now
that wine tries to get its ip from the /etc/hosts (or whereever?) i
noticed some problems with hosting games. as msdn keeps firing errors at
me i go and ask the list about this.
i always though windows (at least until xp?) is not capable of listening
to requests bound to an ip/interface? with the recent changes the games
listen to lo0 and will never ever accept anything. i had to change my
/etc/hosts now to make it work again; yet it will fail with more than
one nic (i have to change /etc/hosts again).
long story short:
- does any windows version at all support the idea behind giving an ip
to listen for connections like unix/linux/bsd does?
- and even if: who runs some windows software in wine that needs this
features and is not able to fix the problem with the firewall or other
restrictions on the unix end?
if no: what would be needed to change the listening to 0.0.0.0 by
default? a patch and a test?
--
cu
pgpsqTiUDK0rC.pgp
Description: PGP signature
Re: WineHQ should discourage the use of cracks
On Tue, Mar 04, 2008 at 04:15:10AM -0800, Dan Kegel wrote: I propose that we change the appdb ratings definitions so that an app that only works with a crack gets no higher than bronze. how about: give it the next state to gold and add a appdb flag, that states may only work if some put in legaly correct term for a crack here flag to the app and then provide the maintainers with a proper explanation of the flag in the UI. if the flag is set, then do not allow the highest state - even if is rated gold. then take of some weeks and weed through the appdb and fix all occurences of the word crack. -- cu pgpkcgzmMg8vu.pgp Description: PGP signature
Re: WineHQ should discourage the use of cracks
On Tue, Mar 04, 2008 at 03:35:11PM +0100, Kai Blin wrote: No argument on the US part. I'm still convinced that by EU laws, you're allowed to crack an app you bought in order to make it run on your software. As this hasn't been tested in court yet, though, I'll concede. IANAL, but since 2008 germany adopted a law from a EU proposal (maybe other countries added it before), that disallows circumventing copy protections at all. so in theory your statement is not true any longer for the EU. -- cu pgp0U6cn8T1Z2.pgp Description: PGP signature
Re: Usable Wine interface
On Mon, Feb 18, 2008 at 03:30:30PM +0800, Dmitry Timoshkov wrote: What's the purpose of running 3 full screen games simultaneously? Perhaps you have to run them with different wine prefixes then. i run all my games in a desktop as big as the root window. this is a must for the game Grand Prix Legends and i grew acustomed to it. i can change to other apps/desktops without screen-res-changes or similar stuff - and there are games out there, that do not need 100% attention - playing Heroes Of Might And Magic mulitplayer comes into my mind here. -- cu pgpqIuPBQMUUI.pgp Description: PGP signature
add HKLM/System/MountedDevices to be added by default
this is suggested on quite some places in appdb to make seucrom based games
come a litle further
---
tools/wine.inf |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/tools/wine.inf b/tools/wine.inf
index c3cb89c..f63fb23 100644
--- a/tools/wine.inf
+++ b/tools/wine.inf
@@ -362,6 +362,8 @@ HKLM,SOFTWARE\Microsoft\Active Setup\Installed
Components\{de5aed00-a4bf-11d1-99
HKLM,SOFTWARE\Microsoft\Active Setup\Installed
Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},IsInstalled,2,1
HKLM,SOFTWARE\Microsoft\Active Setup\Installed
Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},Locale,2,*
HKLM,SOFTWARE\Microsoft\Active Setup\Installed
Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},Version,2,4,74,9273,0
+; SecuROM needs this key
+HKLM,System\MountedDevices,,,
[Nls]
HKLM,System\CurrentControlSet\Control\Nls\Codepage,37,,
--
1.5.3.7
pgpgUKYHLeqmT.pgp
Description: PGP signature
Re: Wine Direct3D progress
On Thu, Dec 20, 2007 at 03:58:05PM +0100, H. Verbeet wrote: OLD CONFIGURATION: Configuration: Core 2 Duo [EMAIL PROTECTED], 2GB RAM, GF 6800 GS Options in wine registry: GLSL, FBO, VideoMemorySize 256, PS, VS, SoftwareEmulation Patches: 3DMark hack ACTUAL CONFIGURATION (bold results): Configuration: Core 2 Duo [EMAIL PROTECTED], 2GB RAM, GF 7900 GT (nvidia 169.04) Options in wine registry: GLSL, FBO, VideoMemorySize 256, PS, VS, SoftwareEmulation Patches: 3DMark hack, small gothic patch, wined3d: rewrite IWineD3DSurfaceImpl_BltOverride colorfill codepath, wined3d: use IWineD3DDeviceImpl_ClearSurface in IWineD3DDeviceImpl_Clear Changing the graphics card skews the results a bit :-/ Unfortunately it's pretty hard to say how much of an impact that has per test. and changing drivers (assumption) and the patches won't help either. -- cu pgpHPbbXCdrA2.pgp Description: PGP signature
d3d fill caps oddity
Hi wined3d devs, i get this message on my notebook (Quadro 570m): fixme:d3d:IWineD3DImpl_FillGLCaps OpenGL implementation supports 32 vertex samplers and 32 total samplers fixme:d3d:IWineD3DImpl_FillGLCaps Expected vertex samplers + MAX_TEXTURES(=8) combined_samplers does anyone want some traces or other infos? or is this a problem most likely going away with the next nvidia driver update? -- cu pgpck1um2CDqN.pgp Description: PGP signature
Re: PulseAudio as a sound output?
On Thu, Oct 11, 2007 at 11:44:03AM +0200, Tijl Coosemans wrote: On Thursday 11 October 2007 04:02:22 Jan Zerebecki wrote: On Wed, Oct 10, 2007 at 06:22:19PM -0500, King InuYasha wrote: That way, there isn't a conflict between audio streams to send to audio output. Any mixing resolves this conflict, the only thing that does not support this is bare oss. I think OSSv4 does. Multiple applications can open the same device and the audio streams will be mixed. i used a very long time oss only with my emu10k card and i never had to use anything else beside - it just worked with everything i did. the pita started since i used alsa (e.g. with software like mumble). -- cu pgpJRK4hJiOtr.pgp Description: PGP signature
Re: Request to be unbanned from #winehq (Jan Zerebecki)
On Mon, Oct 08, 2007 at 08:09:37AM +0200, [EMAIL PROTECTED] wrote: Which program do I have to use to get connected in the #winehq channel? I have truly been out of chatting for a long time. http://www.winehq.org/site/irc -- cu pgpXKn8BUAWak.pgp Description: PGP signature
Re: DInput mouse - where to go from here?
On Thu, Sep 27, 2007 at 04:48:23AM +, L. Rahyen wrote: On Thursday September 27 2007 04:07, Vitaliy Margolen wrote: The point I'm trying to make is: can we once put our right ways of doing things aside and fix something that never worked before? And fix it _for good_! I strongly agree here with Vitaliy. Personally I think that using evdev for this purpose IS the right way. Yes it will not work with remote X but Windows doesn't support this too (as far as I know at least). WINE purpose is to conform with Windows behavior. Therefore use of evdev will be correct. Even if above isn't true (I think it is) full support of remote X by dinput component isn't something useful for about 100% of users anyway. Of course everything above is just my opinion. on the other hand what is the use of playing a game over a remote machine? or are there apps, that suffer from this too? i can only figure out two things: - running a game server (unlikely one uses a direct X session - maybe only for games that need a client to configure the server) - play multiplayer games on one machine exporting it to the network (i doubt many do this - excepcially with windows games; it is more likely the other way around: host a linux game to a buddy with a windows notebook) one other concern i have is compatibility with other platforms. wine runs more or less fine at least on freebsd and osx - and others. so we keep the old code around, right? in general i would like to point out, that we have already similar stuff going on with the joystick drivers. the /dev/js joystick was/is(?) not useable for serious sims, due to its dead zone coming from somewhere in the kernel. so the /dev/input option is there - linux only i asume - which works great. so if the evdev path is a choice one can choose at compile time or even by config: go for it! even if unofficial - the gamers out there are used to hack stuff into wine to make their favourite games work _at_once_ after patches or after release - no matter if they break windows comptibility or other in their wine instance. -- cu pgp9k6fetU7tY.pgp Description: PGP signature
Re: [2/2] winex11: Don't use context-specific info when initializing
On Fri, Aug 10, 2007 at 02:29:49AM -0700, Chris Robinson wrote:
@@ -137,7 +132,7 @@ typedef struct wine_glpbuffer {
} Wine_GLPBuffer;
static Wine_GLContext *context_list;
-static struct WineGLInfo WineGLInfo = { 0 };
+static struct WineGLInfo WineGLInfo;
static int use_render_texture_emulation = 1;
static int use_render_texture_ati = 0;
static int swap_interval = 1;
why is this changed? its a Good Thing to have global structs initialized so
they fail earlier under abuse.
--
cu
pgpf47aSIVUmJ.pgp
Description: PGP signature
Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice
On Thu, Aug 02, 2007 at 06:54:12AM -0600, Vitaliy Margolen wrote: OK, so how do i force my system to use the other implementation (so i can test it) ? I have a Logitech WingMan Extreme (old version). Just (re)move /dev/input/js*. Or in dinput change device name to point to non-existent directory/device (in joystick_linux.c). or on systems with udev and friends just dont load joydev. just evdev. then this devices will not be created (even on non-udev boxes /dev/input/js* would not work). -- cu pgpeGFt7uAtjv.pgp Description: PGP signature
Re: 0001 Add 2 idl files for d3d10
On Mon, Jul 09, 2007 at 12:52:43PM +0200, Kovács András wrote: ... +#define D3D10_VS_OUTPUT_REGISTER_COUNT ( 16 ) +#define D3D10_WHQL_CONTEXT_COUNT_FOR_RESOURCE_LIMIT ( 10 ) +#define D3D10_WHQL_DRAWINDEXED_INDEX_COUNT_2_TO_EXP ( 25 ) +#defineD3D10_WHQL_DRAW_VERTEX_COUNT_2_TO_EXP ( 25 ) here is a space missing? pgpV2aUhXbJ0E.pgp Description: PGP signature
Re: [1/2] uninstaller: add ability to scan HKCU for uninstall entries (Try 2)
On Fri, Jun 01, 2007 at 01:28:36PM -0500, Tom Spear wrote: root is used in more than just FetchUninstallInformation It is used in UninstallProgram. So unless I declare root as a global variable, it would not be accessible by UninstallProgram, and would therefore fail to compile. Also, what if a new root key is added in later on by MS, that allows Uninstall stuff to be placed in it? This way, we just add the name of that new root key to the array. Otherwise, someone has to add another else if (RegOpenKeyExW(.) == ERROR_SUCCESS) root = .; please excuse my bold mail on top of plain ignorance of the windows api - but i would consider finding a key in either the user or the global branch of the registry a task that many developers had to face (even in wine) and i bet there is an API function for that? would it be a Good Thing to add such a thing if not? -- cu pgpbjwd3Nrnnu.pgp Description: PGP signature
Re: Removal of unused audio drivers
On Thu, Apr 12, 2007 at 10:02:31AM +0200, Maarten Lankhorst wrote: There are 5 different audio drivers for linux, I think this is a bit overkill, so I propose to remove the esd and nas drivers, I don't think anyone uses esd, especially that since for that task alsa can be used now since dmix addon. I'm not sure what nas is for, but it seems to be 'network audio system', I haven't seen any use for it, except that it causes a 30 seconds slowdown at showing 'audio' tab in winecfg. I don't think anyone uses it. For esd I think it's best to remove, for nas I'm also for remove, but I'll settle for removing it from winecfg list same way as winearts was disabled for a while. What are your thoughts about this? why do you compile the drivers in - or why do have the files around for them? my audio dialog just shows oss and alsa; the others get dropped at compile time. also there might be other platforms that have to use those audio drivers - why drop something that works? -- cu pgpy27YrPCCdz.pgp Description: PGP signature
Re: Linuxtag 2007
On Mon, Feb 12, 2007 at 04:18:00PM +0100, Stefan Munz wrote: Developers in 1. Germany 2. Europe (incl. Germany) 3. Worldwide (incl. Europe) How many developers work for Codeweavers (as they are for sure the biggest contributor)? isn't finding this number hard for OSS? what makes contributor a devloper? for worldwide then the 873 lines from the AUTHORS file would be start. -- cu pgpHIWbqoMtJq.pgp Description: PGP signature
Re: DirectDrawRenderer=opengl - screen size changeable for final rendering?
On Thu, Feb 08, 2007 at 07:01:04PM +0100, Stefan Dösinger wrote: DirectDraw games access the screen directly by using coordinates from 0, 0 to with, height. If wine makes the surface bigger the rendering will just end up in a corner. The best thing we can do is to scale it, but that is what your monitor does if you set a lower resoltution. thats the point. i dont know how wine handles the ddraw-over-opengl scenario. i just had very blury graphics in JA2. nothing to wonder about as i assume at least one quad is drawn with the image as texture. so the filtering kicks in and voila we have bad image quality. so i wondered if i could configre somewhere to render this quad instead of 800x600 like the app wants it but with 1600x1200 i would get quite some good antialiasing for this old game. this would of course assume, that wine fakes the screen until a redraw, where the polygon is drawn again. if i would just change the res of the monitor there i get also some fsaa for free because the tft would scale it for me - changing the res each time is a cumbersome task for one how does not like to change res at all ;) So you *may* be able to trick the game into using a different resolution, but this will have to be a per-game hack and can't be done in general. assuming that my render a quad theory is right it would work to place a key in the registry, where i would tell the ogl-ddraw-renderer to use my res instead of the one the apps wants. -- cu pgppz6WzZXEPe.pgp Description: PGP signature
DirectDrawRenderer=opengl - screen size changeable for final rendering?
hiho what i ever wondered but never dared to ask: i tried recently the said key with jagged alliance 2. as the game has quite a low resolution 640 or 800 it would be nice to allow higher resolutions when rendering ddraw with opengl (e.g. game wants 800 but for the final rendering use 1600). is this doable via registry or somewhere else? for the files: i run the apps in desktop-mode. -- cu pgpk1mmTmmclW.pgp Description: PGP signature
Re: Howdy! Newbie with keyboard patches.
On Tue, Jan 23, 2007 at 08:58:24AM +0100, Tomas Carnecky wrote: I'm sure I could hack you a small app that takes input events from /dev/input/eventX and uses XTest to fake X key events. That way you could 'map' F13 to Control-F1. I've written a few 'drivers' for input devices (MS Strategic Commander etc) that way.. and it works great. this app allready exists: http://hansmi.ch/software/inputd -- cu pgpISBGQK94BC.pgp Description: PGP signature
Re: Howdy! Newbie with keyboard patches.
On Mon, Jan 22, 2007 at 02:07:34PM -0600, Peter Seebach wrote: I have implemented and tested a patch which is almost certainly unsuitable for production, but which is very convenient to me; it is this patch I enclose. This patch replaces F13-F24 with control-alt-F1 through control-alt-F12, and F25-F32 control-alt-shift-F1 through F8. CTRL+ALT+Fn is used to switch to the text-consoles and back to X11 (at least on linux and openbsd). hardwire this in wine might not be a good idea. -- cu pgpLXk7BKWoBY.pgp Description: PGP signature
[1/4] D3D9: Implement IDirect3DDevice9::StretchRect
This also (partially) fixes the issue with NFS:MW where nothing except the menus appears to be draw when setting the Visual Treatment option to high. The scene is now visible, but its scaled down in the y direction and only covers about the top 2/3 of the screen ...
Re: [dinput 4/5] Add a config for the axes
On Mon, Jan 15, 2007 at 08:03:25PM +0100, Christoph Frick wrote:
This is the replacement for [dinput 4/5] - the other patches still
apply.
--
Add a config for the axes like we do for the buttons
This adds a mapping from the linux input id of the axis to the instance id
we assigned the axis.
dlls/dinput/joystick_linuxinput.c | 122 ++---
1 files changed, 45 insertions(+), 77 deletions(-)
diff --git a/dlls/dinput/joystick_linuxinput.c
b/dlls/dinput/joystick_linuxinput.c
index 0908424..db51236 100644
--- a/dlls/dinput/joystick_linuxinput.c
+++ b/dlls/dinput/joystick_linuxinput.c
@@ -69,9 +69,9 @@ WINE_DEFAULT_DEBUG_CHANNEL(dinput);
#define EVDEVPREFIX/dev/input/event
/* Wine joystick driver object instances */
-#define WINE_JOYSTICK_AXIS_BASE 0
-#define WINE_JOYSTICK_POV_BASE6
-#define WINE_JOYSTICK_BUTTON_BASE 8
+#define WINE_JOYSTICK_MAX_AXES8
+#define WINE_JOYSTICK_MAX_POVS4
+#define WINE_JOYSTICK_MAX_BUTTONS 128
typedef struct EffectListItem EffectListItem;
struct EffectListItem
@@ -140,6 +140,8 @@ struct JoystickImpl
struct ObjProps props[ABS_MAX];
+ int axes[ABS_MAX];
+
/* LUT for KEY_ to offset in rgbButtons */
BYTEbuttons[KEY_MAX];
@@ -352,7 +354,7 @@ static JoystickImpl *alloc_device(REFGUID rguid, const void
*jvt, IDirectInputIm
JoystickImpl* newDevice;
LPDIDATAFORMAT df = NULL;
int i, idx = 0;
-int axis = 0, pov = 0, btn = 0;
+int axis = 0, btn = 0;
newDevice = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
sizeof(JoystickImpl));
if (!newDevice) return NULL;
@@ -367,19 +369,6 @@ static JoystickImpl *alloc_device(REFGUID rguid, const
void *jvt, IDirectInputIm
#ifdef HAVE_STRUCT_FF_EFFECT_DIRECTION
newDevice-ff_state = FF_STATUS_STOPPED;
#endif
- for (i=0;iABS_MAX;i++) {
-/* apps expect the range to be the same they would get from the
- * GetProperty/range method */
-newDevice-props[i].wantmin = newDevice-props[i].havemin =
newDevice-joydev-axes[i][AXIS_ABSMIN];
-newDevice-props[i].wantmax = newDevice-props[i].havemax =
newDevice-joydev-axes[i][AXIS_ABSMAX];
-/* TODO:
- * direct input defines a default for the deadzone somewhere; but as long
- * as in map_axis the code for the dead zone is commented out its no
- * problem
- */
-newDevice-props[i].deadzone = 0;
- }
- fake_current_js_state(newDevice);
/* Create copy of default data format */
if (!(df = HeapAlloc(GetProcessHeap(), 0, c_dfDIJoystick2.dwSize))) goto
failed;
@@ -387,33 +376,47 @@ static JoystickImpl *alloc_device(REFGUID rguid, const
void *jvt, IDirectInputIm
if (!(df-rgodf = HeapAlloc(GetProcessHeap(), 0, df-dwNumObjs *
df-dwObjSize))) goto failed;
/* Supported Axis POVs should map 1-to-1 */
-for (i = 0; i 8; i++)
+for (i = 0; i WINE_JOYSTICK_MAX_AXES; i++)
{
-if (!test_bit(newDevice-joydev-absbits, i)) continue;
+if (!test_bit(newDevice-joydev-absbits, i)) {
+newDevice-axes[i] = -1;
+continue;
+}
-memcpy(df-rgodf[idx], c_dfDIJoystick2.rgodf[axis +
WINE_JOYSTICK_AXIS_BASE], df-dwObjSize);
+memcpy(df-rgodf[idx], c_dfDIJoystick2.rgodf[i], df-dwObjSize);
+newDevice-axes[i] = idx;
+newDevice-props[idx].wantmin = newDevice-props[idx].havemin =
newDevice-joydev-axes[i][AXIS_ABSMIN];
+newDevice-props[idx].wantmax = newDevice-props[idx].havemax =
newDevice-joydev-axes[i][AXIS_ABSMAX];
+newDevice-props[idx].deadzone = 0;
df-rgodf[idx++].dwType = DIDFT_MAKEINSTANCE(axis++) | DIDFT_ABSAXIS;
}
-for (i = 0; i 4; i++)
+
+for (i = 0; i WINE_JOYSTICK_MAX_POVS; i++)
{
if (!test_bit(newDevice-joydev-absbits, ABS_HAT0X + i * 2) ||
-!test_bit(newDevice-joydev-absbits, ABS_HAT0Y + i * 2))
+!test_bit(newDevice-joydev-absbits, ABS_HAT0Y + i * 2)) {
+newDevice-axes[ABS_HAT0X + i * 2] = newDevice-axes[ABS_HAT0Y + i
* 2] = -1;
continue;
+}
-memcpy(df-rgodf[idx], c_dfDIJoystick2.rgodf[pov +
WINE_JOYSTICK_POV_BASE], df-dwObjSize);
-df-rgodf[idx++].dwType = DIDFT_MAKEINSTANCE(pov++) | DIDFT_POV;
+memcpy(df-rgodf[idx], c_dfDIJoystick2.rgodf[i +
WINE_JOYSTICK_MAX_AXES], df-dwObjSize);
+newDevice-axes[ABS_HAT0X + i * 2] = newDevice-axes[ABS_HAT0Y + i *
2] = i;
+df-rgodf[idx++].dwType = DIDFT_MAKEINSTANCE(i) | DIDFT_POV;
}
+
/* Buttons can be anywhere, so check all */
-for (i = 0; i KEY_MAX btn 128; i++)
+for (i = 0; i KEY_MAX btn WINE_JOYSTICK_MAX_BUTTONS; i++)
{
if (!test_bit(newDevice-joydev-keybits, i)) continue;
-memcpy(df-rgodf[idx], c_dfDIJoystick2.rgodf[btn +
WINE_JOYSTICK_BUTTON_BASE], df-dwObjSize);
+memcpy(df-rgodf[idx], c_dfDIJoystick2.rgodf[btn
WineD3D: ProcessVertices
Henri Verbeet wrote: Well, you can't set a VBO as rendertarget directly, but you can copy the FBO data into a PBO, which you can bind as a VBO. That's pretty legitimate in OpenGL. But I was wondering how hard it would be to use something like that for ProcessVertices. Well, you would get the rendered pixels' data written to the VBO then, right? To use this for ProcessVertices one would have to have a bijective relation between pixel's and processed vertices; p.e. pass the transformed vertex coordinates in varying variables and use'em as the color components and have the pixels stored in the order the vertices are so we can tell afterwards from what vertex they originate, in passing the vertex index as an attribute and so generate appropriate vertex coords ... theoretically. I don't think its easy or even possible to have exactly one pixel per vertex at sequential positions in the pixel buffer, or is it (using points and knowing the resolution etc.) ?
Re: [dinput 4/5] Add a config for the axes
On Mon, Jan 15, 2007 at 10:42:10AM -0700, Vitaliy Margolen wrote: df-rgodf[idx++].dwType = DIDFT_MAKEINSTANCE(axis++) | DIDFT_ABSAXIS; } -for (i = 0; i 4; i++) + +idx = WINE_JOYSTICK_MAX_AXES; Why are you creating a gap? This is exactly the point here to skip all the objects that we do not have. And they all need to be sequential in godf - no gaps. Otherwise you braking EnumObjects. you are right. funny thing is - everything works with this patches :/ i will drop the two idx assigns and resubmit the patch. -- cu pgpaoMUOrdkfV.pgp Description: PGP signature
[15/20] WineD3D: Clean up drawprim a bit
Stefan Dösinger wrote: We will need software shaders for a correct implementation of IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I don't really think OpenGL feedback mode is what we want here. Maybe we should remove it for now, but keep the code somewhere(in the wiki maybe). If someone is extra-ambitious we can do something like Softwire/SwiftShader does. But I think ProcessVertices is a good oportunity to verify our vertex shader implementation. Sounds fun *g* ... I thought of generating Intel assembly code from the vertex shader bytecode on the fly, just like GLSL and ARB shaders are generated, using primarily SSE for doing the floating point computations (in situations where it brings an advantage), and directly referencing the memory at IWineD3DVertexShaderImpl-data,input,output (load constants, input data, store temporary values, store output data). Would something like that even be accepted in wine ? I'm already 'experimenting' a bit, but as I don't have much time these days don't count on it to be finished within the next 3 months, or ever, after all I might also get so desperate with it and stop working on it altogether ... I've never written anything similar before. The main reason for this mail is to know whether someone else is working on a solution for doing software vshaders already, and if so, rather invest the time in my other studies (I'm running behind there ...), before having two people work at the same thing.
Re: [dinput][joystick_linuxinput] make axes work, that are not in a row
On Thu, Jan 11, 2007 at 01:10:21PM -0700, Vitaliy Margolen wrote: What you described is SetProperty(DIPROP_RANGE). What I'm talking about is the range we get from device itself. In the map_axis we have: if (val hmax) This-joydev-havemax[axis] = hmax = val; if (val hmin) This-joydev-havemin[axis] = hmin = val; to my knowledge this code is useless. it got copied over from the /dev/js branch. We either need to query the device for what it's ranges are, or use default range (as it's done in joystick_linux). we allready query it. see the code in alloc_device where the have(min|max) is set. Right. But can we query device for the current axes position? They are analog devices, and should provide absolute position. well instead of using ...[AXE_ABS] (another axe) we could use the current value from the device. what it is worth for is this: i bet nearly all apps just call alloc_device and SetProperty in the beginning or when some config is involved. so AXE_ABS is for sure between MIN/MAX (kernel should assert that) and in nearly all cases represent the null-state of the device. so if someone fiddles with this input device between find_joydevs and alloc/setprop the value in DJOYSTATE2 would be wrong. IMHO its not worth the hastle there. -- cu pgpUO8nG79M4C.pgp Description: PGP signature
Re: [dinput][joystick_linuxinput] make axes work, that are not in a row
On Thu, Jan 11, 2007 at 10:25:51AM -0700, Vitaliy Margolen wrote:
attached a patch with all the suggestions for Vitaliy.
Christoph Frick wrote:
with Vitaliy's patches i tried my games yesterday and everything seemed
ok (RBR works again). but my clutch on the wheel did not work and also
That's a good news. I was hopping not to brake too many things while
reorganizing the dinput.
@@ -128,11 +122,20 @@ struct JoystickImpl
/* The 'parent' DInput */
IDirectInputImpl *dinput;
+ /* autodetecting ranges per axe by following movement */
+ LONGhavemax[8];
+ LONGhavemin[8];
I could never understood why we need these? In other joystick_linux the
range assumed to be 0 - 0x.
/* joystick private */
/* what range and deadzone the game wants */
- LONGwantmin[ABS_MAX];
- LONGwantmax[ABS_MAX];
- LONGdeadz[ABS_MAX];
+ LONGwantmin[8];
+ LONGwantmax[8];
+ LONGdeadz[8];
Can we move these into separate struct like it's done in joystick_linux?
It's much cleaner end eventually will allow a better integration of two.
And can you use spaces instead of tabs please?
@@ -395,19 +373,29 @@ static JoystickImpl *alloc_device(REFGUID rguid,
const void *jvt, IDirectInputIm
/* Supported Axis POVs should map 1-to-1 */
for (i = 0; i 8; i++)
{
-if (!test_bit(newDevice-joydev-absbits, i)) continue;
+if (!test_bit(newDevice-joydev-absbits, i)) {
+ newDevice-axes[i] = -1;
+ continue;
+}
Can you please don't brake the good readable style? Please put that
curly bracket into separate line, and use 4 space indentation.
+fake_current_js_state(newDevice);
+
Can you explain what this suppose to do? Why do we need to fake current
state everywhere?
+int axe = This-axes[ie.code];
It's an axis not an axe :)
--
diff --git a/dlls/dinput/joystick_linuxinput.c
b/dlls/dinput/joystick_linuxinput.c
index e2f77f8..640c8d9 100644
--- a/dlls/dinput/joystick_linuxinput.c
+++ b/dlls/dinput/joystick_linuxinput.c
@@ -70,8 +70,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(dinput);
/* Wine joystick driver object instances */
#define WINE_JOYSTICK_AXIS_BASE 0
-#define WINE_JOYSTICK_POV_BASE6
-#define WINE_JOYSTICK_BUTTON_BASE 8
+#define WINE_JOYSTICK_POV_BASE8
+#define WINE_JOYSTICK_BUTTON_BASE 12
typedef struct EffectListItem EffectListItem;
struct EffectListItem
@@ -111,12 +111,15 @@ struct JoyDev {
/* data returned by the EVIOCGABS() ioctl */
int axes[ABS_MAX][5];
- /* LUT for KEY_ to offset in rgbButtons */
- BYTEbuttons[KEY_MAX];
+};
- /* autodetecting ranges per axe by following movement */
- LONGhavemax[ABS_MAX];
- LONGhavemin[ABS_MAX];
+struct ObjProps
+{
+LONG havemin;
+LONG havemax;
+LONG wantmin;
+LONG wantmax;
+LONG deadzone;
};
struct JoystickImpl
@@ -128,11 +131,13 @@ struct JoystickImpl
/* The 'parent' DInput */
IDirectInputImpl *dinput;
- /* joystick private */
- /* what range and deadzone the game wants */
- LONGwantmin[ABS_MAX];
- LONGwantmax[ABS_MAX];
- LONGdeadz[ABS_MAX];
+struct ObjProps props[8];
+
+/* LUT for the mapping of used axes */
+int axes[ABS_MAX];
+
+ /* LUT for KEY_ to offset in rgbButtons */
+ BYTEbuttons[KEY_MAX];
int joyfd;
@@ -177,7 +182,7 @@ static void find_joydevs(void)
struct JoyDev joydev = {0};
int fd;
int no_ff_check = 0;
-int j, buttons;
+int j;
snprintf(buf,MAX_PATH,EVDEVPREFIX%d,i);
buf[MAX_PATH-1] = 0;
@@ -246,7 +251,7 @@ static void find_joydevs(void)
for (j=0;jABS_MAX;j++) {
if (test_bit(joydev.absbits,j)) {
if (-1!=ioctl(fd,EVIOCGABS(j),(joydev.axes[j]))) {
- TRACE( ... with axe %d: cur=%d, min=%d, max=%d, fuzz=%d,
flat=%d\n,
+ TRACE( ... with axis %d: cur=%d, min=%d, max=%d, fuzz=%d,
flat=%d\n,
j,
joydev.axes[j][AXE_ABS],
joydev.axes[j][AXE_ABSMIN],
@@ -254,21 +259,10 @@ static void find_joydevs(void)
joydev.axes[j][AXE_ABSFUZZ],
joydev.axes[j][AXE_ABSFLAT]
);
- joydev.havemin[j] = joydev.axes[j][AXE_ABSMIN];
- joydev.havemax[j] = joydev.axes[j][AXE_ABSMAX
Re: [dinput][joystick_linuxinput] make axes work, that are not in a row
On Thu, Jan 11, 2007 at 10:25:51AM -0700, Vitaliy Margolen wrote:
@@ -128,11 +122,20 @@ struct JoystickImpl
/* The 'parent' DInput */
IDirectInputImpl *dinput;
+ /* autodetecting ranges per axe by following movement */
+ LONGhavemax[8];
+ LONGhavemin[8];
I could never understood why we need these? In other joystick_linux the
range assumed to be 0 - 0x.
linux/input.h reports us the proper ranges from the device. these
numbers will also be used as teh want(min|max). so what this numbers are
good for. apps that want the input as pure as it gets dont
SetProperty some something and just get what the hardware tells them
(e.g. RBR does so).
/* joystick private */
/* what range and deadzone the game wants */
- LONGwantmin[ABS_MAX];
- LONGwantmax[ABS_MAX];
- LONGdeadz[ABS_MAX];
+ LONGwantmin[8];
+ LONGwantmax[8];
+ LONGdeadz[8];
Can we move these into separate struct like it's done in
joystick_linux? It's much cleaner end eventually will allow a better
integration of two.
i will do this.
And can you use spaces instead of tabs please?
of course
@@ -395,19 +373,29 @@ static JoystickImpl *alloc_device(REFGUID rguid,
const void *jvt, IDirectInputIm
/* Supported Axis POVs should map 1-to-1 */
for (i = 0; i 8; i++)
{
-if (!test_bit(newDevice-joydev-absbits, i)) continue;
+if (!test_bit(newDevice-joydev-absbits, i)) {
+ newDevice-axes[i] = -1;
+ continue;
+}
Can you please don't brake the good readable style? Please put that
curly bracket into separate line, and use 4 space indentation.
sorry - to a KR guy that uses ts=8 as default this all is unreadable
gibberish; i will try my best here.
+fake_current_js_state(newDevice);
Can you explain what this suppose to do? Why do we need to fake
current state everywhere?
after e.g. SetProperties and initializing the device we have to put the
values of the DIJOYSTATE2 in a sane state. e.g. GPL set the ranges to
1000-25k; where my pedals are in 0..512; so the app gets in the next
step after the setting a default value of 512 (clutch not pressed) and
gets nuts.
+int axe = This-axes[ie.code];
It's an axis not an axe :)
it was 0300 and i guess i wished for an axe there ;)
--
cu
pgptmUBvH3A6e.pgp
Description: PGP signature
Re: dinput, wheel/joystick and richard burns rally
On Sun, Jan 07, 2007 at 10:22:34PM +0200, Tuomo Kohvakka wrote: http://appdb.winehq.org/appview.php?iVersionId=5934iTestingId=6382 As shown there, joystick (that ofcourse really means the wheel :) isn't detected by the game with current wine. I decided to take a look at that, figuring that it might be fixable. the problem here is somehow deeper within wine. we store a dataformat as default with the device, that does not represent the informations sent to the app. so when an app want to build its own data-format using the infos there. so the problem was actually fixed some time ago but the fix got lost with a huge clean up session. so there is actually currently work undergoing, that fixes the problem (see the mails about RBR before the holidays). (/* Then check if it accepts any instance id, and if not, if it matches Wine's * instance id. */ ((asked_format-rgodf[j].dwType DIDFT_INSTANCEMASK) == DIDFT_ANYINSTANCE) || (DIDFT_GETINSTANCE(asked_format-rgodf[j].dwType) == 0x00FF) || /* This is mentionned in no DX docs, but it works fine - tested on WinXP */ imho this already does not make sense.. (DIDFT_GETINSTANCE(asked_format-rgodf[j].dwType) == DIDFT_GETINSTANCE(format-wine_df-rgodf[i].dwType))) Now, adding || ((asked_format-rgodf[j].dwType0xff) == (format-wine_df-rgodf[i]. =dwType0xff)) ... but then adding the next magic check is wrong. but this is a gut-feeling and maybe there are already new problems introduced with the recent patches. for my part i can at least say, that everythings is working in WINE's head trunk - except RBR with the same problem as before xmas. for what i have seen Vitaliy has build the ground to finally make the same patches for the joysticks as for keyboard and mouse? -- cu pgpEwD3ifF58y.pgp Description: PGP signature
Re: [2/8] WineD3D: Catch NOP vertex declaration changes
Zitat von H. Verbeet [EMAIL PROTECTED]: Nah, it's correct that the refcounts are broken at the moment. What Stefan probbly meant was that we might as well remove refcounting completely from that fucntion. Then so should the AddRef/Release be removed from the StateBlock's Capture function as well. If you set p.e. vertex declaration to 0, then you start recording, set vertex declaration to some object (ref still 1), then stop recording and get the stateblock, and then let this block Capture the device stateblock, the refcount of object would be decreased to 0 since the capturing stateblock's value of vertex declaration is object, the device's is 0, and so stateblock would Release the object it holds.
[2/8] WineD3D: Catch NOP vertex declaration changes
Not performing the following:
if (NULL != pDecl) {
IWineD3DVertexDeclaration_AddRef(pDecl);
}
in IWineD3DDeviceImpl_SetVertexDeclaration(...) when state is being
recorded (note the return that was added), seems to cause a page fault,
at least in NFS: Most Wanted. Is it possible that not adding a
reference here causes the declaration object to be deallocated to
early, when it is still used by the application ?
[2/8] WineD3D: Catch NOP vertex declaration changes
Yet the application (NFS:MW) page faults right at startup at the
address of pDecl + 4 so something's amiss ... maybe this will get fixed
automatically in one of the next patches or is due to some other weird
thing that affects my sources (eh?) ... as long as no one else
complains, lets leave it at this.
Just look again at the SetPixelShader function, this is how it looks in
my current GIT (I didn't touch this one) :
3758 /* Handle recording of state blocks */
3759 if (This-isRecordingState) {
3760 TRACE(Recording... not performing anything\n);
3761 }
3762 3763 if (NULL != pShader) {
3764 IWineD3DPixelShader_AddRef(pShader);
3765 }
3766 if (NULL != oldShader) {
3767 IWineD3DPixelShader_Release(oldShader);
3768 }
3769 3770 if (This-isRecordingState) {
3771 TRACE(Recording... not performing anything\n);
3772 return WINED3D_OK;
3773 }
3774 3775 if(pShader == oldShader) {
3776 TRACE(App is setting the old pixel shader over, nothing
to do\n);
3777 return WINED3D_OK;
3778 }
[4/4] wined3d: Create samplers for *all* 1.x instructions that sample
Note that WINED3DSIO_TEXDP3TEX, WINED3DSIO_TEXM3x3VSPEC,
WINED3DSIO_TEXM3x3SPEC are already handled in the 2 else if branches
below, they should probably be
removed somewhere.
@@ -295,8 +295,15 @@ HRESULT shader_get_registers_used(
if
(WINED3DSHADER_VERSION_MAJOR(This-baseShader.hex_version) == 1
(WINED3DSIO_TEX == curOpcode-opcode ||
WINED3DSIO_TEXBEM == curOpcode-opcode ||
+ WINED3DSIO_TEXBEML == curOpcode-opcode ||
+ WINED3DSIO_TEXDP3TEX == curOpcode-opcode ||
WINED3DSIO_TEXM3x2TEX == curOpcode-opcode ||
- WINED3DSIO_TEXM3x3TEX == curOpcode-opcode)) {
+ WINED3DSIO_TEXM3x3SPEC == curOpcode-opcode ||
+ WINED3DSIO_TEXM3x3TEX == curOpcode-opcode ||
+ WINED3DSIO_TEXM3x3VSPEC == curOpcode-opcode ||
...
} else if
(WINED3DSHADER_VERSION_MAJOR(This-baseShader.hex_version) == 1
(WINED3DSIO_TEXM3x3SPEC == curOpcode-opcode ||
WINED3DSIO_TEXM3x3VSPEC == curOpcode-opcode)) {
Re: [dinput] regression c17e06d5c0e456d3052a1b6de688956f87c59d3e: No need to copy default constant format. Use already defined static instead
On Wed, Dec 20, 2006 at 10:27:52AM -0700, Vitaliy Margolen wrote: The biggest problem is we don't properly initialize device. We should create our own data format structure that has only found objects. So we don't need to do it over and over again in EnumObjects or GetObjectInfo. In the joystick_linuxinput i have added such search what we have already some month ago so support more than one device. so if i catch your drift here we would again set up on a per-device-base a DataFormat - which then could also be used for EnumObjects and GetObjectInfo, right? i can help on that end at least on the input edge of code - under your supervision. -- cu pgpFTVazXwkuW.pgp Description: PGP signature
[dinput] regression c17e06d5c0e456d3052a1b6de688956f87c59d3e: No need to copy default constant format. Use already defined static instead
hiho with that patch: commit c17e06d5c0e456d3052a1b6de688956f87c59d3e Author: Vitaliy Margolen [EMAIL PROTECTED] Date: Sun Dec 10 14:15:08 2006 -0700 dinput: No need to copy default constant format. Use already defined static instead. :100644 100644 c5a35a1... 369c26d... M dlls/dinput/joystick_linuxinput.c The game Richard Burns Rally does no longer get any events. The game worked after some patches some month ago from me. As i had no intention on that pages to make things right but to make the game work i might have not picked the optimal solution. But this patches fixed all the apps, that worked with their own DataFormat. So the problem is like that: The old code copied the default constant format and applied caclulate_ids on it. So the dwTypes where set with proper MAKEINSTANCE(...) calls. So an app, that requested later its own data format with SetDataFormat using the data from EnumObjects. After the change now the default const has ANY_INSTANCE all over the place but the app request a certain instance - so on SetDataFormat there are no matches. So the big question is: is our SetDataFormat wrong or is this patch wrong? Please advice. -- cu pgpOi3YYA3uln.pgp Description: PGP signature
Re: Re: ntdll/signal_i386.c: __wine_enter_vm86 issue
Zitat von Markus Amsler [EMAIL PROTECTED]: Christoph Bumiller wrote: I tried to run some DOS games with wine recently and since most of them crashed I would call this a success, since not ALL of them crashed :-). Winedos is far from a complete DOS emulation. Well, unfortunately those that did NOT crash just did nothing :-( ... I can't comment the vm86 stuff, but no input is because the unix process gets the signal and not the unix thread. Try this patch: http://www.winehq.org/pipermail/wine-patches/2004-November/013645.html It's a while back, so you probably have to manually apply it. Yep .. it (the patch) works, at least for Blade of Destiny which is now actually playable (!) (without sound yet, though). Why hasn't it been merged?
ntdll/signal_i386.c: __wine_enter_vm86 issue
I tried to run some DOS games with wine recently and since most of them crashed with a page fault I tried to find out why and so, examining the last function calls before faulting revealed that when __wine_enter_vm86 in signal_i386.c returns from res = vm86_enter(...) and encounters a VM86TYPE(res) == VM86_UNKNOWN it calls the raise_segv_exception, which in turn calls NtSetContextThread. This one calls set_cpu_context which tries to reload the context of the VM86 thread an, of course, crashes since it can't load the segment registers with invalid (non GDT) values. Backtrace: =1 0x7efe2a57 in ntdll (+0x52a57) (0x7d55e348) 2 0x7efd9a8d NtSetContextThread+0x77() in ntdll (0x7d55e478) 3 0x7efd412e in ntdll (+0x4412e) (0x7d55e498) 4 0x7efd5032 __wine_enter_vm86+0x1d6() in ntdll (0x7d55e608) 5 0x7eeb9b15 K32WOWCallback16Ex+0x417() in kernel32 (0x7d55e668) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported constant max_clusters in function fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported constant max_sectors_per_cluster in function fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported constant max_bytes_per_sector in function 6 0x7d6f50bb DOSVM_Enter+0xab(context=0x7d55e760) [/home/chr/WINE/CVS_BUILD/dlls/winedos/dosvm.c:586] in winedos (0x7d55e748) 7 0x7d71254b MZ_DOSVM+0xbb(lpExtra=0x0) [/home/chr/WINE/CVS_BUILD/dlls/winedos/module.c:638] in winedos (0x7d55ea48) 8 0x7eeacdf6 in kernel32 (+0x6cdf6) (0x7d55eb28) 9 0x7efd9939 in ntdll (+0x49939) (0x7d55f448) 10 0xb7de1512 start_thread+0x84() in libpthread.so.0 (0x7d55f4d8) 11 0xb7d7afde __clone+0x5e() in libc.so.6 (0x) 0x7efe2a57: pop %es My question, is this a bug, and, if so, what should be done to correct it? Is it sufficient to just make raise_segv_exception return if context-Eflags indicate VM86 instead of calling NtSetContextThread ? In my example (Realms of Arkania: Blade of Destiny) this lets the app continue and I get the initial text box to select difficulty level. But ... the process doesn't handle any input - events are queued but never handled p.e. by DOSVM_Wait or similar ... Unfortunately I don't know much about this stuff ... what procedure is responsible to handle these asynchronous events and when ?
Re: Regression in patch: OpenGL32: remove glx context
On Wed, Nov 08, 2006 at 10:32:05PM +0100, Mirek wrote: Here is some small report from terminal: cvswine glsl_bump_mapping.exe err:wgl:process_attach X11DRV or GDI32 not loaded. Cannot create default context. err:module:LdrInitializeThunk opengl32.dll failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for LG:\\usr\\games\\nvidiaSDK\\DEMOS\\OpenGL\\bin\\Release\\glsl_bump_mapping.exe failed, status c142 i would like to second that. Undercover/Operation Hellfire also bails out with the ``err``. as the error message is not so helpful i splitted it into two and the missing dll here is the x11drv. before the change there was the creation of the root-window/desktop before the call and a grep for x11drv only revealed the the desktop creation is - at least the only place i could find - where it seemed like it would be loaded. i tried starting e.g. progman manually before the game to have desktop - but the error is the same. fyi i run all my apps with a fullscreen desktop-setting - and i have not yet tried without it. -- cu pgpsfjlpQkxfX.pgp Description: PGP signature
Re: Executing wine over make segfaults.
On Mon, Nov 06, 2006 at 10:29:22PM +0800, Dmitry Timoshkov wrote: 3) I'm using exec-shield patch, but I can disable it (for sure, tested by the pax testing suite) using a procfs entry. Even with exec-shield disabled the crash is still there, and in 2.6.17, even with exec-shield enabled, there is no crash. Then probably the only way to unbreak the broken apps is to add noexec=off to the kernel command line. this is what i did - and also suggest quite some time ago him(?)/list. i had the same problem since .16 kernels (unstable(~) gentoo-source ebuild). since that change everything works fine (.18 now). -- cu pgp6W1XoUcz12.pgp Description: PGP signature
Re: Patch for opengl32.dll.so
On Fri, Nov 03, 2006 at 01:57:33PM +0100, Roderick Colenbrander wrote: one of the patches from 2006-10-31 fixed my problems as it seems. IL2 now crashed out 1 of 4 starts but with another error. the remaining stuff is fine - although NASCAR 2003 is very slow now. Regarding the slowness of nascar2003 is it caused by the recent patches a none of them have really changed the code. The patches I have sent have mainly changed the location of the code (location in opengl32.dll/gdi32.dll/winex11.drv). The only change that could have had performance implications was the pixel format of august/september. i will go and bisect for it... -- cu pgpze1F73jr69.pgp Description: PGP signature
Re: Patch for opengl32.dll.so
On Thu, Nov 02, 2006 at 05:46:07PM +0100, Christoph Frick wrote: Hmm, if that is indeed the case this patch could work for them. The whole issue is new for me, I'll see what I can do about it. Right now there's some GLX code in opengl32 which creates an opengl context. I was planning to replace it with WGL code, that might help too (if I load the function pointers afterwards). Perhaps Alexandre has an idea how to correctly fight the race condition. just for the files: the glGetIntegerv is also the last thing that the java stacktrace of IL2 shows up. i will try this patch against all the games, that are no longer working on my end. one of the patches from 2006-10-31 fixed my problems as it seems. IL2 now crashed out 1 of 4 starts but with another error. the remaining stuff is fine - although NASCAR 2003 is very slow now. -- cu pgpts4QZID6b8.pgp Description: PGP signature
Re: Patch for opengl32.dll.so
On Thu, Nov 02, 2006 at 02:25:33PM +0100, Roderick Colenbrander wrote: Hmm, if that is indeed the case this patch could work for them. The whole issue is new for me, I'll see what I can do about it. Right now there's some GLX code in opengl32 which creates an opengl context. I was planning to replace it with WGL code, that might help too (if I load the function pointers afterwards). Perhaps Alexandre has an idea how to correctly fight the race condition. just for the files: the glGetIntegerv is also the last thing that the java stacktrace of IL2 shows up. i will try this patch against all the games, that are no longer working on my end. -- cu pgp5czZcpaIaO.pgp Description: PGP signature
Re: WGL: wglGetProcAddress
On Wed, Oct 25, 2006 at 12:07:44AM +0200, Roderick Colenbrander wrote: Hi Roderick, This patch reimplements opengl32's wglGetProcAddress. The endresult is a more reliable function which doesn't directly call X functions. I have tested this patch against current GIT and still i dont get any of my games running. one thing i tried - as i assumed maybe there is a circular dependency - was commenting out the call of dlls/opengl32/wgl.c - void internal_glGetIntegerv: wine_wgl.p_wglGetIntegerv(pname, params); and then at least racer [1] seem to work. yet the folloing games crash quite in the beginning. - IL2 Sturmovik/Pacific Fighters - NASCAR 2003 (GTP Mod) - Grand Prix Legends - Operation Hellfile (Wintersonne) Demo [2] I have applied your patch and did a make clean to have not to bother with ignored dependencies and did after the make install a removal of the opengl32.dll in the win-dir and a wineprefixcreate. have i missed anything? i tested against nvidia drivers 87XX and 9626 and d3d apps and native opengl apps are running fine. [1] http://racer.nl/dl_beta.htm [2] http://www.3dgamers.com/dlselect/games/undercover/operationwintersonnedemo.exe.html -- cu pgptQhT710TWA.pgp Description: PGP signature
Re: When to use SUBLANG_NEUTRAL
On Mon, Oct 23, 2006 at 02:28:01PM +0200, Miko??aj Zalewski wrote: IMO the question is what would an Austrian user (who have chosen German as his preferred language) want to see if there is no such translation: the German spelling or English? I don't know the answer but I'd expect that if the differances are minor then German? He or she wants de; anything else would be like: ``there is no en_UK? then lets use mongolian!``. -- cu pgpV0gpvOWycS.pgp Description: PGP signature
d3d/dx8 GLSL-patch shader question: access on VC constants out of bounds
hiho the game LFS[1] uses in its shaders constants with high numbers (c10-c17,c90-c95); so in sum no problem. but due to check against the OpenGL implemented maximum (in my case VC[31]) the shaders wont work anymore (array out of bounds). is this due to recently discussed max/4 is correct but old nvidia driver reports wrong numers-problem or is this something new? would it be possible to map the constants from the shader into the vertex program using a look-up-table so we just need to allocate a VC-array there with the actualy used size and so the check against the maximum of uniforms would make sense again? [1] http://www.liveforspeed.net/?page=downloads -- cu pgpLZOpDGhQyo.pgp Description: PGP signature
Re: Copy protection
On Wed, Oct 04, 2006 at 07:10:41PM +0200, Kopfgeldjaeger wrote: 2. raw disk access normally requires root rights. It's very unlikely that Alexandre would permit anything which requires to run wine as root (even if those are only additional features) and its very unlikely, that a sane person would WINE allow writing to the MBR (or close to it). right? -- cu pgpvVoCevT3GP.pgp Description: PGP signature
Re: Copy protection
On Thu, Oct 05, 2006 at 04:25:38AM -0400, Tim Schmidt wrote: What we're talking about here is a class of applications that expect raw (or nearly-raw) disk access: - copy-protection that writes mysterious things to or near the MBR - various utility software (virus scanners, disk defragmenters, forensic tools, etc.) - other possibilities? IMHO you can rule out #2. the majority of people using wine want to use their last few remaining apps they have no counterpart for unix and all their games. all these are copy-protection-pestered. the #2 folks are proficient enough with their systems to know what they are doing. the #1 folks hope to get away from the world of #2 things they are forced on the windows world when they change to unix. so #1 is definetly something that should be done with files - not disks - to prevent the masses from fiddling with /dev/sda permissions or running WINE as root. for the law point of view - i though about it from the comments of yesterdays discussion. reducing this to the plain thing i guessed so far: - assuming windows dont let anyone write directly to the disk the app has to gain some higher privs first - as this is no go for most of the admins out there i assume this apps install their .sys files all over the place and run as drivers so they get that extra privs granted - so here comes my big blank: once they have the privs: do the drivers actually work the machine or are they still using the win-api for stuff like writing to the disk? if the winapi is used i would asume there is no law-problem other than all the law problem we allready have. but if they directly access the machine - can we actually intercept it? -- cu pgpOhf6R810Jt.pgp Description: PGP signature
Re: Copy protection
On Wed, Oct 04, 2006 at 09:41:16AM -0500, Tom Spear wrote: I should add that I just thought about this and realized that we _could_ always just encrypt the contents of the file as it is written and read, so that we can actually get somewhere, and not be exposing sensitive data at the same time, but it's just a thought. Anyone care to comment on that? what keeps some nosy haxx0r from looking in the MBR (or some blocks later) if he wants to find out about the copy protection? if they store data like this unprotected (e.g. crypting them) then this is just security-by-obscurity (which is no security at all). the difference in the people able to read this data is just total fool to fool ;) on the other hand you have your point with the way a court might sees things. i think there is more of a problem with data theft. once i grab your .wine/drives/c:/.windows-mbr file i might end up with your ps/dw/... keys. its not even a problem to guess the location of that file. assuming that the key is there stored directly - finding WINE users with a legal and running copy of this software and the machine WFO to grab it... i guess i a better off with a hit-and-run in the local software store to get the software or just install some crack. -- cu pgp80jdg58o81.pgp Description: PGP signature
Re: Copy protection
On Wed, Oct 04, 2006 at 04:09:51PM +0100, Martin Owens wrote: Anyone techinicaly adept could find the MBR, it's the 1st sector on the disk, this isn't about boot records but the MBR which is in a known place. I recon you could use linux tools on your windows hard drive to retrieve it easy. you could also use debug.exe (or was it com) shipping with dos/windows. might even be there in current version? -- cu pgp5dkeVDq5Dd.pgp Description: PGP signature
[PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
hi
would someone please comment on that patch? this is a nearly unchanged
version of my previous attempt - but this time against current git.
---
dlls/winex11.drv/settings.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/dlls/winex11.drv/settings.c b/dlls/winex11.drv/settings.c
index 5de07eb..c9bced2 100644
--- a/dlls/winex11.drv/settings.c
+++ b/dlls/winex11.drv/settings.c
@@ -39,7 +39,8 @@ static LPDDHALMODEINFO dd_modes = NULL;
static unsigned int dd_mode_count = 0;
static unsigned int dd_max_modes = 0;
static int dd_mode_default = 0;
-static const unsigned int depths[] = {8, 16, 32};
+static const unsigned int depths[] = {8, 16, 32, 24};
+static const unsigned int nr_depths = sizeof(depths) / sizeof(depths[0]);
/* pointers to functions that actually do the hard stuff */
static int (*pGetCurrentMode)(void);
@@ -62,7 +63,7 @@ LPDDHALMODEINFO X11DRV_Settings_SetHandl
TRACE(Resolution settings now handled by: %s\n, name);
if (reserve_depths)
/* leave room for other depths */
-dd_max_modes = (3+1)*(nmodes);
+dd_max_modes = nr_depths*nmodes;
else
dd_max_modes = nmodes;
@@ -111,7 +112,7 @@ void X11DRV_Settings_AddDepthModes(void)
int existing_modes = dd_mode_count;
DWORD dwBpp = screen_depth;
if (dwBpp == 24) dwBpp = 32;
-for (j=0; j3; j++)
+for (j=0; jnr_depths; j++)
{
if (depths[j] != dwBpp)
{
@@ -164,8 +165,6 @@ void X11DRV_Settings_Init(void)
*/
BOOL X11DRV_EnumDisplaySettingsEx( LPCWSTR name, DWORD n, LPDEVMODEW devmode,
DWORD flags)
{
-DWORD dwBpp = screen_depth;
-if (dwBpp == 24) dwBpp = 32;
devmode-dmDisplayFlags = 0;
devmode-dmDisplayFrequency = 0;
devmode-dmSize = sizeof(DEVMODEW);
--
1.4.2
Re: WGL patches cause problems with RBR and LFS
On Thu, Sep 07, 2006 at 12:07:30PM +0200, Roderick Colenbrander wrote: Hmm, strange. Could you run the programs using WINEDEBUG=+wgl appname.exe and post me the logs? Strange indeed. please ignore this. i am back on the trunk and there is no problem. sorry for all the confusion. -- cu pgpjvncovS7ud.pgp Description: PGP signature
x11dvr: return support for 24bit - but handle them like 32bit
hiho
the game ``NASCAR Racing Season 2003`` from Papyrus actually asks when
using the OpenGL driver in the game for 24 bit modes. Otherwise it
complains, that it can not find any display modes (it works with 16bit -
but the game seem only to accept the modes the current desktop runs in).
so what i did is adding the 24bit depth back into the list (last one)
and replaced some magic ints and some unused code on my way through
this.
still this game now does no longer work with wine (it worked a year
ago). no it stumbles when calling wglShareLists.
License: LGPL
ChangeLog:
- also list 24bit modes; but still handle them later as 32bit
--
cu
diff --git a/dlls/winex11.drv/settings.c b/dlls/winex11.drv/settings.c
index 5de07eb..f6e2807 100644
--- a/dlls/winex11.drv/settings.c
+++ b/dlls/winex11.drv/settings.c
@@ -39,7 +39,8 @@ static LPDDHALMODEINFO dd_modes = NULL;
static unsigned int dd_mode_count = 0;
static unsigned int dd_max_modes = 0;
static int dd_mode_default = 0;
-static const unsigned int depths[] = {8, 16, 32};
+static const unsigned int depths[] = {8, 16, 32, 24};
+static const unsigned int nr_depths = sizeof(depths) / sizeof(unsigned int);
/* pointers to functions that actually do the hard stuff */
static int (*pGetCurrentMode)(void);
@@ -62,7 +63,7 @@ LPDDHALMODEINFO X11DRV_Settings_SetHandl
TRACE(Resolution settings now handled by: %s\n, name);
if (reserve_depths)
/* leave room for other depths */
-dd_max_modes = (3+1)*(nmodes);
+dd_max_modes = nr_depths*nmodes;
else
dd_max_modes = nmodes;
@@ -111,7 +112,7 @@ void X11DRV_Settings_AddDepthModes(void)
int existing_modes = dd_mode_count;
DWORD dwBpp = screen_depth;
if (dwBpp == 24) dwBpp = 32;
-for (j=0; j3; j++)
+for (j=0; jnr_depths; j++)
{
if (depths[j] != dwBpp)
{
@@ -164,8 +165,6 @@ void X11DRV_Settings_Init(void)
*/
BOOL X11DRV_EnumDisplaySettingsEx( LPCWSTR name, DWORD n, LPDEVMODEW devmode,
DWORD flags)
{
-DWORD dwBpp = screen_depth;
-if (dwBpp == 24) dwBpp = 32;
devmode-dmDisplayFlags = 0;
devmode-dmDisplayFrequency = 0;
devmode-dmSize = sizeof(DEVMODEW);
pgplD2NXsutY4.pgp
Description: PGP signature
Re: WGL patches cause problems with RBR and LFS
On Wed, Sep 06, 2006 at 07:42:03PM +0200, Roderick Colenbrander wrote: Hi Roderick, The WGL patches which are in mike's tree are different ones. They move the WGL-specific opengl code from opengl32.dll to x11drv. The code itself isn't changed. So first try if the problems appeared on 0.9.20 and then we will see further. sorry for making this not clear in the first mail. i was bisecting from wine-0.9.20 to current. in 0.9.20 everything is fine. i actually meant the patches that moved the WGL stuff. -- cu pgpfDH04jgwbV.pgp Description: PGP signature
Re: LOSTWAGES: who's who
On Wed, Sep 06, 2006 at 10:21:42AM -0400, Tom Wickline wrote: -h3Jason Edmeades/h3blockquote -h3Jukka Heinonen/h3blockquote -h3Ove K#229;ven/h3blockquote -h3Shachar Shemesh/h3blockquote -h3Oliver Stieber/h3blockquote -h3Greg Turner/h3blockquote would it not be more kind to move the veterans into their own section instead of removing them at all? at least they managed to get in this list by their previous contributions to the project. please ignore this, if i intercepted with this mail further patches in that direction ;) -- cu pgpAOkMyck5zW.pgp Description: PGP signature
WGL patches cause problems with RBR and LFS
hiho i am currently running Mike's (?) mmbranch git version of wine and beside some games are working without problems (or at least no new problems) Richard Burns Rally and Live For Speed quit instantly with the more or less same message, that there are no valid display modes available. using git-bisect i can at least tell, that before Rodericks WGL patches everything was ok - then came at least one patch that broke compilation for me and at some pointer later it does compile but no longer work (so its hard to pinpoint the exact patch, that cause the regression). would someone - preferably Roderick - point me in a direction, what traces are needed to look into this? beside that for both games there are demos out there. i am running the games in desktop mode (non desktop does helps nothing); LFS with UseGLSL and RBR not. -- cu pgpaOLui7gjCd.pgp Description: PGP signature
Re: DIB Engine
On Thu, Aug 24, 2006 at 03:57:43AM -0700, [EMAIL PROTECTED] wrote: I've recently tried to play Heroes of Might and Magic IV under Wine, which has very poor performance and this message it printed out many, many times after the game is started: fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy assuming that this is the real problem for the poor performance you might squeeze quite some speed out if you get rid of the FIXMEs by redirecting the output to /dev/null. if there are really _lots_ of errors like this it takes quite some time to render them depending on your terminal. at least this reminds me, that i wanted to test homm3 with wine as the native version no longer works with current linux/glibc/64-bit/godknowswhy. -- cu pgpmYXn1BDSWr.pgp Description: PGP signature
Re: LOSTWAGES: Replace references to CVS with Git
On Mon, Aug 21, 2006 at 11:33:28AM +0200, Michael Stefaniuc wrote: My changes to the website reflect that support for CVS may not last forever... Are there any plans to get rid of CVS? I would guess keeping the CVS tree sync from the git tree is low maintanance so it can be kept around forewever. and please dont follow any plans like this until another solution is there to fetch the tree from non-linux-boxen. i tried once to build git (1.2) here on my obsd box at work, where i fetch current wine every day, and it failed. think about the children (that use no linux)! ;) -- cu pgpcqaytRwsj7.pgp Description: PGP signature
re-reading from registry
Hi, I'm still working on the clamav integration in wine. One question that came up recently is how to handle configuration changes. I'd like to allow to configure the virusscanner 'online' without restarting the wineserver or applications currently running. As the configuration is stored in the registry I could read all affected values every time I need them (that means several RegQueryValueExA() calls for every virusscan). But I found that this costs quite some time and even seems to cause IE5 to crash (does anyone know or want to know the reason?). When I save a local copy of my registry values and only update them every x seconds everything is fine. But is that a recommended way or is there a better solution to get notified if a registry key has been changed? If found RegNotifyChangeKeyValue() but I'm not sure if it is the right approach ... Cheers Chris -- Kontakt-Details: http://www.christoph-probst.com/kontakt/ PGP-FP: B171 7EA4 988C DD90 1601 D21C 5279 2FAF 9978 AF86 pgpyTR88KqfYR.pgp Description: PGP signature
Re: [2/2] WINED3D: Fix D3DCOLOR swizzling in shaders.
On Sat, Aug 05, 2006 at 06:15:42PM +0200, H. Verbeet wrote: This patch fixes those issues by looking at the data types in the vertex declaration the shader will be used with. To be able to do that, we have to wait with compiling the shader until the shader is first used and we have a vertex declaration. I am not sure, if exactly *this* patch fixes the problem - but i assume so: the colors of the cars and lights in Live For Speed are not fixed also. thanks for that! -- cu pgpVYvAYhYTb8.pgp Description: PGP signature
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: race condition in dinput's multiple joystick code and IL2
On Wed, Jul 19, 2006 at 02:03:06PM +0100, Robert Shearman wrote: Hi Robert, thanks for your comments. so what i have tried so far: - put find_joydevs into a critical section This should work. Why don't you share the patch you used to do this? because i have dumped it, after there where no success ;) it was basically like this: put a crititcal section and the _debug stuff (stolen from another dll) in the file and call Enter/Leave on the start/end of the find_joydevs method. Note that none of the data in JoystickImpl is protected by that critical section and maybe it should be. in general i dont really like the idea of calling find_joydevs every time it *might* be needed and i would prefer to go a way like registering also hooks in the dinput-implementations to allow the devices to find themself on dinput.dll's startup (add a init-method where the enum/create hooks are). this is what i would have tried next (and i guess still will). there i can put a critical secion also. -- cu pgp0zCUC7xqVl.pgp Description: PGP signature
Re: [Wine] Problems with newest Wine versions (.16, .17)
On Wed, Jul 19, 2006 at 07:48:17AM -0700, Alex Ferguson wrote:
Here's Planescape's output:
fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x7fd61210) : stub,
emulating 64MB for now, returning 64MB
fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel
(0x7fd4d940)-(0x10024,0011)
fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to
16
err:d3d_surface:IWineGDISurfaceImpl_PrivateSetup (0x6da5d6d0)
IWineD3DSurface::GetDC failed with hr 80070006
err:ddraw:IDirectDrawImpl_CreateNewSurface IWineD3DDevice::CreateSurface
failed. hr = 80070006
err:ddraw:IDirectDrawImpl_CreateSurface IDirectDrawImpl_CreateNewSurface
failed with 80070006
for the files - this is what i get (like all other stuff i run this game in
wine's desktop-mode; might this explain another outcome?)
trace:ddraw:IDirectDrawImpl_CreateNewSurface (0x7fd358c8) Created
IDirectDrawSurface implementation structure at 0x6d326e90
trace:ddraw:IDirectDrawImpl_CreateNewSurface Using Surface interface 0x6d326e90
as parent
trace:d3d:IWineD3DDeviceImpl_CreateSurface (0x7fd46638) Create surface
trace:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x7fd46638) : emulating
256MB for now, returning 222MB
trace:d3d:IWineD3DDeviceImpl_AddResource (0x7fd46638) : resource 0x6d326f70
trace:d3d:IWineD3DDeviceImpl_AddResource Added resource 0x6d326f70 with element
0x6d326cf8 pointing to 0x6d326708
trace:d3d:IWineD3DDeviceImpl_CreateSurface (0x7fd46638) : Created resource
0x6d326f70
trace:d3d:IWineD3DDeviceImpl_CreateSurface Pool 0 0 1 2Creating a surface with
a POOL of DEFAULT with Lockable true, that doesn't specify DYNAMIC usage.
trace:d3d:IWineD3DDeviceImpl_QueryInterface
(0x7fd46638)-({3c2aebf6-6f30-11d9-c687-00046142c14f},0x7fbca964)
trace:d3d:IWineD3DDeviceImpl_CreateSurface (0x7fd46638) : w(64) h(64)
fmt(23,WINED3DFMT_R5G6B5) lockable(0) [EMAIL PROTECTED], surfmem@(nil), 8192
bytes
err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this.
this is the end of a +ddraw,+d3d trace i wanted to use in a bugzilla entry. if
somebody is interested, please let me know so i can mail it off-list.
--
cu
pgpCW4HZnz9Rr.pgp
Description: PGP signature
Re: IID_IUnknown not defined?
On Mon, Jul 17, 2006 at 03:15:35PM +0200, Alexandre Julliard wrote: -L adds library paths to the beginning of the library search path. You've probably got a libuuid in one of those directories, which now takes precedence over the one in wine. This should be fixed now. it is! thank you. -- cu pgpSVqeNysqxR.pgp Description: PGP signature
Re: [Wine] Re: latest git fails to compile, amstream.c:77: undefined ref to `IID_IUnknown'
On Tue, Jul 18, 2006 at 09:35:05AM +0200, Christoph Frick wrote: Well, I was able to successfully build git revision 6a97f2202e91fed286ff6ca254926e5f57ca17c1 so this topic is closed. this is a problem, that seemed to exist for a few days on gcc32 compiles. Alexandre fixed this yesterday. please get the current version. ah i love this mornings, where not a single drop of tea or coffee hit me yet - so excuse my inabillity to read properly ;) -- cu pgpzpCxSaR8j9.pgp Description: PGP signature
Re: IID_IUnknown not defined?
On Mon, Jul 17, 2006 at 12:06:11AM +0200, Willie Sippel wrote: They're defined in libuuid. Try make depend make. You should post the exact error that you're seeing, not just your interpretation of it. i do seperate build and i just removed my ./wine_build dir and started from scratch; also helped not (error see below - undef ref. ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./amstream.spec amstream.o main.o mediastream.o regsvr.o version.res -Wl,--rpath, \$ORIGIN/`../../tools/relpath /usr/lib32/wine /usr/lib32` -o amstream.dll.so -lole32 -luser32 -ladvapi32 -lkernel32 -lstrmiids -luuid ../../libs/port/libwine_port.a -m32 -L/emul/linux/x86/usr/lib -L/usr/lib32 -L/emul/linux/x86/lib amstream.o: In function `IAMMultiMediaStreamImpl_QueryInterface': /store/Download/wine/wine/dlls/amstream/amstream.c:77: undefined reference to `IID_IUnknown' main.o: In function `DllGetClassObject': /store/Download/wine/wine/dlls/amstream/main.c:176: undefined reference to `IID_IClassFactory' /store/Download/wine/wine/dlls/amstream/main.c:176: undefined reference to `IID_IUnknown' main.o: In function `AMCF_QueryInterface': /store/Download/wine/wine/dlls/amstream/main.c:87: undefined reference to `IID_IUnknown' /store/Download/wine/wine/dlls/amstream/main.c:87: undefined reference to `IID_IClassFactory' mediastream.o: In function `IMediaStreamImpl_QueryInterface': /store/Download/wine/wine/dlls/amstream/mediastream.c:74: undefined reference to `IID_IUnknown' collect2: ld returned 1 exit status winegcc: gcc32 failed. make[2]: *** [amstream.dll.so] Error 2 make[2]: Leaving directory `/store/Download/wine/wine/dlls/amstream' make[1]: *** [amstream] Error 2 make[1]: Leaving directory `/store/Download/wine/wine/dlls' make: *** [dlls] Error 2 i build the same way - i assume gentoo? on my end it is also gcc32 with some handcrafted -L/emul/... statements on a otherwise 64bit linux. the gcc in question btw 3.4.6. -- cu pgphBIcMHbOzR.pgp Description: PGP signature
Re: 0.9.17 and other issues
On Tue, Jul 11, 2006 at 12:50:40PM +, Roland Kaeser wrote: the goal is to implement the win32 APIs on top of unix. this does neither exclude the gamers nor the appers. But remember the mission: Bring the people to Linux! It's just a matter of priorization. What brings more people to linux? You have right: The business apps. So what's more important? i have never joined that mission. people are free to do/use whatever they want. also i have my _strongest_ doubts about the apps-vs-games theory, but - like you? - i have no numbers to prove it; so i just shut up. -- cu pgpXXMIEpvSb5.pgp Description: PGP signature
assumed graphic card memory
hiho within the dlls/wined3d/device.c there is a define for the fake size of the graphic-card memory. with the given 64MB Richard Burns Rally[1] crashes on startup - once i put my real 256MB there it start and drawprim is the only remaining problem, the game has. IIRC there where a patch, that allowed editing the amount of gfx-ram to be configured via winecfg? until an easy way can be found, would it be better to apply this patch and state this fact in the error-messages wine produces? [1] http://www.3dgamers.com/games/rburnsrally/downloads/ -- cu pgpthaD5ikh7K.pgp Description: PGP signature
Re: [dinput] infos
On Thu, Jul 06, 2006 at 01:28:21PM +0200, Christoph Frick wrote: - i have to find the range an app expects the min/max are - either we have to map the hardware allready to something sane - or we have to fix map_axis; currently my flight stick reports 0-2**16 - with the center at 2**15 this overflows map_axis (2**31+X in int is 0) - this would be a problem with apps, that rely/work with GetProperty/range riddle solved - map_axis needs fixing; the ranges are the full LONG range. -- cu pgpmM6SHCOr70.pgp Description: PGP signature
Re: [dinput-0/6] multiple devices - Resend #2
On Tue, Jul 04, 2006 at 08:03:06PM -0400, Robert Reif wrote: this is again my patch for handling more than one /dev/input/event* joystick within dinput. there are several other patches now to follow, that expect this patch to be applied. so i label this one 0 of 6. against the previous version it only has some detect first joystick code moved around. Why are you changing the code outside of joystick_linuxinput? as explained in my first submit, the code in our dinput's main already has some way to work with multiple devices of one kind i changed the return of the enum-device methods to an int so we have 0=nothing, 1=here is one and -1=nothing here and dont bother any further. i can see no harm in this changes and all the games i tested could not either. -- cu pgptcmGabkh8W.pgp Description: PGP signature
Re: DDRAW: Releasing attached surfaces
On Thu, Jun 29, 2006 at 04:43:04PM +0200, Krzysztof Benkowski wrote:
--- surface.c 26 Jun 2006 12:15:20 - 1.6
+++ surface.c 29 Jun 2006 14:09:59 -
@@ -377,7 +377,7 @@ IDirectDrawSurfaceImpl_Release(IDirectDr
while( (surf = This-next_complex) )
{
This-next_complex = surf-next_complex; /* Unchain it
from the complex listing */
-IDirectDrawSurfaceImpl_Destroy(surf); /* Destroy it */
+IDirectDrawSurfaceImpl_Release(surf); /* Release it */
}
as this seems already solved just for the files. this fix let Planescape
Torment crash (before it just ended silently by releasing its primary
state block) - it worked before the ddraw patches white fine. i will
soon file a bugreport and provide a link to the demo.
--
cu
pgpx02dzGO1Ul.pgp
Description: PGP signature
Re: Wine 0.9.16 and ddraw issues
On Fri, Jun 30, 2006 at 05:11:24PM +0200, Alexander Nicolaysen Sørnes wrote: ... fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock ... fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock this are also the last words of Planescape Torment when starting up (black screen, then end right before the menu would appear) -- cu pgpvuZBo4ZEz5.pgp Description: PGP signature
Re: How do I get the unix filename for a wine handle?
Hi. Eric Pouech wrote: just for sake of completeness: how about enhancing ClamAV so that it takes a fd (instead of a filename) as its input ? It looks like as if fd are already supported somehow. Need to have a closer look at that ... But I found an even better alternative: ClamAV supports a STREAM command which allows a client to send a string to the scanner. This allows to scan a string even before it is written to disk. Thanks for your answer! Chris -- Kontakt-Details: http://www.christoph-probst.com/kontakt/ PGP-FP: B171 7EA4 988C DD90 1601 D21C 5279 2FAF 9978 AF86 pgpY4BQ08QsuX.pgp Description: PGP signature
Re: How do I get the unix filename for a wine handle?
Hi. Alexandre Julliard wrote: You can't do that in general. In Unix a file can have multiple names, or even none at all, there's simply no way to get a filename from a handle. On Linux you can use /proc/self/fd but that's not very portable. So what do you think about the solution that the wineserver stores the filename in the file object when the object is created? Just like wine_server_handle_to_fd() there would be a wine_server_handle_to_filename() that returns the filename. Any objections to this? Chris -- Kontakt-Details: http://www.christoph-probst.com/kontakt/ PGP-FP: B171 7EA4 988C DD90 1601 D21C 5279 2FAF 9978 AF86 pgpajKVTAzkPZ.pgp Description: PGP signature
Re: ddraw assert prevents Ankh from starting
On Fri, Jun 23, 2006 at 11:49:24AM +0200, Stefan Dösinger wrote: Hi Stefan, I tested the demo, the loading screen appears without the assert. I will send a more proper implementation of IDirectDrawSurface::SetSurfaceDesc when I have time(university tests :-( ). no hurry! i try out all the stuff that lies on my disk with cvs every now and then and this came up. The loading screen appears, but it seems to get stuck quite soon during loading. It seems to wait for something, the cpu is idle and the screen not redrawn. it takes _ages_ in some c++ code in one of the dlls it ships with. you just have to be patient. it takes about 3-5 minutes - then you are in the main menu (where the mouse is magically drawn to the center of the screen like a moth and yesterdays dinput mouse fix, does not help here). one good thing about it, is the use of ogre, so i had a peak in the dinput code of current ogre version, if i see something strange. but with my limited knowledge of if the winapi there was at least nothing obvious and there is always the possibility, that the old version did something radical else or that they have patched around in the ogre code. This game seems to use the open source ogle library for rendering, and it also ships a Direct3D9 and OpenGL renderer. Maybe there's a way to make it use the ogl renderer, but I haven't found a way to do so. forget about that - it does not run at all using ogl. i had the same idea and tried it. its also a pity, that they use ogre but do not provide a osx/linux version of the game :/ -- cu pgpwO4QP0PEnn.pgp Description: PGP signature
How do I get the unix filename for a wine handle?
Hi, I'm one of the Google Summer of Code students and I'm working on the ClamAV integration in wine. Today I was discussing an issue with my mentor and he suggested to post it here. 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. Within this function the file is accessed using its unix_handle. The problem is that I need to know the unix filename for clamAV to access the file, but I see no proper way or function to get it as long as I just know the unix_handle or fd. Possible solutions so far: 1. searching /proc/self/fd/%d for the name. This would be an easy but very ugly solution. 2. maintaining a table mapping unix_handles to filenames from within NtCreateFile(). Hence I don't have the feeling that this is a good solution. 3. storing the unix filename in the wineserver handle object when it's created. This is probably the right place to keep this information but it would require some changes to the wineserver. If I understand it right it is already planned to implement something like this (lookup_name in server/object.c) But maybe I just missed an even better approach. What would you recommend to do? Any comment is appreciated. Cheers, Chris -- Kontakt-Details: http://www.christoph-probst.com/kontakt/ PGP-FP: B171 7EA4 988C DD90 1601 D21C 5279 2FAF 9978 AF86 pgpDJM5wzNEV5.pgp Description: PGP signature
ddraw assert prevents Ankh from starting
hiho on the end of this mail is a patch, that removes an assert(0) from the surface code in ddraw. but removing it let Ankh[1][2] start (it started before, but there where no loading screen visible). yet there are other problems with this game - but it now actually works better than before. so let the ddraw developers decide what to do there - this mail is just a reminder, that there is a poor little homeless assert, that needs your attention ;) [1] german demo: http://www.gamershell.com/download_12062.shtml [2] engl. demo: http://www.gamershell.com/download_12202.shtml -- cu Index: dlls/ddraw/surface.c === RCS file: /home/wine/wine/dlls/ddraw/surface.c,v retrieving revision 1.4 diff -u -r1.4 surface.c --- dlls/ddraw/surface.c19 Jun 2006 10:44:41 - 1.4 +++ dlls/ddraw/surface.c20 Jun 2006 07:10:07 - @@ -1865,7 +1865,6 @@ WINED3DFORMAT newFormat = WINED3DFMT_UNKNOWN; HRESULT hr; FIXME((%p)-(%p,%lx)\n, This, DDSD, Flags); -assert(0); if(!DDSD) return DDERR_INVALIDPARAMS; pgpJfvH6fGMTv.pgp Description: PGP signature
[dinput] multiple /dev/input joysticks (for test/review)
hiho,
the attached patch detects _all_ joysticks of /dev/input/event%d; please
have a test before i refine the patch for submission. i tried it with
Il2 Sturmovik and with Live For Speed - both games worked. as neither my
cougar nor my brd wheel have force feedback i was not able to test, if
everything still works.
details:
- use a seperate struct for holding infos about the /dev/input/event
devices
- use the general infos about the devices instead of
acquiring/unacquiring before/after infos about the device are needed
- changed the dinput_main to use three states to return on
create_device: -1 == dont try further, 0 == there is no such device,
1 == there we go
next ideas/patches:
- use a linked list for storing only the JoyDev's that there are
- the guid is stored in the JoyImpl and the JoyDev
- the logic in setting the guids is as first joystick == GUID_Joystick
then use the wine default; this currently leads into the same GUID for
instance and product; i saw in joystick_linux.c how this is solved
there
- as dmesg shows a proper name for the device we might somehow retrieve
it with an ioctl-call; currently the /dev/... name is used, which is
good for developers but not for users
- per-device-config via registry (e.g. combine axes)
this patch actually is longer than the things it really does -
introducing a sub-struct for holding common data adds lots of
``-joydev'' so i decided instead of splitting this patch into several
fragments send an unfinished version and then finish the job with the
following small patches.
please note: the patch is against ~wine/dll/dinput (i use cvs for the
wine original and git where i need it for patching)
--
cu
diff --git a/device.c b/device.c
diff --git a/dinput_main.c b/dinput_main.c
index 9f93a52..d928d96 100644
--- a/dinput_main.c
+++ b/dinput_main.c
@@ -220,10 +220,11 @@ static HRESULT WINAPI IDirectInputAImpl_
for (i = 0; i NB_DINPUT_DEVICES; i++) {
if (!dinput_devices[i]-enum_deviceA) continue;
-for (j = 0, r = -1; r != 0; j++) {
+TRACE( - checking device %d ('%s')\n, i, dinput_devices[i]-name);
+for (j = 0, r = 0; r != -1; j++) {
devInstance.dwSize = sizeof(devInstance);
- TRACE( - checking device %d ('%s')\n, i,
dinput_devices[i]-name);
- if ((r = dinput_devices[i]-enum_deviceA(dwDevType, dwFlags,
devInstance, This-dwVersion, j))) {
+ if (1 == (r = dinput_devices[i]-enum_deviceA(dwDevType, dwFlags,
devInstance, This-dwVersion, j))) {
+TRACE( - found id %d\n, j);
if (lpCallback(devInstance,pvRef) == DIENUM_STOP)
return 0;
}
@@ -250,10 +251,11 @@ static HRESULT WINAPI IDirectInputWImpl_
for (i = 0; i NB_DINPUT_DEVICES; i++) {
if (!dinput_devices[i]-enum_deviceW) continue;
-for (j = 0, r = -1; r != 0; j++) {
+TRACE( - checking device %d ('%s')\n, i, dinput_devices[i]-name);
+for (j = 0, r = 0; r != -1; j++) {
devInstance.dwSize = sizeof(devInstance);
- TRACE( - checking device %d ('%s')\n, i,
dinput_devices[i]-name);
- if ((r = dinput_devices[i]-enum_deviceW(dwDevType, dwFlags,
devInstance, This-dwVersion, j))) {
+ if (1 == (r = dinput_devices[i]-enum_deviceW(dwDevType, dwFlags,
devInstance, This-dwVersion, j))) {
+TRACE( - found id %d\n, j);
if (lpCallback(devInstance,pvRef) == DIENUM_STOP)
return 0;
}
diff --git a/joystick_linux.c b/joystick_linux.c
index d56271d..abedc5c 100644
--- a/joystick_linux.c
+++ b/joystick_linux.c
@@ -162,11 +162,15 @@ static int joydev_get_device(char *dev,
return ret;
}
-static BOOL joydev_enum_deviceA(DWORD dwDevType, DWORD dwFlags,
LPDIDEVICEINSTANCEA lpddi, DWORD version, int id)
+static int joydev_enum_deviceA(DWORD dwDevType, DWORD dwFlags,
LPDIDEVICEINSTANCEA lpddi, DWORD version, int id)
{
int fd = -1;
char dev[32];
+if (id0) {
+return -1;
+}
+
if (dwFlags DIEDFL_FORCEFEEDBACK) {
WARN(force feedback not supported\n);
return FALSE;
@@ -209,13 +213,17 @@ static BOOL joydev_enum_deviceA(DWORD dw
return FALSE;
}
-static BOOL joydev_enum_deviceW(DWORD dwDevType, DWORD dwFlags,
LPDIDEVICEINSTANCEW lpddi, DWORD version, int id)
+static int joydev_enum_deviceW(DWORD dwDevType, DWORD dwFlags,
LPDIDEVICEINSTANCEW lpddi, DWORD version, int id)
{
int fd = -1;
char name[MAX_PATH];
char dev[32];
char friendly[32];
+if (id0) {
+return -1;
+}
+
if (dwFlags DIEDFL_FORCEFEEDBACK) {
WARN(force feedback not supported\n);
return FALSE;
diff --git a/joystick_linuxinput.c b/joystick_linuxinput.c
index 30f81f1..94a0383 100644
--- a/joystick_linuxinput.c
+++ b/joystick_linuxinput.c
@@ -85,12 +85,28 @@ HRESULT linuxinput_get_info_W(int fd, RE
typedef struct JoystickImpl JoystickImpl;
static
Re: appdb security
On Thu, Jun 08, 2006 at 06:44:15PM -0500, EA Durbin wrote:
function makeSafe( $var )
{
$var = trim( addslashes( $var ) );
return $var;
}
$clean['var1'] = makeSafe( $_REQUEST['var1'] );
$clean['var2'] = makeSafe( $_REQUEST['var2'] );
sorry for only throwing things at you guys and not providing any code -
but i am currently packed with work :/
why dont create a object, that wrapps the request and makes it safe.
then fixing the app is not more like sed action and you can handle stuff
in future as you like:
$_REQUEST[(['][^']+['])] - Request::get(\1)
--
cu
pgpIGdBEBgOnK.pgp
Description: PGP signature
Re: notepad patches (search/replace, etc)
On Fri, Jun 09, 2006 at 10:08:11AM +0200, Andreas Mohr wrote: Or, IOW, do we have any guidelines about Anoni Moose submissions to our project? Are they ok, not ok, ok? Loves me, loves me not, ... what is the difference between anonymous submissions, that we can spot and which we don't? maybe you are a fake ;) -- cu pgpPl77O0dqS0.pgp Description: PGP signature
Re: appdb security
On Thu, Jun 08, 2006 at 11:25:08AM -0400, Chris Morgan wrote: $sQuery = Select versionId from appVersion where appId='$_REQUEST['appId'].';; Who's '' around $_REQUEST should prevent the string from being interpreted as anything but a single value passed as the value of appId. with appId=' or 1=1;'? -- cu pgpseZLsLOL39.pgp Description: PGP signature
Re: wine problems on a 64bit system
On Thu, Jun 01, 2006 at 02:59:30PM +0200, Pavel Troller wrote: [EMAIL PROTECTED]:/proc/28433# cat maps |grep 6d4 6d42-6d421000 r--p 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll i run this game (il2+fb+ace+pf) on a opteron system quite well. i found the folling things helpfull - it might shed some more light on the whole thing: a) i have to run this game using win2k (or up - guess nt4 might also work) - it wont work using win98 b) when i configure EnableHardwareShaders=1 (?) in the conf.ini then the game crashes sooner or later (depending on the Water=XXX setting (3 is sooner, 2 is later)) with OutOfMemory exceptions in java. the game takes up to 3 gb ram virtual and a few 100mb resistant acording to top. the box has 2gb real but i am not sure if i put 1gb or 2gb swap on - so it might actually really use all my ram. i found it also quite amusing, that 3gb where used - where i guessed windows can only do 2gb per process without further handling (urban legend?). once i disable the hardware shaders the water looks dull within the game but serves my hours of fun without a problem -- cu pgp77csRomtUo.pgp Description: PGP signature
Re: Direct3D, the kernel and ReactOS
On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote: My long term suggestion is to move the Direct3D-OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer). first of all excuse my ignorance of the d3d interface and so on - but this sounds to me like wine should not deal with the userland dlls at all then? once all the hardware is handled in the kernel parts what is the gain in having our own implementations? installing dx with the games should be sufficient then? on the other hand, if the interface of the kernel parts is hardly documented why not stick with the current implementation that does a good job with what it does and implement/stub the kernel things once an app crashes? -- cu pgpC83ERNLezC.pgp Description: PGP signature
Re: Direct3D, the kernel and ReactOS
On Thu, Mar 30, 2006 at 08:29:03AM -0500, Kuba Ober wrote: Technically sufficient, maybe, but it might be actually illegal to install Direct X on anything non-windows. Might be or is? Or will be like dcom? At least with dcom ms made the point clear. they just dont provide it beside the os. but i can not remember a single game in my collection, that does came with the dx-package needed to run it (i hardly remember anything that came with dcom98.exe). so does anybody knows the actual license or is there anything known what ms has in mind in the near future? I bet there are non-gaming 3D applications that use it. CAD systems come to mind. I think that for example Solid Edge uses Direct X (no, didn't try to get it running under wine yet). yeah i am sure there are lots of non-game applications that utilize directx - dsound for sound apps, d3d for cad, office, 3d, ... and so on. all in all i know close to nothing what goes on the various dlls - but from a point of view like this it seems to be a lot of work to redo the work of others if there is no real need for it, like e.g. accessing hardware or operating system stuff. license issues aside i would only a consider a massive performance gain something that is worth it (and there still remains the question, why is that original dll so much slower with the underlying framework then). and of course its a lot easier to implement something that is *cough* well documented than something that is totally unknown to mankind. -- cu pgpbZAgPXBLOh.pgp Description: PGP signature
Re: How hard would it be to support Java?
Dan Kegel schrieb: Quite a few apps use embedded JVM's. Case in point: SPSS, one of the apps requested by Munich. WTF? There is a JVM for Linux available. To my mind contact the manufacture of your software and explain to them that Java is platform independent ... So I played around a bit with Sun's latest 1.5 JRE. It can run trivial apps, so I closed http://bugs.winehq.org/show_bug.cgi?id=2953 (ok, maybe that was premature, since the bug was for Sun's 1.4 JRE). But it can't run applets; first, it runs into a nasty glx error, http://bugs.winehq.org/show_bug.cgi?id=4143 Once you patch your way past that, it complains about not finding a native method, see http://bugs.winehq.org/show_bug.cgi?id=4873 And it doesn't show up in Firefox's about:plugins by default, see http://bugs.winehq.org/show_bug.cgi?id=4860 Can anyone shed some light on these, especially bug 4143? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
WINE's way to find out about MS headers?
hiho after reading the SetProperty documentation on MSDN about the direct input interface, i found out about four defines that are not yet included in the dinput.h of WINE. #define DIPROP_APPDATA MAKEDIPROP(?) #define DIPROP_CPOINTS MAKEDIPROP(?) #define DIPROP_INSTANCENAME MAKEDIPROP(?) #define DIPROP_PRODUCTNAME MAKEDIPROP(?) i guess the ids they represend are not documented anywhere but the dinput.h from Microsoft. what is the best practise for cases like this, to add them to wine's headers? -- cu pgpdd064LxFws.pgp Description: PGP signature
Re: Can't run DirectX games on x86_64 biarch Linux
On Wed, Mar 08, 2006 at 12:09:28AM +0100, Christian Schneider wrote: As you can see, the most common errors are err:seh:setup_exception and err:ntdll:RtlpWaitForCriticalSection. I've also done some more tests with other games like Revolt, Anno 1503, Half-Life 2, and the errors all look alike. anno 1503 never ever worked for me (there where some discussion about apps like this that follow a pattern with ddraw and threads, that wine might be able to handle (ever)). -- cu pgpngmfhf07cw.pgp Description: PGP signature
