wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

Current Directory Strangely Affects Behaviour of Applications
by Alan Chandler 11 Feb '01

11 Feb '01

I am trying to debug a game called Grand Prix Legends, running on wine with the transgaming patch. If just spent all day getting nowhere in winedbg because I couldn't get hold of what the game was doing. If I cd to the directory in which the game is installed (ie ~/win/sierra/gpl) and then run wine gpl.exe The program starts and fills the whole of my screen with a single black window. It sits there until I move the mouse, at which time it exits. I have just discovered that if I cd to the root of my c: drive (ie ~/win) and then run wine c:\\sierra\\gpl\\gpl.exe The program starts and I get a 640x480 window with the correct startup screen (I have "Desktop" = "640x480" in my config file). It is NOT managed (even though I have "Managed" = "Y" in my config file). However the program appears to partially work - in that a) The program responds to the mouse when I click on the correct parts of the screen, b) It runs a race with computer AI cars when I tell it too. Can anyone suggest why this subtle change might exist? [As an aside, the colours seem to be the negative of what they should be - but it could just be a completely wrong pallette, the program should respond to the keyboard, but all keys affect the underlying console window in which the game was started, and there is a multiplayer option where it should (at least) detect that I have a TCP/IP connection, but doesn't - can anyone say, are these known limitations of the transgaming patch?] Lastly, is the transgaming patch likely to be folded into the up to date CVS versions of wine anytime soon. Alan alan(a)chandlerfamily.org.uk http://www.chandler.u-net.com

2 3

Re: No implementation for shlwapi.dll.0(StrRetToBufA)
by gerard patel 11 Feb '01

11 Feb '01

At 02:36 PM 11/2/01 +0100, you (I) wrote: >I had just last week a real-life experience with this kind of setup: > <snip> Err, I was wrong, it was probably not an ADSL user, but I don't think it affects the issue : too many mail servers with no control is not good (not until they pay me for the right to spam me :-)) Btw, I wonder if the wine-devel list is not used as a spam resource; since I changed my ISP (6 weeks ago) I only posted my mail address on this list (on cemw or for web surfing I used my old address) and I got the same awful stuff as before only 4 days after my old mail box expired :-/// I remember also (a long time ago) a spam with CC'ed the whole wine-devel subscriber list I think :-) Gerard

1 0

Re: No implementation for shlwapi.dll.0(StrRetToBufA) (fixed)
by David D. Hagood 11 Feb '01

11 Feb '01

I hadn't tried setting an explicit override for shlwapi in the DLLoverrides. Silly me, it never occurred to me that I could ADD MY OWN DLLs. However, I noticed that shlwapi is not in the default configuration for Wine. Perhaps somebody who isn't an Anonymous Coward as far as the CVS server goes should add it? To Francois: thanks for the quick turn-around. Kinda late over there, isn't it?

1 0

No implementation for shlwapi.dll.0(StrRetToBufA)
by David D. Hagood 10 Feb '01

10 Feb '01

I've tried to install several programs under Wine (the most recent being Delorme's AAA MapNGo V6.0) and I consistently get this error: err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufA) imported from shell32.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufW) imported from shell32.dll, setting to 0xdeadbeef Always followed by the app calling StrRetToBufW and dying. It looks to me like this function does exist in the code. I've tried forcing my system to use the native DLL, to use the Wine DLL, to no avail. Any pointers on where to go from here? fixme:pthread_kill_other_threads_np err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufA) imported from shell32.dll, setting to 0xdeadbeef err:win32:fixup_imports No implementation for shlwapi.dll.0(StrRetToBufW) imported from shell32.dll, setting to 0xdeadbeef fixme:pthread_kill_other_threads_np Console: Making console complex (creating an xterm)... fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np fixme:pthread_kill_other_threads_np Warning: locale not supported by C library, locale unchanged

2 2

Re: Benchmark hell...
by Iris Fischer 09 Feb '01

