Re: Implementing sxs?
Dan Kegel wrote: Presumably more semi-intelligent futzing with the stubs will get us by for a lot of apps, but I wonder: how soon are we going to have to really implement side-by-side assemblies? A good first step would be to write a simple test case that shows what they do... Mike
Implementing sxs?
http://bugs.winehq.org/show_bug.cgi?id=5276 and its ilk are becoming increasingly annoying. I marked two more bugs as being blocked by this just now. Presumably more semi-intelligent futzing with the stubs will get us by for a lot of apps, but I wonder: how soon are we going to have to really implement side-by-side assemblies?
Re: [D3D9 1/8] Remove const qualifier on state_test data
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 this. Please fix your code to not require that change by simply saving the pointer you are going to free somewhere else. It's already marked const in the parameters of the set and get functions, which means it can't be modified there (arg 3): +void (*set_handler) (IDirect3DDevice9* device, const struct state_test* test, const void* data_in); +void (*get_handler) (IDirect3DDevice9* device, const struct state_test* test, const void* data_out); I guess you get protection against modifying it in the init and teardown functions (which is never going to happen - those are two functions you write at the same time, located directly next to each other)... at the cost of significantly reducing code readability. I would have to define a "test_allocations" structure or something like that, and put the very same pointers in there, and then free them at the end...
Re: [WINED3D 1/6] Move D3DSIO structure into the WINED3D namespace.
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 exposed to other dlls. This one is private. I think the dll interface should be strictly enforced, so private structures have no place outside our folder. This will cause massive confusion. There is already a wined3d_private.h file, you should put that stuff in there. The amount of structures added will quickly result in an unmaintainable header. There's a very clear difference between the two - wined3d_types.h would be for types equivalent to the d3d types - essentially no maintainance, simply map one-to-one to d3d. wined3d_private.h would be for shared structures that we come up with. Also, wined3d_private.h includes wined3d_types.h. I will comply if you want it this way, but I disagree - smaller files are easier to work with. In fact, I think having a single private header per dll is probably a mistake as well.
Re: msi [3/12]: Assign the property to path if the property is empty
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 ); SendMessageW( control->hwnd, EM_SETSEL, 0, -1 ); Later on in that code block, it does: msi_free( path ); msi_free( prop ); If path and prop point to the same thing, then we'll try free and illegal pointer. Looks like it would be better to replace msi_dup_property() with another (new) macro function that understands this behavior, rather than changing the code similarly in 4 places. Mike
Re: KERNEL: honor additional DLL search paths under HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths
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? cmd.exe uses CreateProcess by default, and ShellExecute if you use "start". The ShellExecute code isn't perfect, so if you're going to fix something, start looking there. Mike
Re: Wine 0.9.21 fails to run
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). My thought is that something in my libs was not playing well with Wine. For now, let's consider this problem closed. -kz Nick Law wrote: Ken Zalewski wrote: Hi Nick, Thanks for the advice and patches. However, Wine still fails to run ANY programs at all. This is with both of the patches applied (the "ATI" patch and the "NVidia" patch). Moving back to 0.9.20 makes everything work again. My OpenGL library is from NVidia driver 8774 (the most recent), and x11 is 6.8.2. If there is anything you would like me to provide in order to diagnose this, let me know. Thanks. -kz Nick Law wrote: Ken Zalewski wrote: I just upgraded from 0.9.20 to 0.9.21, and now nothing will run, including simple programs such as sol.exe and notepad.exe. The error message I'm receiving is: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 145 (NV-GLX) Minor opcode of failed request: 4 () Resource id in failed request: 0x242 Serial number of failed request: 19 Current serial number in output stream: 19 My system is a Slackware 10.2 system, running kernel 2.6.17.13, x11 6.8.2, and NVidia driver 8774. I have seen some other postings on the Net about this, including postings in the Ubuntu forums (which means that this is not limited to Slackware). Downgrading to 0.9.20 gets everything working again. My guess, based on the "NV-GLX" message, is that something was changed in the OpenGL support between 0.9.20 and 0.9.21, and it has broken Wine. I'll be happy to help debug this. Sincerely, Ken Zalewski Slackware package maintainer Linuxpackages.net That's correct, on the wow 1.12 AppDB page in the latest news section you'll find two patches, the patch marked ATI ( or FBconfigregression ) will fix the opengl & D3D problems. You can download and apply both irrespective of what graphics card you have. Regards Nick Law Can you list all the programs that you have executed that failed and also any that work, like winecfg .. Regarding notepad.exe, that fails on my system (0.9.21) with a segmentation fault. Start the programs from a terminal ( i.e. wine notepad.exe ) etc and tell us what the errors are ? Do this for each program as the errors may be different. Thanks Nick
Re: Copy protection
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
Re: Copy protection
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 rights or don't understand why running user applications as root is dangerous there is nothing Linux can do against it. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Copy protection
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" :-)
Re: Copy protection
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 sector do the games think they can access? Especially for write ? Having written the mbr code that NetBSD uses - which could validly be in sector zero of the boot disk of a windows systesm - I'm not at all certain there any bytes that can usefully be used. David -- David Laight: [EMAIL PROTECTED]
Re: wined3d: Report the correct number of available 4-component float vectors for GLSL
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 where it says "Filling vendor string NVIDIA Corporation" all the way down to "GLX Extension reported:". Also, I tried 3DMark03 with the new drivers and git HEAD, and didn't notice anything strange. GL_MAX_TEXTURE_UNITS_ARB (still) returns 4 for me as well.
Re: Copy protection
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 > permissions... > > http://bugs.winehq.org/show_bug.cgi?id=4672 > > > I hope nobody needs to explain why that's a very bad idea...
Re: Copy protection
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...
Re: Copy protection
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 and whatnot that this might be risky, and then let the user decide for himself :) Guys, Wine programs can write to the MBR already with correct permissions... http://bugs.winehq.org/show_bug.cgi?id=4672
Re: [PATCH 1/3] lz32/tests: Test more last errors set by LZOpenFile[AW].
* On Tue, 3 Oct 2006, Detlef Riekenberg wrote: > * On Di, 2006-10-03 at 20:40 +0300, Saulius Krasuckas wrote: > > Well, thanks. I'll change that, but is it wrong just because it > > slightly increases code complexity for no direct benefit? I just want > > to know for future. > > For the normal case, SetLastError() is called only on failure. > > http://msdn.microsoft.com/library/en-us/debug/base/setlasterror.asp Do we trust MSDN when we can check things ourselves? No, we don't trust, right? :) > There might be some broken Applications, that expect GetLastError() to > return a special Value, even when a Function returns success, but they > will fail very fast on native Windows with a different version of > Windows, SP, Hotfix or Driver. That could be a way for a program to differentiate between 9x and NT versions without calling GetVersion*(). I saw one code/app in the past, which did such check by querying kernel32.dll for the OpenVxD export ;) > Do you have such a Application? No, I didn't. If I had, that would be my primary argument. I even doubt there exist any application that calls LZOpenFileW() in the world, but still Wine implements it plus it contains W-to-A cross-call, by eliminating which I want to ensure no algorithmic logic was flawed in A-version or in W-version of mentioned function. Hence my intense testing for SetLastError(). I hoped this would let me easier to (re)build code for LZOpenFile[AW]. It would make the code stricter. So I won't be lost in some lots of possible solutions ;) But nevermind, Detlef. I will add those "wrong" checks just in some of my internal branches to make my fantasyless life easier and won't disturb the life of the whole project :]
Re: oleaut32 1/2: [try 3] Implements function varformat:VarWeekdayName
"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 (iFirstDay == 0) > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + LOCALE_IFIRSTDAYOFWEEK - > 1) % 7); > +else > + localeValue = LOCALE_SDAYNAME1 + ((iWeekday + iFirstDay + 4) % 7); This obviously can't work, LOCALE_IFIRSTDAYOFWEEK is a constant. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [D3D9 1/8] Remove const qualifier on state_test data
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 require that change by simply saving the pointer you are going to free somewhere else. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Make.rules.in: Add a new make variable "C_GEN_SRCS" for C files that need to be generated before makedep can be run on them.
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 module bein > # > # Each individual makefile may define the following additional variables: > # C_SRCS : C sources for the module > +# C_GEN_SRCS : C sources that are generated for the module You shouldn't need that. IDL files will be listed as sources and make depend will be able to handle that properly, just like it handles idl headers already. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [WINED3D 1/6] Move D3DSIO structure into the WINED3D namespace.
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 is private. I think the > dll interface should be strictly enforced, so private structures have > no place outside our folder. This will cause massive confusion. There is already a wined3d_private.h file, you should put that stuff in there. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Register policy for WGL_ARB_render_texture
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 when it
isn't around. When the move is done I might look into it as there are various
other parts which still need to be rewritten. I guess FBOs can be used for this
purpose.
Roderick
> 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"))
> register_extension(&WGL_ARB_render_texture);
>
> My glxinfo doesn't show GLX_ATI_render_texture nor
> GLX_ARB_render_texture - if i remove that if and force
> register_extension - all is working
>
> The card is GeForce 6200/AGP on opengl 2.0.2 NVIDIA 87.74. I would
> like only to point that buggy code - maybe someone will came with nice
> fix.
>
> http://bugs.winehq.org/show_bug.cgi?id=6329
>
> take care,
> --
> Paweł Różański
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: Copy protection
Maybe someone from FSF could provide legal guidance on this issue. http://www.fsf.org/about/contact.html
Register policy for WGL_ARB_render_texture
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"))
register_extension(&WGL_ARB_render_texture);
My glxinfo doesn't show GLX_ATI_render_texture nor
GLX_ARB_render_texture - if i remove that if and force
register_extension - all is working
The card is GeForce 6200/AGP on opengl 2.0.2 NVIDIA 87.74. I would
like only to point that buggy code - maybe someone will came with nice
fix.
http://bugs.winehq.org/show_bug.cgi?id=6329
take care,
--
Paweł Różański
Re: Copy protection
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 might be > risky, and then let the user decide for himself :) 1. I don't think that it's really the MBR, because it's 512 Bytes are already too cramped with the partition table and the boot loader. Chances to break those things are too high. Maybe it's really an (unused) sector after the MBR, but even than: 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) Greetings KGJ
Re: Copy protection
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 the MBR like that is quite dangerous.
Re: Copy protection
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 "Nothing's foolproof to a sufficently talented fool" Email service provided by the NUI, Galway Computer Society
Re: [PATCH] add some more fake binaries
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 exes if we don't have the corresponding Winelib exe. I have seen it cause applications think that the exe is available and thus try to run it which fails (hence commit efafe08fc6a6d843e52069095947c70abeab867e). So here it seems to fix an application but it may just break many others. IMHO, it would be better to (also) add a stub. Fake dlls probably have the same issue but maybe not vxds. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
Re: Mem usage in Mac OSX
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 seems like the real culprit. I think STACK GUARD pages should only show up in single-page areas (4K) on either side of a stack. I'm seeing huge areas (~240MB, ~250MB, and ~1GB). There's only one actual stack showing. It's 8MB, between the 250MB guard and the 1GB guard. Checking a normal Mac app (Mail) shows no such huge STACK GUARD areas -- just a single 4K page below each actual stack. I have no idea what's creating these huge stack guard areas. It seems that Wine itself asks for it, see: vmmap on winemine: STACK GUARD8fe7-9000 [ 1600K] ---/rwx SM=NUL STACK GUARDb000-bf80 [253952K] ---/rwx SM=NUL STACK GUARDc000-ffe0 [1046528K] ---/rwx SM=NUL gdb reports: (gdb) break mmap if *(int*)($esp+8) == 0xc000 (gdb) c Continuing. Breakpoint 3, 0x90016cc3 in mmap () #0 0x90016cc3 in mmap () #1 0x60209503 in try_mmap_fixed (addr=0xc000, len=536870912, prot=0, flags=4162, fildes=-1, off=0) at mmap.c:177 #2 0x6020994d in reserve_area (addr=0xc000, end=0xe000) at mmap.c:233 #3 0x6020996a in reserve_area (addr=0xc000, end=0x0) at mmap.c:283 #4 0x602099ef in mmap_init () at mmap.c:350 #5 0x60208829 in wine_init (argc=2, argv=0xb9e8, error=0xb580 "", error_size=1024) at loader.c:648 #6 0x7bf00f2d in main (argc=2, argv=0xb9e8) at main.c:58 Pierre
Re: Copy protection
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?
Re: Copy protection
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 user decide for himself :) On 10/4/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > 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 obscurity from a cryptography point of view ;-) http://en.wikipedia.org/wiki/Kerckhoffs'_principle The thing is that the user HAS to be able to decrypt the movie / game / whatever and use it, so in some form he HAS to have the keys. The only thing that can be hidden is the algorithm and the location of the keys(sort of part of the algorithm). This can't work from a mathematical point of view. What makes copy protection problematic to circumvent is not the math or the technical stuff, it is the laws protecting it :-(
Re: Copy protection
> 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 obscurity from a cryptography point of view ;-) http://en.wikipedia.org/wiki/Kerckhoffs'_principle The thing is that the user HAS to be able to decrypt the movie / game / whatever and use it, so in some form he HAS to have the keys. The only thing that can be hidden is the algorithm and the location of the keys(sort of part of the algorithm). This can't work from a mathematical point of view. What makes copy protection problematic to circumvent is not the math or the technical stuff, it is the laws protecting it :-( pgpnJxzYMqQW6.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
Re: Copy protection
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 illegal because writing> to a file (registry, wine-only proprietary db or any other type of> file) as opposed to writing to the mbr like the copy protection is > supposed to could potentially reveal data that the copy protection> companies don't want being revealed, and therefore that would end up> making wine a possible target for aiding circumvention. Sure there > are tools out there that crackers use that read the mbr and store it> in a file, so that they can circumvent the copy protection, but that> has nothing to do with wine.This doesn't require cracker tools, reading a MBR using standard tools like dd is as easy as reading a file or registry.JonathanGood point. I'll shut up now lol.-- ThanksTomCheck out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://www.imvu.com/catalog/web_registration.php?userId=1547373
Re: 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: wined3d: Report the correct number of available 4-component float vectors for GLSL
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 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 GL_MAX_TEXTURE_UNITS_ARB as well. Also, that's not the entire extension detection log.
Re: Copy protection
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 what isnt if you have a file that contains an entire drive's worth of data. 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.
Re: Copy protection
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 (registry, wine-only proprietary db or any other type of > file) as opposed to writing to the mbr like the copy protection is > supposed to could potentially reveal data that the copy protection > companies don't want being revealed, and therefore that would end up > making wine a possible target for aiding circumvention. Sure there > are tools out there that crackers use that read the mbr and store it > in a file, so that they can circumvent the copy protection, but that > has nothing to do with wine. This doesn't require cracker tools, reading a MBR using standard tools like dd is as easy as reading a file or registry. Jonathan signature.asc Description: Ceci est une partie de message numériquement signée
Re: wined3d: Report the correct number of available 4-component float vectors for GLSL
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 GL_MAX_TEXTURE_UNITS_ARB as well. Also, that's not the entire extension detection log.
Re: [PATCH 1/3] Compile oleaut32 for win32 but not for win64
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@ @OPENGLFILES@ @XFILES@ > > Why? I don't understand your question. If you mean that I forgot @WIN32FILES@, I didn't. My copy of the patch has it. I don't think "stgit mail" could have lost it, but my message is not in the archives yet, so I cannot check at the moment. Perhaps @WIN32FILES@ got lost on your side. If you mean why this was needed at all, then the answer is that it's one of two compile errors that prevents building Wine for win64. I think it's much more important to concentrate on more fundamental problems, such as crashes, rather than a compile error in one of the dlls. It looks like you know the right solution (http://www.winehq.com/hypermail/wine-devel/2004/10/0356.html), so it would be great if you do it this way. The comment in oaidl_p.c says that it was generated and tweaked. I just don't know what exactly needs to be done. I can have a look, but I cannot promise I'll come with a better solution soon. -- Regards, Pavel Roskin
Re: Copy protection
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 illegal because writing to a file (registry,> > wine-only proprietary db or any other type of file) as opposed to writing to> > the mbr like the copy protection is supposed to could potentially reveal > > data that the copy protection companies don't want being revealed, and> > therefore that would end up making wine a possible target for aiding> > circumvention. Sure there are tools out there that crackers use that read > > the mbr and store it in a file, so that they can circumvent the copy> > protection, but that has nothing to do with wine.>We should allow are technical solutions to be bogged down with the EUCD, we are clearly protected for making a compatible program and Ithink we should strive to introduce the protection under the technicalmeans we have available.the fact that we allow the copy protection to work at all proves we have no malicious intent.It would clearly be dangerous to write to the MBR and I would notrecommend us doing so.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 1) as we have seen all too often lately, the US court system doesn't always see things the way everyone else does (cf NSA wiretapping bill(s)). and2) see previous emails about why writing _only_ the MBR to a file could be a sticky mess for some of us. 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? -- ThanksTomCheck out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://www.imvu.com/catalog/web_registration.php?userId=1547373
Re: Copy protection
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, > wine-only proprietary db or any other type of file) as opposed to writing to> the mbr like the copy protection is supposed to could potentially reveal> data that the copy protection companies don't want being revealed, and > therefore that would end up making wine a possible target for aiding> circumvention. Sure there are tools out there that crackers use that read> the mbr and store it in a file, so that they can circumvent the copy > protection, but that has nothing to do with wine.Could you not say the same thing for vmware or any other virtualharddrive application?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 what isnt if you have a file that contains an entire drive's worth of data. -- ThanksTomCheck out this new 3D Instant Messenger called IMVU. It's the best I have seen yet!http://www.imvu.com/catalog/web_registration.php?userId=1547373
Re: [TRY2 1/8] gdi32: Cleanup the update_font_info().
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)
> +{
> +RegSetValueExA(hkey, value_name, 0, REG_SZ,
> + (const BYTE *)value_data, (DWORD)(strlen(value_data)
> + 1));
> +}
You shouldn't need the DWORD cast here.
> @@ -1546,6 +1528,7 @@ static void update_font_info(void)
> +if(!matched_nls_font_list)
> +{
> +FIXME("there is no font defaults for lcid %04lx/ansi_cp %u", lcid,
> ansi_cp);
> +return;
> +}
Could you add the missing \n in the FIXME and change the text to read
"There are no..."?
Thanks,
Huw.
Re: wined3d: Report the correct number of available 4-component float vectors for GLSL
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:
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_color_buffer_float
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_depth_texture
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_draw_buffers
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB_draw_buffers support
- max buffers=4
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_fragment_program
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB Pixel Shader support
- version=11
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB Pixel Shader support
- GL_MAX_TEXTURE_IMAGE_UNITS_ARB=16
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB Pixel Shader support
- max float constants=256
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB Pixel Shader support
- max temporaries=32
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB Pixel Shader support
- max instructions=4096
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_fragment_program_shadow
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_fragment_shader
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB_fragment_shader
(GLSL) support - max float ps constants=128
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_half_float_pixel
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB Half-float pixel support
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_imaging
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB imaging support
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_multisample
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB Multisample support
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_multitexture
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB Multitexture support
- GL_MAX_TEXTURE_UNITS_ARB=8
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_occlusion_query
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB Occlusion Query support
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_pixel_buffer_object
trace:d3d_caps:IWineD3DImpl_FillGLCaps FOUND: ARB Pixel Buffer support
trace:d3d_caps:IWineD3DImpl_FillGLCaps - GL_ARB_point_parameters
Mirek
H. Verbeet napsal(a):
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, "GL_ARB_multitexture") == 0) {
glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, &gl_max);
+ gl_max *= 2;
TRACE_(d3d_caps)(" FOUND: ARB Multitexture support -
GL_MAX_TEXTURE_UNITS_ARB=%u\n", gl_max);
gl_info->supported[ARB_MULTITEXTURE] = TRUE;
gl_info->max_textures = min(MAX_TEXTURES, gl_max);
That doesn't look quite correct. What is the actual problem / could
you attach a +d3d_caps log (Just the part where it does extension
detection)?
Re: wined3d: Report the correct number of available 4-component float vectors for GLSL
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, "GL_ARB_multitexture") == 0) {
glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, &gl_max);
+ gl_max *= 2;
TRACE_(d3d_caps)(" FOUND: ARB Multitexture support -
GL_MAX_TEXTURE_UNITS_ARB=%u\n", gl_max);
gl_info->supported[ARB_MULTITEXTURE] = TRUE;
gl_info->max_textures = min(MAX_TEXTURES, gl_max);
That doesn't look quite correct. What is the actual problem / could
you attach a +d3d_caps log (Just the part where it does extension
detection)?
Re: wined3d: Report the correct number of available 4-component float vectors for GLSL
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 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 to ask Alexandre what he
would consider acceptable.
--- 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, "GL_ARB_multitexture") == 0) {
glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, &gl_max);
+ gl_max *= 2;
TRACE_(d3d_caps)(" FOUND: ARB Multitexture support -
GL_MAX_TEXTURE_UNITS_ARB=%u\n", gl_max);
gl_info->supported[ARB_MULTITEXTURE] = TRUE;
gl_info->max_textures = min(MAX_TEXTURES, gl_max);
Re: [PATCH 1/3] Compile oleaut32 for win32 but not for win64
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
Re: wined3d: Report the correct number of available 4-component float vectors for GLSL
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 to ask Alexandre what he would consider acceptable.
Re: wined3d: Report the correct number of available 4-component float vectors for GLSL
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, 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 Flatout 2, Tomb Raider
Legend, Need for Speed Most Wanted, 3DMark 2005 and 2006 working like
with stable driver.
I am using Nvidia GF 6800 GS PCI-E with Core 2 Extreme and GLSL
functions no ARB.
Mirek
It's possible those are actual bugs in our GLSL. The 96.25 drivers'
GLSL compiler seems to be quite a bit stricter than previous versions.
As for the constants issue, I see a few options, none of which I
particularly like:
- Keep it the way it currently is. Correct, but breaks the current
stable drivers
- Revert the patch. The code will be incorrect, and break with 96.25
and later drivers. The current stable drivers will work though.
- Add a version check. Quite ugly, but should work with both sets of
drivers. Good luck convincing Alexandre on that one :-)
Personally I'm leaning towards the first option, in part because
driver bugs are one of the reasons GLSL isn't enabled by default at
the moment, in part because the code is simply correct.
---
dlls/wined3d/directx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index fdde6ea..0e61c67 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -546,6 +546,7 @@ #undef USE_GL_FUNC
} else if (strcmp(ThisExtn, "GL_ARB_fragment_shader") == 0) {
gl_info->supported[ARB_FRAGMENT_SHADER] = TRUE;
glGetIntegerv(GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB, &gl_max);
+if ( gl_max >= 256 )
+gl_max /= 4;
TRACE_(d3d_caps)(" FOUND: ARB_fragment_shader (GLSL) support - max
float ps constants=%u\n", gl_max);
gl_info->ps_glsl_constantsF = gl_max;
} else if (strcmp(ThisExtn, "GL_ARB_imaging") == 0) {
@@ -618,6 +619,7 @@ #undef USE_GL_FUNC
} else if (strcmp(ThisExtn, "GL_ARB_vertex_shader") == 0) {
gl_info->supported[ARB_VERTEX_SHADER] = TRUE;
glGetIntegerv(GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB, &gl_max);
+if ( gl_max >= 256 )
+gl_max /= 4;
TRACE_(d3d_caps)(" FOUND: ARB_vertex_shader (GLSL) support - max
float vs constants=%u\n", gl_max);
gl_info->vs_glsl_constantsF = gl_max;
} else if (strcmp(ThisExtn, "GL_ARB_vertex_blend") == 0) {
---
dlls/wined3d/directx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index fdde6ea..0e61c67 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -546,6 +546,7 @@ #undef USE_GL_FUNC
} else if (strcmp(ThisExtn, "GL_ARB_fragment_shader") == 0) {
gl_info->supported[ARB_FRAGMENT_SHADER] = TRUE;
glGetIntegerv(GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB, &gl_max);
+if ( gl_max > 256 )
+gl_max /= 4;
TRACE_(d3d_caps)(" FOUND: ARB_fragment_shader (GLSL) support -
max float ps constants=%u\n", gl_max);
gl_info->ps_glsl_constantsF = gl_max;
} else if (strcmp(ThisExtn, "GL_ARB_imaging") == 0) {
@@ -618,6 +619,7 @@ #undef USE_GL_FUNC
} else if (strcmp(ThisExtn, "GL_ARB_vertex_shader") == 0) {
gl_info->supported[ARB_VERTEX_SHADER] = TRUE;
glGetIntegerv(GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB, &gl_max);
+if ( gl_max > 256 )
+gl_max /= 4;
TRACE_(d3d_caps)(" FOUND: ARB_vertex_shader (GLSL) support -
max float vs constants=%u\n", gl_max);
gl_info->vs_glsl_constantsF = gl_max;
} else if (strcmp(ThisExtn, "GL_ARB_vertex_blend") == 0) {
Re: wined3d: Report the correct number of available 4-component float vectors for GLSL
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 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 Flatout 2, Tomb Raider
Legend, Need for Speed Most Wanted, 3DMark 2005 and 2006 working like
with stable driver.
I am using Nvidia GF 6800 GS PCI-E with Core 2 Extreme and GLSL
functions no ARB.
Mirek
It's possible those are actual bugs in our GLSL. The 96.25 drivers'
GLSL compiler seems to be quite a bit stricter than previous versions.
As for the constants issue, I see a few options, none of which I
particularly like:
- Keep it the way it currently is. Correct, but breaks the current
stable drivers
- Revert the patch. The code will be incorrect, and break with 96.25
and later drivers. The current stable drivers will work though.
- Add a version check. Quite ugly, but should work with both sets of
drivers. Good luck convincing Alexandre on that one :-)
Personally I'm leaning towards the first option, in part because
driver bugs are one of the reasons GLSL isn't enabled by default at
the moment, in part because the code is simply correct.
---
dlls/wined3d/directx.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index fdde6ea..0e61c67 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -546,6 +546,7 @@ #undef USE_GL_FUNC
} else if (strcmp(ThisExtn, "GL_ARB_fragment_shader") == 0) {
gl_info->supported[ARB_FRAGMENT_SHADER] = TRUE;
glGetIntegerv(GL_MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB, &gl_max);
+if ( gl_max >= 256 )
+gl_max /= 4;
TRACE_(d3d_caps)(" FOUND: ARB_fragment_shader (GLSL) support -
max float ps constants=%u\n", gl_max);
gl_info->ps_glsl_constantsF = gl_max;
} else if (strcmp(ThisExtn, "GL_ARB_imaging") == 0) {
@@ -618,6 +619,7 @@ #undef USE_GL_FUNC
} else if (strcmp(ThisExtn, "GL_ARB_vertex_shader") == 0) {
gl_info->supported[ARB_VERTEX_SHADER] = TRUE;
glGetIntegerv(GL_MAX_VERTEX_UNIFORM_COMPONENTS_ARB, &gl_max);
+if ( gl_max >= 256 )
+gl_max /= 4;
TRACE_(d3d_caps)(" FOUND: ARB_vertex_shader (GLSL) support -
max float vs constants=%u\n", gl_max);
gl_info->vs_glsl_constantsF = gl_max;
} else if (strcmp(ThisExtn, "GL_ARB_vertex_blend") == 0) {
Re: wined3d: Report the correct number of available 4-component float vectors for GLSL
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 Flatout 2, Tomb Raider Legend, Need for Speed Most Wanted, 3DMark 2005 and 2006 working like with stable driver. I am using Nvidia GF 6800 GS PCI-E with Core 2 Extreme and GLSL functions no ARB. Mirek It's possible those are actual bugs in our GLSL. The 96.25 drivers' GLSL compiler seems to be quite a bit stricter than previous versions. As for the constants issue, I see a few options, none of which I particularly like: - Keep it the way it currently is. Correct, but breaks the current stable drivers - Revert the patch. The code will be incorrect, and break with 96.25 and later drivers. The current stable drivers will work though. - Add a version check. Quite ugly, but should work with both sets of drivers. Good luck convincing Alexandre on that one :-) Personally I'm leaning towards the first option, in part because driver bugs are one of the reasons GLSL isn't enabled by default at the moment, in part because the code is simply correct.
