- Wine-Devel - list.winehq.org

RE: strcat+strcat+strcat == baaad
by Patrik Stridvall Dec. 2, 2002

Dec. 2, 2002

> I suggest implementing strlcat and strlcpy, as in OpenBSD. I > can write > them, but I'm not sure where to place them. They should either be > inlined (as in - implemented in an include file as a static > func), or in > some library that will be linked (statically, I hope). Ideas? Since the do exists on some platforms (OpenBSD and FreeBSD) the obvious place to put them would be library/port.c like any other function that doesn't exists on all platforms. Just remember to add detect in configure.ac and use the HAVE_ macro in library/port.c As for (re)writing them. Why not just borrow the source from FreeBSD or OpenBSD. They both have licenses compatible with Wine. No need to reinvent the wheel.

1 0

Adding support for xxx_test.exe all
by Francois Gouget Dec. 2, 2002

Dec. 2, 2002

When running the tests on Windows you can either do 'xxx_test.exe' which gives you a list of the available tests for this executable, or 'xxx_test.exe foo' which runs test foo, and only test foo. So I propose the following patch which makes it possible to run 'xxx_test.exe all' which runs all the tests implemented by that executable. Do others find this patch acceptable? Useful? Index: include/wine/test.h =================================================================== RCS file: /home/wine/wine/include/wine/test.h,v retrieving revision 1.7 diff -u -r1.7 test.h --- include/wine/test.h 30 Oct 2002 20:36:21 -0000 1.7 +++ include/wine/test.h 30 Nov 2002 04:46:23 -0000 @@ -319,7 +319,23 @@ if ((p = getenv( "WINETEST_REPORT_SUCCESS"))) report_success = atoi(p); if (!argv[1]) usage( argv[0] ); - return run_test(argv[1]); + if (strcmp(argv[1], "all") == 0) + { + const struct test* test; + int status=0; + + for (test = winetest_testlist; test->name; test++) + { + fprintf(stderr, "Testing %s\n", test->name); + status+=run_test(test->name); + fprintf(stderr, "\n"); + } + return (status <= 255) ? status : 255; + } + else + { + return run_test(argv[1]); + } } #endif /* WINETEST_WANT_MAIN */ -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

2 2

Wine/FF7 midi help request
by Robotech_Master Dec. 2, 2002

Dec. 2, 2002