09 Feb '01

Hi there, I found your benchmark... it wasn´t exactly what I was looking for, but do you maybe have an idea on how I can find information about the demand for wine in Canada, or North America on the internet? I´m writing my thesis on importing german wine to Canada and need to go over the demand part too of course. Would be great if you could help me. You can contact me at fischer_iris(a)hotmail.com Thanks a lot, sincerely IRIS FISCHER

6 6

LDT
by Sandie 08 Feb '01

08 Feb '01

Hello i'm french (so i may make some mistakes) I m interested in wine but it is not the main goal of my mail, I would like to know how to change the ldt under linux,because I heard that wine uses this function to run windows program,so if someone Can explain me how to change it or just tell where to get doc it would be nice! Thank you for your help! Please answer me at nicoobzz(a)free.fr

3 2

Problem with Pager control
by Guy L. Albertelli 07 Feb '01

07 Feb '01

While working on ComboEx with the 1/29/2001 CVS, IE4 no longer displays its menu bar. (Well, not really a menu bar, it is a Rebar with a Pager as the child and a Toolbar as a child of the Pager. The Toolbar buttons are the "menu" items.) If I revert the Pager code to the 12/29/2000 version (very limited functionality) then the "menu" appears and is usable. If you need traces, I can provide them. This is with preinstalled copy of IE4. Thanks, Guy Albertelli <<galberte(a)neo.lrun.com>>

2 1

RE: Reverse engineering court decision
by Patrik Stridvall 07 Feb '01

07 Feb '01

> Patrik Stridvall wrote: > > > > > One intresting aspect concerning Wine is the > > DRM (Digital Rights Management) that Slashdot > > reported that Microsoft are going to add to Windows. > > > > If we implement it is Wine we are not trying to circumvent > > it quite the opposite we are trying to to make it possible > > enforce it. ;-) > > > > Of course a one line patch making a critical function > > always return TRUE or something might be able to disable > > it for people that don't like it. :-) > > DO IT! I think we currently have other more important thing to do for Wine 1.0. > What are they going to say, that because you can > change the code > that you are aiding in circumventing copyright protection. It is actually much more intresting than that. Let for arguments sake say that we do it they sue us and the courts rule that it is legal. In that case if the full implementation is legal what about a partial implementation or a buggy implementation? If we have a function CheckIfAllowed that are implemented as FIXME("stub"); return TRUE will it make it a circumvention device. What if CheckIfAllowed is incorrectly used (intentally or by misstake) making things that are not authorized possible? What if we have a full implementation and somebody distributes a one line patch that disable any protection Is that patch a circumvention device? What if somebody says on the mailing list that if you make CheckIfAllowed return TRUE it will disable the protected. Is that _sentence_ a circumvention device? What somebody says that it is really easy to disable just look in the source code? Is that _sentence_ a circumvention device? What if somebody writes a perl script that takes parts of the Wine code and generates and compiles a tools useful for circumvention. Is that perl script a circumvention device? The point that I'm trying to make is that if any program that does Digital Rights Managagement is legal as open source it is without any problem possible make a device that circumvents these rights. This is the logical problem with DMCA unless it is totally draconian, ie everything even remotely related is forbidden, it is almost useless since even with a arbitrary line somewhere you can use whatever is legal and step by step, using steps that are themselves legal transform it to something that are on the other side of the arbitrary line. If law was mathematics this would be sufficient proof that DMCA is logical inconsistant since it would mean that some actions were both legal and illegal. In short no arbitrary line is possible either everything even remotely related is illegal or nothing is illegal. > If they go after > you then you know for sure that they have the poorest of intentions. Well, we already know that their only intention is more profit, so this will not really help us derive anything new.

3 2

Re: debugger fix
by Ulrich Weigand 07 Feb '01

07 Feb '01

