February 2004 - Wine-Devel - list.winehq.org

Re: Setup .inf files
by Kevin Koltzau Feb. 15, 2004

Feb. 15, 2004

On Saturday 14 February 2004 10:22 pm, Chris Morgan wrote: > The best documentation I've found thus far for inf files, > http://www.leeos.com/infdoc.html#Top, doesn't have anything about running > programs from inside of an inf file. If this is possible it would probably > make more sense to have the inf file register the dlls. There is no way to do this that I'm aware of. Usually you would add a RunOnce registry key in HKLM to call regsvr32

1 0

Re: Darwine Update, Question
by ATMRD＠aol.com Feb. 15, 2004

Feb. 15, 2004

Dimi, In a message dated 2/13/04 1:37:17 AM, dpaun(a)rogers.com writes: > > What configure script is that, I can't imagine why we would be looking > for this atldef.h file... > > It is the configure script created after running winemaker on the source directory. ~Sanjay Connare

2 1

using the FIXME macro
by Zimler Attila Feb. 15, 2004

Feb. 15, 2004

Hi List, I would like to use the FIXME macro in my piece of code. I found out that this macro is declared in "include/wine/debug" and my code compile's well, but I got an error at link time. The error message is: undefined reference to 'FIXME'. I think I should link a library to the code. But I don't find which. Could somebody help with that library's name? Thanks, Attila

3 2

Re: SHDOCVW: Mozilla Active X control embedding done right
by Dimitrie O. Paun Feb. 14, 2004

Feb. 14, 2004

On February 13, 2004 12:35 pm, Mike McCormack wrote: > OK, this time I've done it the right way, and it at least works for one > or two apps, with a screen shot to prove it. Very cool indeed Mike! One thing that I've noticed is that the code uses a lot of Mozilla dependent names, but the only thing that's actually Mozilla specific is the CLSID. Shouldn't we just read that info from the registry (from some sort of HtmlControl key), so that people can experiment with other things as well (e.g. IE) just by changing the configuration? Another thing: + if( !SHDOCVW_GetMozctlPath( szPath, sizeof szPath ) ) where szPath is an array of WCHAR, so you pass the size in bytes (sizeof szPath).I hope that's OK (I have to run now, and I don't have time to look up Reg* docu). :) -- Dimi.

3 3

#winehackers IRC logs
by Mike Hearn Feb. 14, 2004

Feb. 14, 2004

Was not feeling in a wine-hacking mood so I wrote this instead: http://www.navi.cx/~mike/winelogs/ Voila, you can now see the stuff we all talk about in there, updated in real time. You need an XSLT capable browser. Any modern gecko browser will do it, as will IE6 with the a recent MSXML. Konqueror will not. Opera will not. At some point I may move the xslt processing serverside, but not sure when I'll have the motivation. Have fun! thanks -mike

3 3

Is there an opensource MIDL?
by Kuba Ober Feb. 14, 2004

Feb. 14, 2004

Hi, I'm putting up a cross-compilation environment for Qt/Win (Professional/Enterprise) so that it could be built (and the applications using it!) with crossmingw32 (http://www.ibib.waw.pl/~winnie) In order to enable myself (and other people) to "natively" use ActiveX (and thus ActiveQT), I guess I need to find an IDL compiler, right? I think that Qt needs it for ActiveQT... 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? My web searches didn't turn up with anything... Thanks, Kuba Ober PS. Please CC replies to me as I'm not on wine-devel

5 4

Re: SetRenderState
by Ann and Jason Edmeades Feb. 14, 2004

Feb. 14, 2004

>trace:d3d:IDirect3DDevice8Impl_SetRenderState (0x4a540020)->(153,0) not handled yet This says the apps has called (or as part of replaying a state block, we have called) set render state, with parm 153 == D3DRS_SOFTWAREVERTEXPROCESSING, and we haven't implemented it, but this would not account for an exception. That render state just tells d3d not to do software rendering, it wants hardware (I think, from memory), but doesn't change any parms / behaviour from d3d8. The question is where does it trap and why. This is usually the golden question, and a backtrace may help but might not - it all depends on what has happened. This is where we can spend hours trying to work out what has gone wrong. I remember you mentioned the resolutions were not being shows - Your d3d trace you sent me showed us returning 15 or 16 different display resolutions / bpp, so I don't know why it wasn't coming out. Jason

1 0

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