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

Problems converting DLL to unix SO with winelib

by List vmn

Hello Wine-devel, I finaly got the expected results from my simple tests to get a winelib DLL and test application to work. I am pretty sure that I am still doing something wrong in these tests !!!!! Can somebody say if the below setup is correct and if not what would be the correct way to create a winelib "dll" and then call it from a winelib executable. I am using wine-20020509. =>I start with a simple DLL file called mytest.c and use winemaker to create a libmytest.so bash#cd ~/mytest.dll bash#ls mytest.c bash#cat mytest.c //mytest.c #include <windows.h> #include <stdio.h> BOOL APIENTRY DllMain(HINSTANCE hinstDLL , DWORD fdwReason, LPVOID lpvReserved ) { printf("DllMain called\n"); return TRUE; } void usefullFunction() { printf("Usefull function got called\n"); } //end of mytest.c bash#winemaker --dll --nomfc . <output suppressed> bash#cat libmytest.spec name mytest type win32 mode dll init DllMain import kernel32.dll import ntdll.dll bash# ./configure <output suppressed> bash# make && make install gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o mytest.o mytest.c ld -r mytest.o -o libmytest.tmp.o strip --strip-unneeded libmytest.tmp.o LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -L/usr/local/lib/wine -sym libmytest.tmp.o -o libmytest.spec.c -spec ./libmytest.spec gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o libmytest.spec.o libmytest.spec.c gcc -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o libmytest.so mytest.o libmytest.spec.o -lwine -lwine_unicode -lwine_uuid -lm _list=""; for i in $_list; do (cd $i; make install) || exit 1; done _list=" "; for i in $_list; do install $i /usr/local/bin; done _list="libmytest.so"; for i in $_list; do install $i /usr/local/lib; done bash# #Now I have a /usr/local/lib/libmytest.so file \ #I think the next commands are wrong... bash# cd /usr/local/lib bash# cp libmytest.so wine/mytest.dll.so bash# ln -s wine/mytest.dll.so libmytest.dll.so bash# #This was done so that I can write \ # import mytest.dll \ # in a spec file and "register with wine" this so =>I now create a simple winelib application to call mytest called "callmytest" =>Call my test is defined in callmytest.c bash# cd ~/callmytest bash#ls callmytest.c bash# cat callmytest.c //start of callmytest.c #include "windows.h" extern usefullFunction(); int WINAPI WinMain(HINSTANCE a,HINSTANCE b,LPSTR c ,int d) { usefullFunction(); } //end of callmytest.c bash# winemaker --guiexe -imytest.dll -lmytest.dll . <output suppressed> bash# cat callmytest.spec name callmytest type win32 mode guiexe init WinMain import kernel32.dll import ntdll.dll import mytest.dll bash# ./configure <output suppressed> bash# make gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o callmytest.o callmytest.c ld -r callmytest.o -o callmytest.tmp.o strip --strip-unneeded callmytest.tmp.o LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -L/usr/local/lib/wine -sym callmytest.tmp.o -o callmytest.spec.c -spec ./callmytest.spec gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o callmytest.spec.o callmytest.spec.c gcc -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o callmytest.so callmytest.o callmytest.spec.o -lmytest.dll -lwine -lwine_unicode -lwine_uuid -lm test -f callmytest || ln -s /usr/local/bin/wine callmytest bash# ./callmytest DllMain called Usefull function got called DllMain called QUESTION 1: I think that adding -imytest.dll -lmytest.dll to winemaker --guiexe -imytest.dll -lmytest.dll . is wrong. QUESTION 2: Is DllMain called when the DLL is loaded and then unloaded ? Can anyone help me on this? Thanks, Miguel Feitosa

June 11, 2002

Problems converting DLL to unix SO with winelib

by mfeitosa