I wrote: > Eric Pouech wrote: > > > > Could you send me the libwinspool.drv.so file that objcopy > > > is choking on? I'd like to look whether there's something > > > strange with that. > > here it is... (I've used libpsapi.so instead, because it's smaller, but > > effects are the same) > > Well, one difference I see is that yours has a .rel.stabs section, > while mine doesn't. Now I don't quite understand why stabs need > to be relocated, but I guess this could be a source of confusion. > In any case, after I strip the stabs data using objcopy --strip-debug, > I can subsequently use objcopy -N without problems. > > The problem might be caused by the objcopy -L step not correctly > updating the debug info. Could you try adding a --debugging > argument to objcopy in both localize_imports and strip_imports? No, it's definitely a problem with the .rel.stabs section. In fact, *every* invocation of objcopy that leaves the .rel.stabs section in its output fails -- even a simple identical copy. (Note that if you *remove* the .rel.stabs section, it works -- this is why a normal 'strip' works ...) The reason for this is that objcopy relies on the bfd library to assign the file offsets of the sections in the output file. Unfortunately, the automatic assignment is done only for sections that are part of a segment (i.e. loaded into memory), and also for *those* sections outside of segments that are *not* reloc sections ... For reloc sections outside of segments, like the .rel.stabs section, no automatic file offset assignment is performed. Instead, the upper layers must do this themselves, which e.g. the linker does in its final_link step. The objcopy tool, however, never does. This leads to an invalid file offset being used when writing out the .rel.stabs section, which causes the abort. As a side note: I've tried using the --debugging argument, which basically recreates the debug sections from scratch instead of copying them, and this fails completely with my toolchain -- it runs into an endless loop. The reason for this is apparently a compiler bug in gcc 2.95.2 that miscompiles a routine from objcopy by converting a recursive function call into tail recursion in an invalid way ... I still don't understand why your toolchain creates a .rel.stabs section in the first place. Could you check at which point this is created first (as, ld, ld -shared)? Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

2 4

RE: Reverse engineering court decision
by Patrik Stridvall 06 Feb '01

06 Feb '01

> Patrik, that was probably one of the most well-written > arguments I have > heard against the DMCA. Thank you, my immidiate reaction when proof reading it was that it was not entirely clear but I didn't feel I had time to improve it more. The arguement is not really water tight it assumes that you legally can reverse engineer, implement and publish an existing Digital Rights Managagement scheme. All of this is possible because of the duality between the rights management and circumvention. Any attempt to partition the set of devices in two parts will fail since you mathematically will be able to prove that they are equal and thus the arbitrary line chosen in the beginning doesn't really exist. However note that there are three solutions to the problem. 1. The DMCA protects nothing and are totally meaningless. 2. The DMCA are logically inconsistant and thereby null and void. 3. The DMCA will forbid digital rights management without authorization as well. The only thing that can save you is if you can pry a crack in it somewhere by find some kind of allowed digital rights management or circumvention because of some other reason, like constitional issues. If you even have one crack, then only possible case is 1, because of the reason given above. Note that 3 would mean that making an exact copy of some a device will be illegal if it contained any kind of digital right mangagement, thereby granting it a perpetual patent protection if it was hardware alternativly perpetual copyright protection if it was software. This kind of argument are not really new, however the arguments I have seen used it when talking about protected works. I'm talking about _devices_ that are authorized to "play" such works. Not being an expert on constitional issues I will say nothing more than that I think it would be unlikely that it is not so. > Too bad probably only Wine > developers will see it. I don't think it would be a useful argument to use in court it is much to abstract for normal Judges to understand. Better stick to constitional issue I think. > Ever thought of becoming a lawyer? ;-) No, I hate lawyers. :-) BTW, concerning reverse engineering any law against reverse engineering will have similar logical problems as DMCA since if some things are legal to reverse engineer it will be possible to using a similar step by step method transform this to something of the other side of any arbitrary line. Fortunately no such law exists AFAIK.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel