On 04/10/06, Mirek [EMAIL PROTECTED] wrote:
Unfortunately there are many issues with latest nVidia drivers and
Windows apps in wine. In Half-Life 2 EO (characters brokes the game),
3DMark 2003 (first test with planes is very strange), GTA SA (almost
everywhere in game), but other apps such as
And what about this patch? It is working with new and old nVidia
drivers, but i dont know if some cards have gl_max realy 256 and below.
Mirek
H. Verbeet napsal(a):
On 04/10/06, Mirek [EMAIL PROTECTED] wrote:
Unfortunately there are many issues with latest nVidia drivers and
Windows apps in
Sorry, there should be only greater then, not equal. So this i the right
version :)
Mirek
Mirek napsal(a):
And what about this patch? It is working with new and old nVidia
drivers, but i dont know if some cards have gl_max realy 256 and below.
Mirek
H. Verbeet napsal(a):
On 04/10/06,
On 04/10/06, Mirek [EMAIL PROTECTED] wrote:
And what about this patch? It is working with new and old nVidia
drivers, but i dont know if some cards have gl_max realy 256 and below.
There might be. GF4 might be a card we want to check. I do think it's
a bit dodgy though... you'll probably want
Pavel Roskin wrote:
GLUT32FILES = glut32
OPENGLFILES = opengl32 wined3d
XFILES = winex11.drv
-EXTRADIRS = @GLU32FILES@ @GLUT32FILES@ @OPENGLFILES@ @XFILES@
+WIN32FILES = oleaut32
+EXTRADIRS = @GLU32FILES@ @GLUT32FILES@ @OPENGLFILES@ @XFILES@
Why?
--
Rob Shearman
OK, and now what about this patch? With this patch evrything is working
correctly if i am using nVidia BETA 9625 drivers (HL2 EO, GTA SA, 3DMark
2003), corectly means same like with old driver and wine 0.9.22.
Mirek
H. Verbeet napsal(a):
On 04/10/06, Mirek [EMAIL PROTECTED] wrote:
And what
On 04/10/06, Mirek [EMAIL PROTECTED] wrote:
--- directx.c.old 2006-10-03 22:36:25.0 +0200
+++ directx.c 2006-10-04 14:24:18.0 +0200
@@ -557,6 +558,7 @@
gl_info-supported[ARB_MULTISAMPLE] = TRUE;
} else if (strcmp(ThisExtn,
Here is the log, without this patch i have with new nVidia driver only 4
GL_MAX_TEXTURE_UNITS_ARB and some apps have big regression. I realy dont
know why, i am not expert in wine or directx, but now it is working.
trace:d3d_caps:IWineD3DImpl_FillGLCaps GL_Extensions reported:
On Wed, Oct 04, 2006 at 11:26:49AM +0900, Byeong-Sik Jeon wrote:
Changelog:
Cleanup the updata_font_info().
+static void add_nls_font_to_registry(
+HKEY hkey,
+const char *value_name,
+const char *value_data,
+BOOL is_force)
+{
+
On 10/3/06, Michael [Plouj] Ploujnikov [EMAIL PROTECTED] wrote:
I'm by no means an expert on copyright law or copy protection, but I think that using any method other than writing directly to the MBR with those copy protection measures would be illegal because writing to a file (registry,
On 10/3/06, Martin Owens [EMAIL PROTECTED] wrote:
On 10/3/06, Michael [Plouj] Ploujnikov [EMAIL PROTECTED] wrote: I'm by no means an expert on copyright law or copy protection, but I think that using any method other than writing directly to the MBR with those copy
protection measures would be
On Wed, 2006-10-04 at 12:23 +0100, Robert Shearman wrote:
Pavel Roskin wrote:
GLUT32FILES = glut32
OPENGLFILES = opengl32 wined3d
XFILES = winex11.drv
-EXTRADIRS = @GLU32FILES@ @GLUT32FILES@ @OPENGLFILES@ @XFILES@
+WIN32FILES = oleaut32
+EXTRADIRS = @GLU32FILES@ @GLUT32FILES@
On 04/10/06, Mirek [EMAIL PROTECTED] wrote:
Here is the log, without this patch i have with new nVidia driver only 4
GL_MAX_TEXTURE_UNITS_ARB and some apps have big regression. I realy dont
know why, i am not expert in wine or directx, but now it is working.
The old drivers only had 4
Le mardi 03 octobre 2006 à 15:51 -0500, Tom Spear a écrit :
[...]
I'm by no means an expert on copyright law or copy protection, but I
think that using any method other than writing directly to the MBR
with those copy protection measures would be illegal because writing
to a file
Technically yes, but the difference is that VMware actually writes
_everything_ into that one file vs wine proposing to write just what is
written to the boot sector into a file..
The reason it is different, is because it is much more difficult (if not
impossible) to tell what is boot sector and
So this is very strange, because under Windows XP i have definitely 8.
Ok, from what app do you want this log?
Mirek
H. Verbeet napsal(a):
On 04/10/06, Mirek [EMAIL PROTECTED] wrote:
Here is the log, without this patch i have with new nVidia driver only 4
GL_MAX_TEXTURE_UNITS_ARB and some
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
On 10/4/06, Jonathan Ernst [EMAIL PROTECTED] wrote:
Le mardi 03 octobre 2006 à 15:51 -0500, Tom Spear a écrit :[...] I'm by no means an expert on copyright law or copy protection, but I think that using any method other than writing directly to the MBR
with those copy protection measures would be
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.
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).
Copy protection IS security by
why not just implement the write to MBR? figure out how the copy
protector does it and just implement it. as long as you know what
you're doing and where the O/S stores its stuff you should be alright.
put a few warnings on the instaeller and whatnot that this might be
risky, and then let the
What makes copy protection problematic to circumvent is not the math or the
technical stuff, it is the laws protecting it :-(
how does cedega do it?
On 3 oct. 06, at 08:09, Ken Thomases wrote:
The other really big chunk of VM (after Wine) is labeled as STACK
GUARD. I believe the intent of STACK GUARD space is to generate
exceptions (EXC_BAD_ACCESS / SIGSEGV) if a stack grows beyond its
pre-allocated bounds. It's another 1.5GB! This
On Tue, 3 Oct 2006, Marcus Meissner wrote:
Hi,
Added dsound.dll and dsound.vxd and ddhelp.exe
to the fake dlls.
These are checked for by Curse of Monkey Island
DirectX check.
[...]
+11,,ddhelp.exe
11,,ddraw.dll
+11,,dsound.dll
+11,,dsound.vxd
[...]
I think we should not add fake
Quoting EA Durbin [EMAIL PROTECTED]:
What makes copy protection problematic to circumvent is not the math or the
technical stuff, it is the laws protecting it :-(
how does cedega do it?
They license the code for the copy protection detection from the likes
of macrovision.
--
Darragh
On Wednesday 04 October 2006 09:25, Karsten Anderson wrote:
why not just implement the write to MBR?
The user running Wine more than likely won't have such write access to the
disk. Only root would be able to do that, and running Wine as root is far
from encouraged. Plus, fooling around with
Hi,
Karsten Anderson wrote:
why not just implement the write to MBR? figure out how the copy
protector does it and just implement it. as long as you know what
you're doing and where the O/S stores its stuff you should be alright.
put a few warnings on the instaeller and whatnot that this
Hi,
On current git I see that wglBindTexImageARB isn't found on my
system (when running nvidia demos).
Quick look into dlls/winex11.drv/opengl.c reveals:
if (glxRequireExtension(GLX_ATI_render_texture) ||
glxRequireExtension(GLX_ARB_render_texture))
Maybe someone from FSF could provide legal guidance on this issue.
http://www.fsf.org/about/contact.html
Hi,
Right now I'm busy moving all GLX code over to winex11.drv. The
WGL_ARB_render_texture code was one of the pieces of code which I moved over
already. I haven't written the old code but it appeared more or less complete
in case GLX_ATI_render_texture is around. A few parts are implemented
Ivan Gyurdiev [EMAIL PROTECTED] writes:
Note: A new file was started for this purpose: wined3d_types.h. This
is _not_ the same as the one in the wine include folder - that one
should be for types which appear in the interface of wined3d, and must
therefore be exposed to other dlls. This one
Robert Shearman [EMAIL PROTECTED] writes:
This is useful for generated files such as *_i.c and *_p.c (when widl
can generate them).
diff --git a/Make.rules.in b/Make.rules.in
index 9e7ec07..68544dc 100644
--- a/Make.rules.in
+++ b/Make.rules.in
@@ -8,6 +8,7 @@ # MODULE : name of the
Ivan Gyurdiev [EMAIL PROTECTED] writes:
Type: Cleanup
Why:
The const qualifier is unnecessarily restrictive.
I intend to allocate and free such data on the heap in a future patch
(in addition to the current const data).
I still don't see any reason for this. Please fix your code to not
Benjamin Arai [EMAIL PROTECTED] writes:
+ if (fAbbrev)
+if (iFirstDay == 0)
+ localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday +
LOCALE_IFIRSTDAYOFWEEK - 1) % 7);
+else
+ localeValue = LOCALE_SABBREVDAYNAME1 + ((iWeekday + iFirstDay + 4) %
7);
+ else
+if
On 10/4/06, Karsten Anderson [EMAIL PROTECTED] wrote:
why not just implement the write to MBR? figure out how the copy
protector does it and just implement it. as long as you know what
you're doing and where the O/S stores its stuff you should be alright.
put a few warnings on the instaeller
Jesse Allen wrote:
Guys, Wine programs can write to the MBR already with correct
permissions...
http://bugs.winehq.org/show_bug.cgi?id=4672
I hope nobody needs to explain why that's a very bad idea...
It's a very very bad idea, I don't understand why linux doesn't
protect normal users corrupting the disk at byte level that just seems
really bad for security.
On 10/4/06, Aaron Slunt [EMAIL PROTECTED] wrote:
Jesse Allen wrote:
Guys, Wine programs can write to the MBR already with correct
On 04/10/06, Mirek [EMAIL PROTECTED] wrote:
So this is very strange, because under Windows XP i have definitely 8.
Ok, from what app do you want this log?
Mirek
App shouldn't matter, the +d3d_caps log should be the same. But I'll
need the entire extension detection part, ie from the part
On Wed, Oct 04, 2006 at 09:41:16AM -0500, Tom Spear wrote:
I agree that we shouldn't write to the MBR, but I definitely think that we
should get some legal guidance before we proceed with writing anything to a
file (in this case), because
If it isn't a silly question, which part of the mbr
On 04/10/06, Jesse Allen [EMAIL PROTECTED] wrote:
Guys, Wine programs can write to the MBR already with correct permissions...
I think that should read with wrong permissions :-)
Le mercredi 04 octobre 2006 à 21:14 +0100, Martin Owens a écrit :
It's a very very bad idea, I don't understand why linux doesn't
protect normal users corrupting the disk at byte level that just seems
really bad for security.
Every distro does AFAIK. However if people mess with their user's
On 10/4/06, H. Verbeet [EMAIL PROTECTED] wrote:
On 04/10/06, Jesse Allen [EMAIL PROTECTED] wrote:
Guys, Wine programs can write to the MBR already with correct permissions...
I think that should read with wrong permissions :-)
Yes, very wrong from a security standpoint :P
Nick,
I just completed a major upgrade of my system -- x11 6.9.0 (from 6.8.2),
NVidia driver 9625 (from 8774), glibc 2.3.6 (from 2.3.5), gcc 3.4.6
(from 3.3.6), among many other package upgrades.
I built Wine 0.9.22, and it runs fine (including sol.exe, notepad.exe,
and efaxviewer.exe).
Alex Villacís Lasso wrote:
Dreamweaver still can't find the DLL without my patch, even with the
start command, as demonstrated in the previous trace. Did you mean
that my patch *should* have placed the check in ShellExecute? Does
cmd.exe from Windows XP use CreateProcess or ShellExecute?
James Hawkins wrote:
@@ -1456,6 +1456,9 @@ static void msi_dialog_update_pathedit(
prop = msi_dialog_dup_property( dialog, control-property, indirect );
path = msi_dup_property( dialog-package, prop );
+if (!path)
+path = prop;
+
SetWindowTextW( control-hwnd, path
Alexandre Julliard wrote:
Ivan Gyurdiev [EMAIL PROTECTED] writes:
Note: A new file was started for this purpose: wined3d_types.h. This
is _not_ the same as the one in the wine include folder - that one
should be for types which appear in the interface of wined3d, and must
therefore be
Alexandre Julliard wrote:
Ivan Gyurdiev [EMAIL PROTECTED] writes:
Type: Cleanup
Why:
The const qualifier is unnecessarily restrictive.
I intend to allocate and free such data on the heap in a future patch
(in addition to the current const data).
I still don't see any reason for
47 matches
Mail list logo