Hello Wine-devel, I finaly got the expected results from my simple tests to get a winelib DLL and test application to work. I am pretty sure that I am still doing something wrong in these tests !!!!! Can somebody say if the below setup is correct and if not what would be the correct way to create a winelib "dll" and then call it from a winelib executable. I am using wine-20020509. =>I start with a simple DLL file called mytest.c and use winemaker to create a libmytest.so bash#cd ~/mytest.dll bash#ls mytest.c bash#cat mytest.c //mytest.c #include <windows.h> #include <stdio.h> BOOL APIENTRY DllMain(HINSTANCE hinstDLL , DWORD fdwReason, LPVOID lpvReserved ) { printf("DllMain called\n"); return TRUE; } void usefullFunction() { printf("Usefull function got called\n"); } //end of mytest.c bash#winemaker --dll --nomfc . <output suppressed> bash#cat libmytest.spec name mytest type win32 mode dll init DllMain import kernel32.dll import ntdll.dll bash# ./configure <output suppressed> bash# make && make install gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o mytest.o mytest.c ld -r mytest.o -o libmytest.tmp.o strip --strip-unneeded libmytest.tmp.o LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -L/usr/local/lib/wine -sym libmytest.tmp.o -o libmytest.spec.c -spec ./libmytest.spec gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o libmytest.spec.o libmytest.spec.c gcc -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o libmytest.so mytest.o libmytest.spec.o -lwine -lwine_unicode -lwine_uuid -lm _list=""; for i in $_list; do (cd $i; make install) || exit 1; done _list=" "; for i in $_list; do install $i /usr/local/bin; done _list="libmytest.so"; for i in $_list; do install $i /usr/local/lib; done bash# #Now I have a /usr/local/lib/libmytest.so file \ #I think the next commands are wrong... bash# cd /usr/local/lib bash# cp libmytest.so wine/mytest.dll.so bash# ln -s wine/mytest.dll.so libmytest.dll.so bash# #This was done so that I can write \ # import mytest.dll \ # in a spec file and "register with wine" this so =>I now create a simple winelib application to call mytest called "callmytest" =>Call my test is defined in callmytest.c bash# cd ~/callmytest bash#ls callmytest.c bash# cat callmytest.c //start of callmytest.c #include "windows.h" extern usefullFunction(); int WINAPI WinMain(HINSTANCE a,HINSTANCE b,LPSTR c ,int d) { usefullFunction(); } //end of callmytest.c bash# winemaker --guiexe -imytest.dll -lmytest.dll . <output suppressed> bash# cat callmytest.spec name callmytest type win32 mode guiexe init WinMain import kernel32.dll import ntdll.dll import mytest.dll bash# ./configure <output suppressed> bash# make gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o callmytest.o callmytest.c ld -r callmytest.o -o callmytest.tmp.o strip --strip-unneeded callmytest.tmp.o LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -L/usr/local/lib/wine -sym callmytest.tmp.o -o callmytest.spec.c -spec ./callmytest.spec gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o callmytest.spec.o callmytest.spec.c gcc -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o callmytest.so callmytest.o callmytest.spec.o -lmytest.dll -lwine -lwine_unicode -lwine_uuid -lm test -f callmytest || ln -s /usr/local/bin/wine callmytest bash# ./callmytest DllMain called Usefull function got called DllMain called QUESTION 1: I think that adding -imytest.dll -lmytest.dll to winemaker --guiexe -imytest.dll -lmytest.dll . is wrong. QUESTION 2: Is DllMain called when the DLL is loaded and then unloaded ? Can anyone help me on this? Thanks, Miguel Feitosa

June 11, 2002

RE: Linux patch for supporting shortcuts and symlinks on VFAT

by Patrik Stridvall

> On Tue, 11 Jun 2002, Patrik Stridvall wrote: > [...] > > However it would be nice be nice to handle .lnk files as symlinks > > somehow. > > I'm not sure this is very useful, Well, just a feeling, but I have always been irritated about that the .lnk files are not real symlinks. Wine is not only supposed to be as good as Windows but also better if possible. > especially since few > symlinks will be > supported in any case. For instance in his proposal he ignores: > * all symlinks to absolute paths. That would be pretty much all > symlinks created under windows Yes. However you could have a drive table like echo /windows-c-drive > /proc/windows/drive/c echo /windows-d-drive > /proc/windows/drive/d So the kernel could do the look up. BTW this would also means that Wine could read /proc/windows/drive and map the drives. > * all UNC symlinks except those to \\localhost. But don't these paths > have a drive letter too? Even worse they have the first part after \\localhost should be the name of the share so that means that we need to have a series of /proc/windows/share directories or something as well... > * I guess he would also ignore the command line options > specified in shortcuts to executables > * and also the current directory Hmm. Well, that is a problem as well. Perhaps you could link to some sort of autogenerated shell script in /proc/windows/links say you access /mnt/c/test.lnk and you get a shell script in /proc/windows/links/mnt/c/test.lnk or something that /mnt/c/test.lnk symlinks to. > * and the icon of course. Which then means tools like konqueror or > nautilus cannot extract the icon either unless they make use of the > proposed ioctl hack. I don't consider this a problem. However solving the other problem is probably to ugly eventhough they are solvable in some meaning. > And if the goal is to be able to create symlinks on a filesystem that > does not support them, I believe the right way to do so would > be to have > a module sit on top of the file system that would do things > ala umsdos. > This would for instance allow one to also get things like ownership, > file permissions, device files, socket files, etc. And if you > are going > to use a VFAT filesystem as a regular Unix filesystem, having > permissions at least while in Linux seems like it would be a very good > thing. Indeed. It would be better if it was generalized somehow. Hmm... > > > * on Windows if you open("foo.lnk") you get the .lnk > files, not the > > > file it 'points' to. On Linux you would get the file it points to > > > instead which is a different behavior. > > > > True. However we could check if the extension is .lnk in OpenFile > > as friends and then call special funcitons like readlink to read the > > file. But it probably would be a too ugly hack to be worth it. > > Yes that's the soluti^H^H^H^H ugly hack that was suggested as a > workaround. It would probably involve an ioctl of some sort > though here > we are talking about reading the content of a file, not just > a couple of > metadata bits, not sure how ioctls handle such things (maybe > that's not > a problem, I'm not very familiar with ioctls). Doing it is not the problem. Accepting the overhead and the ugly hack is the real problem... > The other issue is that this workaround is not implemented > yet so we may > get stuck in a bad place for a while. True. > [...] > > Anyway, the big question seem to be whether we should > oppose the patch > > or not. It might could trouble for Wine is such a feature > exists some > > user might active it so we have to handle that case. > > It is proposed as the default behavior. This means it would likely end > up as the default in most distributions, so many users will > be hit by it > even if they did not activate it. > > I definitely oppose it. I believe it is not only harmful to Wine, but > also the wrong thing for Linux. As the default behavior I also oppose it. Unfortunely I very much fear that I won't be possible to do it in an acceptable way at all...

June 11, 2002

RE: Linux patch for supporting shortcuts and symlinks on VFAT

by Francois Gouget

On Tue, 11 Jun 2002, Patrik Stridvall wrote: [...] > However it would be nice be nice to handle .lnk files as symlinks > somehow. I'm not sure this is very useful, especially since few symlinks will be supported in any case. For instance in his proposal he ignores: * all symlinks to absolute paths. That would be pretty much all symlinks created under windows * all UNC symlinks except those to \\localhost. But don't these paths have a drive letter too? * I guess he would also ignore the command line options specified in shortcuts to executables * and also the current directory * and the icon of course. Which then means tools like konqueror or nautilus cannot extract the icon either unless they make use of the proposed ioctl hack. And if the goal is to be able to create symlinks on a filesystem that does not support them, I believe the right way to do so would be to have a module sit on top of the file system that would do things ala umsdos. This would for instance allow one to also get things like ownership, file permissions, device files, socket files, etc. And if you are going to use a VFAT filesystem as a regular Unix filesystem, having permissions at least while in Linux seems like it would be a very good thing. > > * on Windows if you open("foo.lnk") you get the .lnk files, not the > > file it 'points' to. On Linux you would get the file it points to > > instead which is a different behavior. > > True. However we could check if the extension is .lnk in OpenFile > as friends and then call special funcitons like readlink to read the > file. But it probably would be a too ugly hack to be worth it. Yes that's the soluti^H^H^H^H ugly hack that was suggested as a workaround. It would probably involve an ioctl of some sort though here we are talking about reading the content of a file, not just a couple of metadata bits, not sure how ioctls handle such things (maybe that's not a problem, I'm not very familiar with ioctls). The other issue is that this workaround is not implemented yet so we may get stuck in a bad place for a while. [...] > Anyway, the big question seem to be whether we should oppose the patch > or not. It might could trouble for Wine is such a feature exists some > user might active it so we have to handle that case. It is proposed as the default behavior. This means it would likely end up as the default in most distributions, so many users will be hit by it even if they did not activate it. I definitely oppose it. I believe it is not only harmful to Wine, but also the wrong thing for Linux. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

June 11, 2002

RE: Linux patch for supporting shortcuts and symlinks on VFAT

by Patrik Stridvall

> On Tue, 11 Jun 2002, Patrik Stridvall wrote: > > > I notice that I patch have been posted to the linux-kernel that > > might be of intrest to us. > > > > vfat patch for shortcut display as symlinks for 2.4.18 > > http://marc.theaimsgroup.com/?l=linux-kernel&m=102358795411222&w=2 > > > > It seem that at least some people are against it inclusion so I > > wonder whether we should support inclusion of the patch or not. > > > > I'm personally a little doubtful that it is a good idea... > > > I think it's a bad idea. The reason is that the VFAT driver > is the wrong > abstraction layer to support the '.lnk' files: Probably. The more I think about the more I worry about the consequences. However it would be nice be nice to handle .lnk files as symlinks somehow. > * on Windows if you open("foo.lnk") you get the .lnk files, not the > file it 'points' to. On Linux you would get the file it points to > instead which is a different behavior. True. However we could check if the extension is .lnk in OpenFile as friends and then call special funcitons like readlink to read the file. But it probably would be a too ugly hack to be worth it. > * Windows supports .lnk files on FAT, VFAT, NTFS, ISO9660, etc. So if > such support is added in the Linux kernel, it should be added > to all of > the above filesystems. And then there is no reason not to add it to > ext2, NFS, etc! True. The feature should probably be at file system independant layer, if anywhere. > This would also hurt Wine as: > > * it would prevent us from reading the information in the '.lnk' > file... at least for 'supported' '.lnk' files Well, as I said above, we can read them with readlink and friends. > * it's not entirely clear to me what they do with unsupported '.lnk' > files. Are they just dead symlinks or can one read their contents? In > the first case Wine is SOL again, and in the latter case we'll have to > play games to know which kind we got. As I said, you always can read a symlinks content with readlink. > * it was suggested to implement a hack to let Wine access the '.lnk' > data. Why implement a hack which is going to be Linux specific when > doing nothing works just fine and on any Unix system? True. > * making it a default option does not help Wine at all. Then > we have to > keep telling users that they have to modify their fstab if they want > Wine to work. Yes, that is a problem. See below. > The right level to implement symlink support is: > > * in Wine. Of course! :-) > * in an LD_PRELOAD library. Then they would work for all filesystems, > be selectable on a per-user or even per-process basis. Of course it > would most likely not work with Wine (ld_preload libraries seldom do). > > * as an option in the KDE/Gnome file browsers. That's the layer which > seems closest to the Windows shell 'layer'. True. Anyway, the big question seem to be whether we should oppose the patch or not. It might could trouble for Wine is such a feature exists some user might active it so we have to handle that case. BTW. I just though of another thing. Perhaps we should support the opposite. Translate existing symlinks to .lnk files? > This looks like it could be the next 'unhide' thing. hmmm, probably, > people not subscribed to linux-kernel missed the 'unhide' issue. See: > * Jeremy White - isofs unhide option: troubles with Wine > http://marc.theaimsgroup.com/?l=linux-kernel&m=102230123607864&w=2 I basicly agree with your opinion. The hidden attribute is metadata meant as advice for the application not something the operating system should concern itself.

June 11, 2002

Re: Linux patch for supporting shortcuts and symlinks on VFAT

by Francois Gouget

On Tue, 11 Jun 2002, Patrik Stridvall wrote: > I notice that I patch have been posted to the linux-kernel that > might be of intrest to us. > > vfat patch for shortcut display as symlinks for 2.4.18 > http://marc.theaimsgroup.com/?l=linux-kernel&m=102358795411222&w=2 > > It seem that at least some people are against it inclusion so I > wonder whether we should support inclusion of the patch or not. > > I'm personally a little doubtful that it is a good idea... I think it's a bad idea. The reason is that the VFAT driver is the wrong abstraction layer to support the '.lnk' files: * on Windows if you open("foo.lnk") you get the .lnk files, not the file it 'points' to. On Linux you would get the file it points to instead which is a different behavior. * Windows supports .lnk files on FAT, VFAT, NTFS, ISO9660, etc. So if such support is added in the Linux kernel, it should be added to all of the above filesystems. And then there is no reason not to add it to ext2, NFS, etc! This would also hurt Wine as: * it would prevent us from reading the information in the '.lnk' file... at least for 'supported' '.lnk' files * it's not entirely clear to me what they do with unsupported '.lnk' files. Are they just dead symlinks or can one read their contents? In the first case Wine is SOL again, and in the latter case we'll have to play games to know which kind we got. * it was suggested to implement a hack to let Wine access the '.lnk' data. Why implement a hack which is going to be Linux specific when doing nothing works just fine and on any Unix system? * making it a default option does not help Wine at all. Then we have to keep telling users that they have to modify their fstab if they want Wine to work. The right level to implement symlink support is: * in Wine. Of course! * in an LD_PRELOAD library. Then they would work for all filesystems, be selectable on a per-user or even per-process basis. Of course it would most likely not work with Wine (ld_preload libraries seldom do). * as an option in the KDE/Gnome file browsers. That's the layer which seems closest to the Windows shell 'layer'. This looks like it could be the next 'unhide' thing. hmmm, probably, people not subscribed to linux-kernel missed the 'unhide' issue. See: * Jeremy White - isofs unhide option: troubles with Wine http://marc.theaimsgroup.com/?l=linux-kernel&m=102230123607864&w=2 -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

June 11, 2002

locale tests failed

by Sylvain Petreolle

../../programs/winetest/runtest -q -P wine -M kernel32.dll -T ../.. -p tests/kernel32_test.exe.so tests/locale.c && touch tests/locale.ok fixme:string:OLE_GetFormatA datelen = 0, returning 255 fixme:string:OLE_GetFormatA datelen = 0, returning 255 tests/locale.c:260: Test failed: GetNumberFormat with len=2 got 2 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx instead of 2,xx tests/locale.c:269: Test failed: GetNumberFormat got 2 353,00 instead of 2,353.00 tests/locale.c:214: Test failed: GetCurrencyFormat with len=0: got 8 instead of 7 tests/locale.c:219: Test failed: GetCurrencyFormat got 23xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx instead of $23.53 tests/locale.c:226: Test failed: GetCurrencyFormat got 23,53 ¤ instead of $23.53 tests/locale.c:227: Test failed: GetCurrencyFormat: got 8 instead of 7 make[2]: *** [tests/locale.ok] Erreur 6 make[2]: Quitte le répertoire `/home/wine/dlls/kernel' make[1]: *** [kernel/__test__] Erreur 2 make[1]: Quitte le répertoire `/home/wine/dlls' make: *** [dlls/__test__] Erreur 2 LANG is set to fr_FR, and the '¤' is, I think, the euro symbol.test is ok when LANG is set to en_US for example. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

June 11, 2002

Linux patch for supporting shortcuts and symlinks on VFAT

by Patrik Stridvall

I notice that I patch have been posted to the linux-kernel that might be of intrest to us. vfat patch for shortcut display as symlinks for 2.4.18 http://marc.theaimsgroup.com/?l=linux-kernel&m=102358795411222&w=2 It seem that at least some people are against it inclusion so I wonder whether we should support inclusion of the patch or not. I'm personally a little doubtful that it is a good idea... Comments?

June 11, 2002

Re: GLU32 patch

by Marcus Meissner

On Mon, Jun 10, 2002 at 11:52:34PM -0400, Vincent B?ron wrote: > The glu32 dll is now compliant with MSDN. It can be compiled with a > libGLU 1.1, but preferably by a libGLU 1.2. > > Changelog: > - Modified the glu32 prototypes to match MSDN. > - Made it work for libGLU 1.1 and 1.2. ... > -@ stdcall gluCheckExtension(str ptr) wine_gluCheckExtension Why is this function gone? And you will need to add checks for glu.h in configure.ac too. Ciao, Marcus

June 11, 2002

Re: GLU32 status & update

by Marcus Meissner

On Mon, Jun 10, 2002 at 08:18:38PM -0400, Vincent B?ron wrote: > After investigating bug #783 (Wine20020605: Problems with build of > dlls/glu32), here are my conclusions so far (not finished yet, but I > need a bit of advice on next direction to pursue): > > First, we need to not compile glu32 is no libGLU.so is found. The test > for libGLU is already in configure, the only thing missing is some logic > in the dlls/Makefile (or maybe dlls/glu32/Makefile?) to not build it. The code is of course already there for this. Check dlls/Makefile.in, and mentions of 'GLU32FILES' in configure.ac, which does not recurse into dlls/glu32 if libGLU.so is not there. So the bug reporter, as you already found, did a 'cd dlls/glu32' and built it himself, which is of course not supported. Ciao, Marcus

June 11, 2002

Re: bugs.winehq.com upgraded

by Jeremy Newman

Yes it does. I just have not at this point given anyone permissions to add/edit keywords. On Mon, 2002-06-10 at 22:04, Tony Lambregts wrote: > Jeremy Newman wrote: > > >I have *finally* gotten around to upgrading our Bugzilla. We are now > >running version 2.14.2. > Great. Does this version include the keyword field? > > Tony Lambregts > -- __ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

June 11, 2002

Re: bugs.winehq.com upgraded

by Tony Lambregts

Jeremy Newman wrote: >Yes it does. I just have not at this point given anyone permissions to >add/edit keywords. > > In that case I would like to suggest three keywords right now. The first is Regression (or something like it) for bugs relating to programs that were working at one time but stoped working for some reason. The second is Download (or something like it) for bugs relating to programs that have a downloadable version. The third keyword I would like to see is Source (or something like it) for bugs relating to programs where the sourse code is available. Any Comments? Tony Lambregts

June 11, 2002

Re: bugs.winehq.com upgraded

by Tony Lambregts

Jeremy Newman wrote: >I have *finally* gotten around to upgrading our Bugzilla. We are now >running version 2.14.2. > >This build seems to solve some long overdue usability complaints. One of >the big differences I noticed is that there is levels of "Resolved" now. > >If you notice any issues with the new bugzilla, please submit issues >about it to the "Bugzilla" product. > > > > Great. Does this version include the keyword field? Tony Lambregts