On Tue Jun 11 2002 - 13:50:43 CDT Johan Gill wrote (as part of a discussion about midi in WINE in which FF7 was mentioned): > Done. TiMidity++-2.12.0beta as alsa sequencer client requires no > modification to wine at all, and the OSS emulation of ALSA makes the > thing transparent to WINE. Can you, or someone, please let me know how to set up wine to use this? I'm running Debian Linux; these are the versions of timidity and wine that I have: ii timidity 2.11.2-1.3 Software-only MIDI sequencer. ii wine 0.0.20021125-1 Windows Emulator (Binary Emulator) For sound, I'm using artsdsp 0.6.1 to emulate esd. I have a Soundblaster live card. On the FF7 config program, it gives me the choices Wine OSS midi out (#0) - disabled EMU10K1 midi Under "midi data" it gives me the choises General midi Soundfont midi (Creative AWE32/AWE64) Yamaha XG midi No matter what I try, in whatever combination, I get "Error opening device" and the wine console says fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403ab930,0001003c,3):stub Can someone help me out--or point me at somewhere else I can find help? Thanks. -- Chris Meadows aka | Co-moderator, rec.toys.transformers.moderated Robotech_Master | Homepage: <URL:http://www.eyrie.org/~robotech/> robotech(a)eyrie.org | And now I've started a weblog: | http://robotech_master.livejournal.com

1 0

Wine REALLY emulates Windows (was: Texture corruption in Wine)
by David D. Hagood Dec. 2, 2002

Dec. 2, 2002

I am continually amazed at how well Wine emulates Windows - for example, my recent experiences show Wine has the whole "Just re-install it, it will fix it" thing down pat! 8^> To recap the story thus far - Several months ago, I was able to play Halflife- Opposing force all the way through under Wine. Then my motherboard died, and I replaced it with an SMP mobo. I had to do some tweaks to my kernel, my X server, and to Wine to get everybody back up. But when I was done, and I went to install Halflife-Blue shift, the textures were screwed up. So were the textures in OpFor. I tried booting UMP, I tried scraping the fake Windows install and reinstalling, to no avail. Friday, I downloaded Transgamings WineX in an effort to remove a few variables from the matrix. WineX ran BlueShift and OpFor flawlessly - exonerating my X server, kernel and system. So, this morning I set about trying to find out what changed in Wine. I went back and pulled Wine as of the 20020902 tag, and rebuilt. Then I did my usual install method: rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R && make install Still had no luck with Halflife - still had corrupted textures. So, I moved my fake Windows and .wine directories out of the way, created new, empty directories, copied my old .wine/config over, re-installed the Wine default registry, and re-installed Blueshift. And it worked. OK, maybe the install had problems. I moved my new fake windows and .wine directories out of the way, and moved the old directories back. And still, it worked. All textures were fine. Note: at this point, I should have had the OLD install of Blueshift back in place, and the old registry. The very one that didn't work five paragraphs ago. So, I went to my image of the current CVS of Wine, rebuilt it, and once again did a rm /usr/local/winelibs /usr/local/include/wine /usr/local/bin/win* -R && make install. And still, it worked. In theory, I should have been back to where I started from. Except where I started from didn't work. Where I was did. Now, I am at a loss as to what could have changed from the non-working state to the working state. Like I said, Wine has the whole Windows "mysterious changes" thing down pat! But it works. As Bugs Bunny said, "I don't ask questions, I just have fun." So, I am off to kill some headcrabs. But for the life of me I don't know HOW what I did fixed it....

1 0

DIB engine
by Johan Gill Dec. 1, 2002

Dec. 1, 2002

Hi all, I've just started working on the DIB engine, FYI. -- Johan Gill, johane(a)lysator.liu.se

3 2

RE: [RFC] Wine headers
by Patrik Stridvall Dec. 1, 2002

Dec. 1, 2002

> On December 1, 2002 12:35 pm, Patrik Stridvall wrote: > > 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 those apps will be aware of the issue, and can use explicit types, > just like we're going to do in Wine. Sure, they will not be able to > use the header files directly (actually, they might by having some > compat files that are not compiled with said flag on), but I don't > think it's a big deal anyway. It's workable, A better solution would be to port the source code to the LP64 model. It is entirely possible for to support all of LP32 (Win32 and "Unix32"), LLP64 (Win64) and LP64 ("Unix64") in a sane way. I don't think it is worth the effort to support LLP64 beyond having a "-flong-int" flag to get a working version to show as a prototype that porting is indeed possible. > and Win64 will not > bother us for some time... True. Microsoft doesn't seems that eager pushing Win64 either...

1 0

RE: [RFC] Wine headers
by Patrik Stridvall Dec. 1, 2002

Dec. 1, 2002

> 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.

2 1

"not enough space in GDI heap" / forking vstlib programs
by Kjetil S. Matheussen Dec. 1, 2002

Dec. 1, 2002

Hello, as I just announced I'm developing a vst-server, that loads and runs windows vst plugins. But after loading and unloading a lot of plugins, I get lots of "err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes" errors. I understand that the cause of this error is caused by a memory leak in a windows program. However, in the vst-server, there is no way to control memory leaks in the plug-ins, as those are made by various groups and persons. So is there a way around this error. Doing a fork for each new plug-in perhaps? Is that safe? I want to do that also to avoid having a plug-in crash the vst-server. --

2 2

RE: [RFC] Wine headers
by Patrik Stridvall Dec. 1, 2002

Dec. 1, 2002

> 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.

2 1

RE: [RFC] Wine headers
by Patrik Stridvall Dec. 1, 2002

Dec. 1, 2002

> The only thing I don't like in my proposal is the win32 name, namely > the 32. I guess Win64 will go in the same namespace, as well as win16. > This is confusing. What about winxx or even better winapi? Windows uses the same header files for both Win32 and Win64. It is Win32 if _WIN32 is defined and Win64 if _WIN64 is defined. 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. So we probably should have the same include directory for Win32 and Win64. As for the name well I think I like "windows" best. > > > plus a bunch of other things (like making it easy to use other > > > headers for the Win32 API, etc). And best of all, it seems to > > > be easily implementable, no? > > > > "mv" is your friend however the CVS versioning doesn't like > it though... > > We don't have to move anything in the tree, just modify where > we install > stuff. Of course, this means that you will not be able to use > your tree > include files in all cases, but I think it's good as a start. Perhaps.

2 1