- Wine-Devel - list.winehq.org

Re: SetRenderState
by Abdul-Haseeb Ahmad Feb. 14, 2004

Feb. 14, 2004

does anyone know what this is supposed to do, and whether it is something that is critical or not? i get an unhandled exception right after this occurs in nhl2004 trace:d3d:IDirect3DDevice8Impl_SetRenderState (0x4a540020)->(153,0) not handled yet

1 0

SetRenderState
by Abdul-Haseeb Ahmad Feb. 14, 2004

Feb. 14, 2004

does anyone know what this is supposed to do, and whether it is something that is critical or not? i get an unhandled exception right after this occurs in nhl2004 trace:d3d:IDirect3DDevice8Impl_SetRenderState (0x4a540020)->(153,0) not handled yet

1 0

Prototype for PE area preloader
by Mike Hearn Feb. 14, 2004

Feb. 14, 2004

Hi, Attached is a prototype of a technique we can use to solve the problems caused by exec-shield and prelink. Yes, it's complicated. I wish it wasn't, but simpler attempts at this haven't worked. I can't think of another way to do it, given my limited knowledge. It's possible Alexandre can figure something out, but as that hasn't happened yet here is my contribution. This is not useful inside Wine. It's a prototype only - it requires a C99 compiler, the code is a mess, and all it shows is the loader app running "target" which just prints out the mappings. Some more work would be needed to turn this into a patch, but I don't know when I'll get time to do this, so here is my work for others to pick up the baton if they want to. You can see if it's working by ensuring there is only one /dev/zero entry every time when exec-shield-randomize is on. When it is on, the output of "loader" should be different each time, use diff to see this. When exec-shield is off, there should be no differences. Prelink has the same effect but the addresses are randomized in a cron job, not on every program load. Don't worry if you don't fully understand this code, neither do I ;) It's some pretty hardcore voodoo, at least by my standards..... Here is the README contained within: ----------------------------------------------------------------- Mike Hearn <mike(a)theoretic.com> * OK, so what is this? This is a prototype of some code that will allow us to solve the problems exec-shield and prelink are giving Wine. They stop us working because they randomize the load addresses of DSOs, so any linux libraries we link against might get dropped in the middle of the load area we need. This is Bad News. By default EXE files on Windows have their relocation records stripped (to save space). They must be loaded at 0x400000. Because an EXE is always the first thing into an address space, this is no problem. Unfortunately on Wine of course the EXE isn't the first thing into memory - Wine is. Basically, the problem is that the dynamic linker thinks we have a clear and empty address space. In fact we don't, we want a specific region reserved for later use. The dynamic linker (rtld or "elf interpreter") is the first thing that runs in a dynamically linked binary, so we have a problem. Wine doesn't get control until the damage is already done. * How does it work? We have a stub binary, the preloader, which is statically linked. It gets control direct from the kernel, and the rtld isn't run. We mmap the PE load area, with the MAP_FIXED (so we grab the exact range of addresses we need) and MAP_NORESERVE (so we don't try and allocate the memory, which is what scuppered earlier attempts to fix the issue). That's the easy part. It's, what, 4 lines of code? Nothing. It's piffling. The hard part, which is what takes up the other 320 lines of code is restarting the standard boot process. We must do what the kernel would normally do - map in the target (wine-pthread/kthread), relocate the sections to the right place, set up the entry stack for the ELF interpreter and then jump into it in order to convert our static binary, into a dynamic one. Once we reach the other side of the dynamic linker rollercoaster, we can then unmap the load area and tada! we now have a space we can map PE binaries into. This works, for a simple target binary. Will it work once we start throwing more complex stuff (TLS initialization etc)? I just don't know. Only time will tell. I expect so, but there's no way to be 100% sure. This sort of stuff is simply not done anywhere else. * Did you really write this all yourself? Nope, I was aided by the sources to ul_exec (BSD licensed): http://lists.netsys.com/pipermail/full-disclosure/2004-January/015143.html The rtld and kernel sources were valuable references but I didn't use any code from them. * How portable is it? I only tested this on Linux. The problem only manifests itself on Linux - other UNIXy platforms don't have technologise like exec-shield (for security) or prelink (for speed), so it's not a problem there. It's possible they will develop them in future though, so portability is still a concern. In theory it's 100% portable. ELF is a standard, and even though it embedded asm and such, it should still work. MAP_NORESERVE *might* be a GNU extension, I'm not sure, but I don't think it is. We can't work reliably without this flag anyway so it's a moot point.

1 0

Re: Re: Getopt - was Re: problem on the Cygwin port
by Christian Costa Feb. 14, 2004

Feb. 14, 2004

