December 2002 - Wine-Devel - list.winehq.org

RE: [RFC] Wine headers

by Patrik Stridvall

> On December 1, 2002 11:36 am, Patrik Stridvall wrote: > > So that is why we "never" will support 100% Win64 source > compatibillity > > on 64bit platforms. We can (and presumably) will support a > LP64 variant > > of Win64 but it won't be 100% source compatible. > > I don't think it's nearly as bad as you make it. In the Wine sources, > we'll just use explicit types that don't depend of compiler switches, > while Winelib apps will just use the -flong-int flag, and get > what they > expect. Of course, they'll have to use our msvcrt lib instead of the > native libc, but that's largely true today anyway (for > different reasons). That solves the libc problem however compiling with -flong-int also means that it will be impossible to call other libraries, which means that it will be a little hard to use Unix specific library to have extra functionallity under Unix. But sure having a -flong-int flags is nice but it doesn't solve all problems. Perhaps would be good to push for its addition even now, it might take a few years before standard GNU C installation supports it.

Dec. 1, 2002

Re: [RFC] Wine headers

by Dimitrie O. Paun

On December 1, 2002 11:36 am, Patrik Stridvall wrote: > So that is why we "never" will support 100% Win64 source compatibillity > on 64bit platforms. We can (and presumably) will support a LP64 variant > of Win64 but it won't be 100% source compatible. I don't think it's nearly as bad as you make it. In the Wine sources, we'll just use explicit types that don't depend of compiler switches, while Winelib apps will just use the -flong-int flag, and get what they expect. Of course, they'll have to use our msvcrt lib instead of the native libc, but that's largely true today anyway (for different reasons). -- Dimi.

Dec. 1, 2002

RE: [RFC] Wine headers

by Patrik Stridvall

> On November 29, 2002 01:43 pm, Patrik Stridvall wrote: > > On 64 bit platforms we can never get 100% Win32 source compabillity > > because of compiler problems. If fact we can't get 100% > Win64 support > > either for the same reasons so I guess Wine on 64-bit platforms will > > be some kind of pseudo mode. > > Why are you saying that? What about the current difference between the > sizeof(wchar_t), it wasn't such a big deal. Can't we have other flags > in the great tradition of -fwchar-short? It is a little worse that that. The C programming langauge doesn't really specify the sizes of the various integer types. It it up to the ABI. In Win32 the only really problematic difference I the one you meantion above ie the size(wchar_t) problem. It can be "solved" as specified above with -fwchar-short. The price is that you can't call the C library "wchar" functions or for that matter any library functions that depend of wchar. Not that big deal though. In the Win64 ABI Microsoft in it infinity "wisdom" has choosen the type long to be 32 bit instead of 64 bit like in most (all?) Unix API on 64 bit platforms. The Microsoft Win64 choice is called LLP64. That is long long and pointers are 64 bit. The Unix64 choice is called LP64. That is long and pointers are 64 bits. So this means that if we add an option similar to -fwchar-short, say -flong-int or -flong-32bit or whatever we can call we can't call the any library on the platform since it would could ABI problems. :-) So that is why we "never" will support 100% Win64 source compatibillity on 64bit platforms. We can (and presumably) will support a LP64 variant of Win64 but it won't be 100% source compatible.

Dec. 1, 2002

Re: Janitorial Projects

by Dimitrie O. Paun

On November 29, 2002 03:06 pm, Francois Gouget wrote: > Now we have a way to pretty easily compile them on Windows. Here's the > procedure: > > * get the Wine source > * run ./tools/winapi/msvcmaker --no-wine > (it's a perl script so you might even be able to do it on Windows) > * make those source accessible by a Windows machine (e.g. export them > via Samba) > * load winetest.dsw in Visual C++ > * hit that build button This is too complicated. First, it requires Visual C++, which sucks. We should be able to compile the tests with MinGW, as any OSS project out there. So I would say the TODO for building the tests is as follows: * make sure we can compile them with MinGW * arrange such that we can generate _one_ executable for all tests * create script that builds them say, every few (3-5) days, tests if the executable changed (by comparing MD5 sums) from the last build, and if so, put it up for download on a site, and email the test volunteers a notification (containing the URL) that the tests have changed, and they should retest. The URL should be fixed (e.g. http://www.corp.com/wine/wine-tests.exe) so the tester can bookmark it, write scripts against it, etc. * enlist a volunteer to run said script on a regular basis. As it stands, the tests have to do way too much work for this to have a snowball's chance in hell of working long term. Don't forget that the testers need to worry of a different box, etc. which is already enough work. The rest can be automated, as I just described. -- Dimi.

Dec. 1, 2002

Re: [RFC] Wine headers

by Dimitrie O. Paun

On November 29, 2002 01:43 pm, Patrik Stridvall wrote: > On 64 bit platforms we can never get 100% Win32 source compabillity > because of compiler problems. If fact we can't get 100% Win64 support > either for the same reasons so I guess Wine on 64-bit platforms will > be some kind of pseudo mode. Why are you saying that? What about the current difference between the sizeof(wchar_t), it wasn't such a big deal. Can't we have other flags in the great tradition of -fwchar-short? -- Dimi.

Dec. 1, 2002

Re: Fwd: Re: [putty]Winelib support + patch

by Dimitrie O. Paun

On November 29, 2002 02:45 pm, Francois Gouget wrote: > If you modify wine itself then you should be able to remove the wrapper. > However, how will you instruct Wine to load just the right libraries? We already have a wrapper for the .exe.so, we can pass in some flags. Something like --preload ntdll,kernel,user,gdi,... Of course, the ideal fix is if wine canfigure things out automatically from the .exe.so file. Since we are going to have that link script sooner or later, what about we store this information in a ELF section, and get it from there before dlopening the file? BTW, how hard would be to get to such a section? > But you cannot create trampolines for variables. No, but I guess you can trigger a segfault, and do the fixup in the signal handler. But regardless, how does Windows deal with this? How come it works there, and not under Wine? -- Dimi.

Dec. 1, 2002

Re: Texture problems under Wine - more info

by David D. Hagood

Lionel Ulmer wrote: > '> This begs the question: > > Does the Linux implementation of pthread really work anyway? Considering that about 2 months ago, I was able to play HalfLife Opposing Force all the way through under Wine, I doubt the pthread emulation is a problem. > > By the way, what drivers are you using ? > XFree86 DRI for Radeon 7500 (r100 driver) from CVS. I haven't had time to begin regressing the OpenGL shim under Wine, as this weekend has been rather busy doing other things, but as I get time I will begin doing so.

Dec. 1, 2002

Re: SetWindowHookEx

by Shachar Shemesh

Hi all, I just found out that the version I posted on the web was an old one. Some of the bugs there were purely visual, but there is a serious problem with the shared memory creation there that causes it not to work on Windows 98. Since I also have the new version, I have updated the link with the new version. My appologies. http://www.consumer.org.il/personal/xeyes.zip As before, treat this as a GPL program. Shachar Shachar Shemesh wrote: > I sent Alexandre the App privately. I originally wanted to CC the list > (the app can be distributed under either GPL or LGPL), but the mail > was rejected. I would hereby like to appologize for trying to attach > more than the set limit of 40Kb of a zip file to the list. My appologies. > > In leu of such atrocities which I would not like to commit, and I > would like to thank the moderator for stopping that mail, I have > placed on a web site, and am hereby making both source and a compiled > binary available in a zip file (no wonder it was more than 40Kb, what > was I thinking trying to send it to the list) at > http://www.consumer.org.il/personal/xeyes.zip. > > D/L size is 49Kb. > > Thanks, > Shachar > > > Alexandre Julliard wrote: > >> Shachar Shemesh <wine-devel(a)sun.consumer.org.il> writes: >> >> >> >>> So you mean to say that my windows X-Eyes implementation won't work on >>> WINE????? Damn. >>> >>> Anyone knows of any Unix port of that program? >>> >>> Shachar >>> >>> No, wait. I'm using a mouse hook. Maybe it'll work after all. >>> >> >> >> At this point probably not, but if you could send me that app I'd be >> interested to play with it. >> >> >> > > > >

Dec. 1, 2002

Re: strcat+strcat+strcat == baaad

by Shachar Shemesh

Alexandre Julliard wrote: >Francois Gouget <fgouget(a)free.fr> writes: > > >Well, no, the cost is linear. It would only be quadratic if the number >of strcat calls depended on the length of the string. > > Well - still snprintf is more efficient. > > >>It's more efficient to do: >> >> sprintf(foo, "%s%s%s%s%s%s", bar1,bar2,bar3,bar4,bar5,bar6); >> >> > >I seriously doubt that sprintf would be faster that a couple of >strcats. And I don't think we need to worry about this kind of >micro-optimizations right now... > > But there is also no reason not to welcome these submissions if someone already took the time to submit them. Shachar

Dec. 1, 2002

Compilation with -DSTRICT

by Thomas Wickline

Hello, I just want to say Thank you to all the people who put work into the Compilation with -DSTRICT Tom

Dec. 1, 2002

Programs to test D3D

by J C

Hi all, I've been following the recent work on D3D and decided I would give a couple of benchmarks/demos I had around a go. Pleasantly I found that they actually start up now and display some stuff on screen! Before the recent patches they would fail completely when starting the actual D3D stuff. I'm not sure if you're aware of these programs or not but I figured I would pass on the URLs to you as they might be of help. This first is a demo called Bleam: http://www.bluespoon.com/banjoh/ This page has a binary of the demo and source code as well. The second is an older benchmark/demo called Tirtanium: http://www.tirtanium.de/prog3d.html The homepage doesnt seem to have the binary anymore so here's a direct link to a mirror: http://public.planetmirror.com/pub/3dfiles/tweakfiles/benchmark/tirta190.zip Both display stuff on screen and will run through to the end with no crashes. Justin Chevrier PS. Great work guys! _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

Nov. 30, 2002

Re: strcat+strcat+strcat == baaad

by Jeremy White

> > It's really inefficient: the cost increases quadratically with the size > > of the resulting string. > > Well, no, the cost is linear. It would only be quadratic if the number > of strcat calls depended on the length of the string. > > > It's more efficient to do: > > > > sprintf(foo, "%s%s%s%s%s%s", bar1,bar2,bar3,bar4,bar5,bar6); > While I agree with Alexandre that the argument for this change based on efficiency is not compelling, I find the resulting clarity of code refreshing. And perhaps it's not our top priority, but I think if we can encourage folks to tighten the code, that would be a Good Thing (TM).

Nov. 30, 2002