June 11, 2002

GLU32 status & update

by Vincent Béron

After investigating bug #783 (Wine20020605: Problems with build of dlls/glu32), here are my conclusions so far (not finished yet, but I need a bit of advice on next direction to pursue): First, we need to not compile glu32 is no libGLU.so is found. The test for libGLU is already in configure, the only thing missing is some logic in the dlls/Makefile (or maybe dlls/glu32/Makefile?) to not build it. Next, the version of the GLU implementation of MS is 1.2. That's fine as long as the same (or more recent) version is found while building. I'm currently using Mesa 3.4.2 on RH 7.2, which is GLU 1.1 compliant. The GL/glu.h has the defines for 1.2 and 1.3, but the lib/libGLU.so doesn't have any implementation. Some more recent distributions (eg, RH 7.3) has the SGI GLU implementation which is 1.3. So we need to check this also. What would be the best thing to do if the native GLU is < 1.2? Not build dlls/glu32 at all? There's a way to map 1.1 call to 1.2 or beyond, but not the other way around (or I'm not aware of it). I finished correcting the prototypes (compliant with MSDN) in glu.c for a native GLU 1.2. Now I'd like to have some input as to what to do wrt a native GLU 1.1. If you have some advice, I'll appreciate them. Vincent

June 11, 2002

tabctl32.ocx

by Medland, Bill