Hi, I've done some further checks and it appears that getopt_long is not broken... It seems to have a conflict with the definition of our own implementation in libwine_port (file getopt1.c). If I rename the latter, glibc's getopt_long works fine again. So I guess it's more a linking issue. Bye, Christian > Message du 13/02/04 16:28 > De : Steven Edwards > A : Dimitrie O. Paun > Copie à : Christian Costa , wine-devel(a)winehq.com > Objet : Re: Getopt - was Re: problem on the Cygwin port > --- "Dimitrie O. Paun" wrote: > > > -#ifndef HAVE_GETOPT_LONG > > > +#if !defined(HAVE_GETOPT_LONG) || defined (__CYGWIN__) > > > > Shouldn't we check in configure if the getopt_long is broken, > > and if so, not use it? > > Yes we should I just didnt have time to do the proper check and rerun > configure. I am going to try to find time to do this soon if no one > beats me to it. > > Thanks > Steven > > __________________________________ > Do you Yahoo!? > Yahoo! Finance: Get your refund fast by filing online. > http://taxes.yahoo.com/filing.html > >

2 2

JOB POSTING - VSTs and Wine
by Michael Ost Feb. 13, 2004

Feb. 13, 2004

Our Menlo Park, CA based startup is looking for someone with strong Wine skills to help us support VST plugins in a Wine environment. Plugin compatibility issues need to be tracked down and solved, either by patching Wine or our hosting environment. Deep experience in Wine configuration and development are important. Strong Windows API skills are important too. An interest in digital music, soft synths and digital effects would be helpful. The position is available immediately. Telecommuting is available. The position would initially be on a contractor basis, but could lead to a full time position. The rate will be based on experience, and the terms are negotiable. If you are interested and qualified, please send an email to jobs(a)museresearch.com with WINE CONTRACTOR in the subject line. Include your resume in the body of the email, and attach it as a separate file as well.

1 0

Re: RSABASE: enough implementation to get Steam to login
by Geoff Thorpe Feb. 13, 2004

Feb. 13, 2004

On February 13, 2004 12:15 pm, Mike McCormack wrote: > This patch allows steam to login. It also provides a framework for > implementing the rest of rsabase.dll correctly using libcrypto.so Cool, I've been looking for an excuse to do something useful on Wine, and as one of the developers of libcrypto.so (www.openssl.org) perhaps this might be the place? Does anyone have good refs/links to the corresponding win32 side of this? Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/

2 1

Re: Is there an opensource MIDL?
by Rolf Kalbermatter Feb. 13, 2004

Feb. 13, 2004

Kuba Ober <kuba(a)mareimbrium.org> wrote: >Do you folks, by any chance, know of an opensource midl compiler that I could >use in my packages? Or is there something at least semi-functional in the >works somewhere? What is about the widl tool in the wine sources? It's by far not complete but maybe it could be useful for your purposes. Rolf Kalbermatter

1 0

Re: Re: Question about system.ini and win.ini
by Christian Costa Feb. 13, 2004

Feb. 13, 2004

> Message du 13/02/04 02:51 > De : Alexandre Julliard > A : Christian Costa > Copie à : wine-devel(a)winehq.com > Objet : Re: Question about system.ini and win.ini > Christian Costa writes: > > > I've just figured out that system.ini and win.ini are no more > > accessible from my ~/.wine directory. > > I had to copy them in the windows directory to make things work. > > Is it a recent change in wine or just a regression? > > It's a side effect of the changes in the profile code to make it use > standard file I/O APIs. I guess you can call it a feature ;-) > > -- > Alexandre Julliard > julliard(a)winehq.com > > ;-) Thanks for the info, Alexandre. Bye, Christian

1 0

Re: Shlwapi: Add IntlStrEqWorker Functions and StrCmp Tests
by Alexandre Julliard Feb. 13, 2004

Feb. 13, 2004

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > +void test_StrCmpA(void) > +{ > + static const char str1[] = {'a','b','c','d','e','f',0x81,'a',0}; > + static const char str2[] = {'a','b','c','d','e','f',0x81,'b',0}; > + static const char str3[] = {'a','B','c','d','e','f',0x81,'a',0}; > + WORD dbcs1 = 0x81 | 'a' << 8; > + WORD dbcs2 = 0x81 | 'b' << 8; DBCS chars depend on the locale, you cannot hardcode them in the test. -- Alexandre Julliard julliard(a)winehq.com

3 3

DLL Version Stamp Problem
by Mike Kost Feb. 13, 2004

Feb. 13, 2004

Framemaker 7.0 installs fine on Wine but pops up an error message that it can't properly determine the version of one of it's dll's (actual error message = "The version stamp is missing from the Framemaker resource file C:\Program Files\Adobe\FrameMaker7.0\fminit\fmres.dll"). After poking at the specific dll (fmres.dll), it has no version information. Does anyone have experience with the Wine/Windows version stamp reading functions (I've seen code references to 'GetFileVersionInfo(<stuff>)') or any advice on debugging further. I've hit the limits of my knowledge. Thanks, Mike K mike at tashcorp dot net

2 4