Anyone any ideas? Our application basically results in running an OLE container which loads Visual Basic ocx's, some of which use the TABCTL32.OCX tab control. However the TABCTL32.OCX doesn't "load" in some way. (If I put a Debug MessageBox into the Visual Basic I get "Failed to load control 'SSTab' from TABCTL32.OCX." I have done a relay trace to see what happens between the end of the OCX's init routine (which succeeds) and the message and there is no obvious complaint. (This is with native ole32, oleaut and rpcrt4) Bill

June 10, 2002

debug channels

by max

I just finished coding a front-end for wine, that parses on the fly all wine logs and display only selected ones; logs are selectable by class and channel. I'd like to post it, but there's a probem yet : the parser, for speed purposes, works line-by-line, looking for strings of kind 080ee030:trace:win32:_EnterSysLevel (0x4070e558, level 2): ................ 080ee030:trace:win32:_EnterSysLevel (0x4070e558, level 2): ............... 080ee030:trace:win32:_LeaveSysLevel (0x4070e558, level 2): ............. so, for strings containing an optional adress field, a colon, a class name, a colon and a channel name. It can't obviously understand multi-line outputs like this one : 080ee030:warn:heap:HEAP_ValidateInUseArena Heap 40a60000: ............ Heap: 40a60000 Next: 65430000 Sub-heaps: 40a60000 Free lists: Block Stat Size Id 40a60038 free 00000001 prev=40a606bc next=40a6004c 40a6004c free 00000001 prev=40a60038 next=40a60060 because of lack of :CLASS:CHANNEL: markers. Would it be possible to patch debug channel code to add it on beginning (or after address field) of EACH output line, instead of only first line of multiline output ? Regards Max

June 10, 2002

Re: Lotus Notes R5 devel

by Andreas Mohr

Hi ! On Fri, Jun 07, 2002 at 05:52:48AM -0700, JJ Neff wrote: > I am a NON-Programmer (very few C C++ classes some time ago:-) I read that > regulr Notes users are needed. I have been trying to run Notes with verying > success for some time. I am a Notes Admin and have had some success with R5 > under Wine. I run Debian unstable and use daily build Wine debs from > gluck.debian.org. > > I regularly use IRC to get assistance or to try to troubleshoot. PLease let me > knwo how I can best help Cool ! Finally someone who's offering help ! You might want to get in touch with Daniel Schwarz <dschwarz(a)bellatlantic.net>. He's been very close to Notes development, and he volunteered to do the application owner thing. As Notes is an incredibly important application (we just had lotsa inquiries on our Linuxtag fair !), having at least two people take care about it is definitely great help. Your job would be to make sure it runs properly, that there are no regressions that need to be fixed again, and also to make sure that people feel good running Notes on Wine ;-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

June 10, 2002

Re: Error messages when typing Hebrew characters

by Shachar Shemesh

Dmitry Timoshkov wrote: >"Shachar Shemesh" <wine-devel(a)sun.consumer.org.il> wrote: > > > >>Ok, I found the problem with the kind help of the Ivrix mailing list guys. >> >>The problem was that the locales were not installed (none of them). I >>installed the locales and presto - everything started to work. Thanks >>for everyone here for helping out. >> >> > >Shachar, could you please provide an URL or the whole description of >the steps required to correctly setup Hebrew locale support in Linux >(for archival purposes)? > >Thanks in advance. > > > http://ivrix.org.il/mailing-lists/ivrix-discuss/2002/06/ All I had to do (I am using Debian) is 'apt-get install locales', and selecting the he_IL locale (not necessarily as default). Other distros will likely have somewhat different instructions. Shachar

June 10, 2002

Re: Crash with "privileged instruction in 16-bit code"

by Andreas Mohr

On Mon, Jun 10, 2002 at 09:58:27AM -0700, Andriy Palamarchuk wrote: > An app crashes with this message. Described in the bug > 768: > http://bugs.winehq.com/show_bug.cgi?id=768 > > Does anybody want to look at it? [...] > Unhandled exception: privileged instruction in 16-bit > code (034f:49f0). > Symbol __strtol_internal is invalid > 0x034f:0x49f0: pushw %es:0x4(%bx) > > Wine-dbg>info reg > CS:034f SS:0a27 DS:0a27 ES:0000 FS:0000 GS:0000 > IP:49f0 SP:90a0 BP:932c FLAGS:0206( - 00 I - > -P1 ) Sounds like ES:BX is a NULL pointer (you forgot to list BX, though). And as ES == NULL == evil, this results in a privileged instruction exception. Try to find out where the NULL pointer comes from via relay trace or by walking the function backtrace (checking where ES:BX gets loaded and where this memory location or register gets its value from). -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

June 10, 2002

bugs.winehq.com upgraded

by Jeremy Newman

I have *finally* gotten around to upgrading our Bugzilla. We are now running version 2.14.2. This build seems to solve some long overdue usability complaints. One of the big differences I noticed is that there is levels of "Resolved" now. If you notice any issues with the new bugzilla, please submit issues about it to the "Bugzilla" product. -- __ _WebGeek/NetAdmin CodeWeavers -= http://www.codeweavers.com | \| |_____ __ ___ __ __ _ _ _ -= http://www.dracowulf.com | .` / -_) | | / ' \/ _` | ' \ -= mailto:jnewman(a)codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

June 10, 2002

Crash with "privileged instruction in 16-bit code"

by Andriy Palamarchuk

An app crashes with this message. Described in the bug 768: http://bugs.winehq.com/show_bug.cgi?id=768 Does anybody want to look at it? Information from debugger below: ***************************************** Unhandled exception: privileged instruction in 16-bit code (034f:49f0). Symbol __strtol_internal is invalid 0x034f:0x49f0: pushw %es:0x4(%bx) Backtrace: =>0 0x034f:0x49f0 (bp=932c) 1 0x0317:0x3fb7 (bp=9344, far call assumed) 2 0x09b7:0x22f9 (bp=9430, far call assumed) 3 0x0317:0x1f4e (bp=944a, far call assumed) 4 0x02d7:0x421b (bp=9460, far call assumed) 5 0x02d7:0x4405 (bp=9486) 6 0x0327:0x3652 (bp=95aa, far call assumed) 7 0x0327:0x3013 (bp=9612) 8 0x02d7:0x421b (bp=9628, far call assumed) 9 0x0307:0x31cd (bp=964a, far call assumed) 10 0x0957:0x3ac8 (bp=969e, far call assumed) 11 0x0977:0x4e5b (bp=96b6, far call assumed) 12 0x0297:0xc789 (bp=96c8, far call assumed) 13 0x0297:0x40ca (bp=0000) Wine-dbg>info reg CS:034f SS:0a27 DS:0a27 ES:0000 FS:0000 GS:0000 IP:49f0 SP:90a0 BP:932c FLAGS:0206( - 00 I - -P1 ) ***************************************** Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 10, 2002

Re: FPU patch for bug 586

by Ove Kaaven

On Mon, 10 Jun 2002, admiral coeyman wrote: > This patch adds the self-modifying code part of the FPU interrupts 34->3b and > moves int 3d into the winedos section. Oh, I've been meaning to reply, but hadn't got around to it yet... it makes no sense to use MapDosToLinear(MapRealToLinear()). It should be obvious from its name that MapRealToLinear already converted to a linear address, so that's all you need. And MapLinearToDos will probably *not* do what you want, you should change the real-mode pointer directly instead, as in general you just can't convert a linear address back to real mode. Otherwise, the code is probably OK...

June 10, 2002

Re: Return value of fileio_get_async_count

by Martin Wilck

Am Mon, 2002-06-10 um 04.26 schrieb Vincent Béron: > Could you have a look at the last line of fileio_get_async_count? It > seems gcc -W says the test always has the same outcome. It has been > reported as bug #778. Yeah, DWORD is an unsigned type. The patch below should fix it. Actually, if we trust our own implementation of read and write, we might as well drop that case distinction altogether and simply return fileio->count - fileio->lpOverlapped->InternalHigh. Martin --- files/file.c.orig Mon Jun 10 12:52:00 2002 +++ files/file.c Mon Jun 10 12:59:11 2002 @@ -131,8 +131,8 @@ static DWORD fileio_get_async_count (const struct async_private *ovp) { async_fileio *fileio = (async_fileio*) ovp; - DWORD ret = fileio->count - fileio->lpOverlapped->InternalHigh; - return (ret < 0 ? 0 : ret); + return ( fileio->count <= fileio->lpOverlapped->InternalHigh ? + 0 : fileio->count - fileio->lpOverlapped->InternalHigh ); } static void CALLBACK fileio_call_completion_func (ULONG_PTR data) -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

June 10, 2002

Re: Fixes for ADPCM decoding.

by David D. Hagood

Gads. I knew better than that. Sorry, diff -u attached. Changelog: ADPCM nybble processing order was incorrect. ? console/Makefile ? controls/Makefile ? files/Makefile ? graphics/Makefile ? graphics/enhmetafiledrv/Makefile ? graphics/metafiledrv/Makefile ? graphics/win16drv/Makefile ? graphics/win16drv/prtdrv.glue.c ? graphics/x11drv/Makefile ? if1632/Makefile ? if1632/relay16.s ? libtest/Makefile ? loader/Makefile ? loader/ne/Makefile ? memory/Makefile ? misc/Makefile ? msdos/Makefile ? relay32/Makefile ? scheduler/Makefile ? win32/Makefile ? windows/Makefile ? windows/x11drv/Makefile ? windows/x11drv/wineclipsrv Index: dlls/msacm/imaadp32/imaadp32.c =================================================================== RCS file: /home/wine/wine/dlls/msacm/imaadp32/imaadp32.c,v retrieving revision 1.5 diff -u -r1.5 imaadp32.c --- dlls/msacm/imaadp32/imaadp32.c 31 May 2002 23:25:48 -0000 1.5 +++ dlls/msacm/imaadp32/imaadp32.c 10 Jun 2002 02:53:41 -0000 @@ -284,16 +284,16 @@ { for (i = 0; i < 4; i++) { - process_nibble(*src >> 4, &stepIndexL, &sampleL); + process_nibble(*src, &stepIndexL, &sampleL); W16(dst + (2 * i + 0) * 4 + 0, sampleL); - process_nibble(*src++, &stepIndexL, &sampleL); + process_nibble(*src++ >> 4, &stepIndexL, &sampleL); W16(dst + (2 * i + 1) * 4 + 0, sampleL); } for (i = 0; i < 4; i++) { - process_nibble(*src >> 4, &stepIndexR, &sampleR); + process_nibble(*src , &stepIndexR, &sampleR); W16(dst + (2 * i + 0) * 4 + 2, sampleR); - process_nibble(*src++, &stepIndexR, &sampleR); + process_nibble(*src++ >>4, &stepIndexR, &sampleR); W16(dst + (2 * i + 1) * 4 + 2, sampleR); } dst += 32; @@ -335,9 +335,9 @@ for (nsamp = nsamp_blk; nsamp > 0; nsamp -= 2) { - process_nibble(*src >> 4, &stepIndex, &sample); + process_nibble(*src, &stepIndex, &sample); W16(dst, sample); dst += 2; - process_nibble(*src++, &stepIndex, &sample); + process_nibble(*src++ >> 4, &stepIndex, &sample); W16(dst, sample); dst += 2; } /* we have now to realign the source pointer on block */

June 10, 2002

Re: Fixes for ADPCM decoding.

by Vincent Béron

"David D. Hagood" a écrit : > > I found a bug in the decoding of the ADPCM data - the nybbles in the > samples were being processed backwards - MSN then LSN (bits 4-7, then > 0-3), rather than LSN then MSN. Since ADPCM re-syncs every 8 samples, > the audio was distorted but intelligable. With this fix, the audio is > correct. I've tested this patch with Delorme's AAA MapNGo 4.0, which > uses ADPCM for its audio files. > > NOTE: I didn't check the encoding routines, nor did I check the MSADPCM > files to see if they were correct. > > Changelog: > ADPCM nybble processing order was incorrect. > > ------------------------------------------------------------------------ David, please use the "-u" format for diffs. It's much safer to use, and it's good to have some context around the modified lines for quick review purpose. Vincent

June 10, 2002