- wine-devel - winehq.org

RE: driver question
by Patrik Stridvall 11 Jun '02

11 Jun '02

> On Tue, Jun 11, 2002 at 11:23:06PM +0300, Hetz Ben Hamo wrote: > > > I'm not an expert on licensing, and I thought to ask this > question here - I'm > > not trying to make any emails flame war - just need a > simple answer... > > > A friend of mine is toying with an idea to write a frame > buffer driver instead > > of the x11drv on wine, but he doesn't think his boss will > allow to release > > the code.. > > > Can he (legally) write the driver, bundle it with the > lgpl'd wine and sell > > it? or is this illegal? > > If the driver interfaces with the rest of Wine through a > clearly defined > library API, and his proprietary code is distributed as > separate object > code that can be relinked with Wine at runtime or at build time (i.e., > made available as either .o files or as a .so shared lib), > then this is > unquestionably permitted by the LGPL. True in general but unfortunately the Wine display driver API wouldn't IMHO be classified as a clearly defined API... So whether this is allowed is a little unclear to say the least.

2 1

self-registerable standard DLLs
by John K. Hohm 11 Jun '02

11 Jun '02

I noticed that the attempt to test comcat.dll on Win98 failed because DllRegisterServer is a stub returning E_NOTIMPL. I have added the registry entries for the component categories manager to winedefault.reg, which should suffice for normal Wine installations. Despite this, is it generally acceptable to have actual code to register/unregister a standard COM server DLL in its Dll[Un]RegisterServer? It would be redundant for normal Wine, but hey, it's not big or complex.

4 5

driver question
by Hetz Ben Hamo 11 Jun '02

11 Jun '02

Hi, I'm not an expert on licensing, and I thought to ask this question here - I'm not trying to make any emails flame war - just need a simple answer... A friend of mine is toying with an idea to write a frame buffer driver instead of the x11drv on wine, but he doesn't think his boss will allow to release the code.. Can he (legally) write the driver, bundle it with the lgpl'd wine and sell it? or is this illegal? Thanks, Hetz

2 1

Re: null midi device
by Eric Pouech 11 Jun '02

11 Jun '02

> I was thinking: Couldn't one use timidity to make a fake midi device > that actually produces sound? That would be something. I thought about it. you need to use timidity 0.20i (the last one from the original author released under LGPL, the next ones are released under GPL). Then, to make it a real midi driver (in terms of Win32 API) which isn't a trivial task (for example, timidity pre-processes the full content of the MIDI file to be played, whilst a standard MIDI driver has to play midi notes on the fly...). I did start looking at that a long time ago, but without real results in so far. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

6 9

builtin oleaut32
by Ann and Jason Edmeades 11 Jun '02

11 Jun '02

Hello, I have been doing some playing with builtin oleaut32 and a Visual Basic program I am trying to get working under wine with no-windows (well, as little as possible anyway). I noticed after copying some ocx files from windows, I was starting to trap due to unimplemented stubs inside oleaut32, and have started coding up just enough to get my application working. Every time I fix one issue, I find 2 others, so before I dive in too far has anyone else done any work in improving this area which hasnt been submitted, or is anyone actively working on this - or should I just continue? Currently I have: VarCmp support for BSTR and Integer variants VarAnd support for boolean variants only VarNot support for boolean variants only VarParseNumFromStr support for negative numbers VarNumFromParseNum support shorts VarDateFromUDate return value is incorrect VarNot support for boolean variants only Two other questions as I am still fairly new at Unix in general, let alone wine.... 1. What is the policy on patches - Is one big one with all changes for the same module ok? 2. What about tracing - While writing them I have added trace to show the parms and return values (relay just shows the rc whereas the actual return value is normally a third varient). Should I leave these in? Thanks Jason

2 1

RE: builtin oleaut32
by Medland, Bill 11 Jun '02

11 Jun '02

> -----Original Message----- > From: Ann and Jason Edmeades [mailto:us@the-edmeades.demon.co.uk] > Sent: Tuesday, June 11, 2002 10:20 AM > To: wine devel > Subject: builtin oleaut32 > > > Hello, > > I have been doing some playing with builtin oleaut32 and a > Visual Basic > program I am trying to get working under wine with no-windows > (well, as > little as possible anyway). > > I noticed after copying some ocx files from windows, I was > starting to trap > due to unimplemented stubs inside oleaut32, and have started > coding up just > enough to get my application working. Every time I fix one > issue, I find 2 > others, so before I dive in too far has anyone else done any work in > improving this area which hasnt been submitted, or is anyone actively > working on this - or should I just continue? Basically that's what I noted too. I am sort of working in the area but I haven't even got everything working natively yet (since I started from a non-windows installation and it's hard to figure out what needs to be put in). I would suggest that the best solution is to submit small packages at regular intervals. > > Currently I have: > VarCmp support for BSTR and Integer variants > VarAnd support for boolean variants only > VarNot support for boolean variants only > VarParseNumFromStr support for negative numbers > VarNumFromParseNum support shorts > VarDateFromUDate return value is incorrect > VarNot support for boolean variants only > > Two other questions as I am still fairly new at Unix in > general, let alone > wine.... > 1. What is the policy on patches - Is one big one with all > changes for the > same module ok? > 2. What about tracing - While writing them I have added trace > to show the > parms and return values (relay just shows the rc whereas the > actual return > value is normally a third varient). Should I leave these in? Sounds a good idea. Presumably they are under the ole debug channel. If it gets ridiculous it might be worth adding a new debug channel. > > Thanks > Jason > > > Bill

1 0

Re: Linux patch for supporting shortcuts and symlinks on VFAT
by Brian Vincent 11 Jun '02

11 Jun '02

> 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'd agree that doing it at the kernel level isn't the answer. You don't want to abstract that information away from the user. Plus, like Francois mentioned there's a bunch of cases where it's just not going to work. However, what would be interesting (if you're going to parse the .lnk file anyway) is to display it as a symlink, but not actually have it operate as a link. For instance: -rw-r--r-- 1 vinn power 22 Jun 11 09:16 junk -> c:\Program Files\bar At that point it becomes useful to parse large directories of .lnk files by simply reading the directory. Leave it up to the application (Wine, etc) to figure out how to translate the path. With proper error handling you could probably add it as a "feature" to every filesystem. </$.02> -brian

1 0

Re: FPU patch for bug 586
by Ove Kaaven 11 Jun '02

11 Jun '02

On Tue, 11 Jun 2002, admiral coeyman wrote: > 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... > > > I was unsure of the memory handling functions. Both of these functions report > that they return linear addresses, but I read one as a dos linear address and > the other as a wine linear address. It was a mistake on my part. I read it as > though I had to convert the seg:offset code to a dos linear address, then > convert it to a wine linear address. It may have made more sense to me if I > hadn't been worried about the addresses being in the wrong order. Well, the meanings of these address types are, if I remember right: Real = 16-bit real mode seg:ofs address Dos = 32-bit offset from DOSMEM_dosmem (aka DOSMEM_MemoryBase()) (unless it's above 1MB, then it's considered a linear pointer) (after the DOS restructure, DOSMEM_dosmem is always 0, which is probably why it worked for you) Linear = 32-bit linear pointer that you can dereference in Wine code I consider the "Dos" memory type pretty useless, there's almost never a reason to use it instead of linear memory or something... > What I read says that the stack's lowest address contains IP and the word > above that is the code segment for the return. IP:CS I'm not sure that I > could just point a segment:offset converting function at an address in that > format and get the linear address. Well, you can, as long as we stick to x86 (might be trickier if we were to write a CPU emulator, but I guess there would be lots of places to change then anyway). > I've done the reverse conversion be backing IP up 2 bytes. You have two versions of the Int3dHandler in your patch. One of them isn't changed... Anyway, if it helps, here's how I might have written your routine (without the error checking), if I thought that perhaps these interrupts are also used by win16 apps (otherwise the second CTX_SEG_OFF_TO_LIN(...) can be replaced with PTR_REAL_TO_LIN(stack[1], stack[0])) void FPU_ModifyCode(CONTEXT86 *context, BYTE Opcode) { WORD *stack = CTX_SEG_OFF_TO_LIN(context, context->SegSs, context->Esp) BYTE *code = CTX_SEG_OFF_TO_LIN(context, stack[1], stack[0]); code[-2] = 0x9b; code[-1] = Opcode; stack[0] -= 2; }

1 0

Re: GLU32 patch
by Marcus Meissner 11 Jun '02

11 Jun '02

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

2 1

Problems converting DLL to unix SO with winelib
by List vmn 11 Jun '02

11 Jun '02

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

1 0

Problems converting DLL to unix SO with winelib
by mfeitosa 11 Jun '02

11 Jun '02

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

1 0

RE: Linux patch for supporting shortcuts and symlinks on VFAT
by Patrik Stridvall 11 Jun '02

11 Jun '02

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

1 0

RE: Linux patch for supporting shortcuts and symlinks on VFAT
by Patrik Stridvall 11 Jun '02

11 Jun '02

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

2 1

Linux patch for supporting shortcuts and symlinks on VFAT
by Patrik Stridvall 11 Jun '02

11 Jun '02

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?

2 1

GLU32 status & update
by Vincent Béron 11 Jun '02

11 Jun '02

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

2 1

bugs.winehq.com upgraded
by Jeremy Newman 11 Jun '02

11 Jun '02

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@codeweavers.com |_|\_\___|\_/\_/|_|_|_\__,_|_||_| -= ICQ: 1842980 Yahoo: laxdragon

2 3

tabctl32.ocx
by Medland, Bill 10 Jun '02

10 Jun '02

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

1 0

debug channels
by max 10 Jun '02

10 Jun '02

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

1 0

Lotus Notes R5 devel
by JJ Neff 10 Jun '02

10 Jun '02

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 jjneff(a)yahoo.com John __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

4 3

Error messages when typing Hebrew characters
by Shachar Shemesh 10 Jun '02

10 Jun '02

Hi. I tried repeating Hetz's experiment, and run the command "LANG=he_IL wine notepad", and then type a few (random) Hebrew chars. I get the following messages on screen: Warning: Language 'he_IL' was not found, retrying without country name... fixme:edit:EDIT_EM_FmtLines soft break enabled, not implemented fixme:win:GetProcessDefaultLayout ( 0x40556df4 ): No BiDi err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CEA (hebrew_finalkaph) : err:keyboard:X11DRV_ToUnicode (virtKey=4C,scanCode=26,keycode=2E,state=2010) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CF9 (hebrew_shin) : err:keyboard:X11DRV_ToUnicode (virtKey=41,scanCode=1E,keycode=26,state=2010) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CEC (hebrew_lamed) : err:keyboard:X11DRV_ToUnicode (virtKey=4B,scanCode=25,keycode=2D,state=2010) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CE3 (hebrew_dalet) : err:keyboard:X11DRV_ToUnicode (virtKey=53,scanCode=1F,keycode=27,state=2010) I tried following X11DRV_ToUnicode around a bit, but hit a brick wall at the X11 function "TSXKeysymToString". Anyone has any idea why the Hebrew characters are not being translated correctly (the character names are correct). Shachar

2 8

Crash with "privileged instruction in 16-bit code"
by Andriy Palamarchuk 10 Jun '02

10 Jun '02

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

2 1

Re: FPU patch for bug 586
by Ove Kaaven 10 Jun '02

10 Jun '02

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

1 0

Re: Return value of fileio_get_async_count
by Martin Wilck 10 Jun '02

10 Jun '02

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@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: Fixes for ADPCM decoding.
by Vincent Béron 10 Jun '02

10 Jun '02

"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

2 1

LinuxTag 2002
by Malte Cornils 10 Jun '02

10 Jun '02

Hi all, I'm just writing to "report" from WINE's booth during LinuxTag in Karlsruhe, Germany. Andreas Mohr and Uwe Bonnes were the developers staffing the booth. Generally, there was significant interest and high hopes for the WINE project, requests for application support was centered on MS Office (Word and Access mainly, also secondary MS apps like Visio and MS Project), Lotus Notes (but that one works quite well already, although we didn't demo it), WYSIWIG Web editors (Dreamweaver, Homesite) and DTP application (very common was support for PageMaker, which is the predecessor to Adobe InDesign). Illustrator and Photoshop were also common requests. The other notable application was Act 2000, which is some kind of Personal Information Management Software (and it did not work :)). CAD software was also commonly requested, though requests were spread on a lot of products. We tried to analyze most of the problems - I hope I can put in some bug reports later. We were able to solve *two* problems - Rhinoceros 3D modelling software (Andi will mail the patch later) and some fixes for BuildCommDCB (for some special hardware development software). A personal wishlist item: I'd like to have some overview documentation for the tricky areas in Wine, like Interprocess communication and window management (how to debug this, mainly). We found out that the wine debugger doesn't really work that well yet :-) (for me, it only worked after setting it to not using an xterm/wconsole) Marcus Meissner also stopped by and found out that most apps (Homesite, Dreamweaver, Adobe InDesign 2.0) were using encryption to protect their application file, we didn't get the decryption working. A lot of apps would probably start working if we could support "encrypted" binaries. I'll try to put in more detail later, however, you can download their trial applications and see for yourself :-) Another area of consternation was installer support, however, most InstallShield-based installers worked with a native stdole32.tlb (maybe a message to the user that (s)he needs this would be a good idea while we can't generate the typelib file ourselves, or is there some rewind stuff we could use?). About games: we showed Half-life, Diablo 2, Starcraft and Grim Fandango, we used winex for that, though. Reaction to the proprietary extensions of Transgaming (and sometimes Codeweavers) were varied. It was a bit sad that most non-game applications each had some flaws (the WordArt bug for Office, dibengine problems for MS IE, the non-working compiler backend for Visual Studio (could be a problem with the specific computer) and well... there weren't many more apps we could show because most didn't start up :)) Links to trial applications: (those I mentioned above) InDesign 1.5: ? InDesign 2.0 (PageMaker would also be interesting, get it from the same URL): http://www.adobe.com/support/downloads/main.html Illustrator 10: http://www.adobe.com/support/downloads/main.html Act 2000: http://www.act.com/products/50/freetrial/index.cfm CoolEdit 2000: http://www.syntrillium.com/download/download.html?1 Homesite: http://www.macromedia.com/software/homesite/trial/ (note: registering should not be necessary, click on "continue w/o login" Dreamweaver: http://www.macromedia.com/software/trial_download/ Rhinoceros 3D: http://download.mcneel.com/rhino/2.0/eval/default.asp (this one works great with Andi's patch!) (and those that were rarely or just once mentioned, and not mentioned above) Gandke & Schubert EAR and GS-Verein: http://www.gsn.de/download/default.asp Lemmings Revolution: http://www.gsn.de/download/default.asp Mindmap: http://www.mindjet.de/download/download.php?produkt=mm2002std-g (with registration) Q-Stat: http://www.q-das.de/homepage_e/produkt%FCbersicht_e.htm (no free download. contacting them via mail requesting a demo per snail mail should work) Xara X: http://www.xara.com/downloads/xarax/ Photos: We made few. I hope Andi will mail an URL with them to wine-devel later. (I hope I can post some debug logs later and put some entries in the bug tracking system. No firm promises though, but you can always try most apps yourself) Yours Malte #8-)

1 0

command line options and registry questions
by Christian Costa 09 Jun '02

09 Jun '02

Hi winers! The command line -winver option has been removed. I found that this option was quite convenient because : 1) it can be used easily in shortcut (in KDE for example) 2) when you don't know the windows version an app runs on, it is easier to test until you match the right one. Is there a reason for this removal ? Moreover it seems that some wine configuration are stored in the registry (the windows version for each apps for example). Is it wise to use the registry for wine specific configuration ? Personaly, I think a very cool feature could be to specify a registry file when invoking wine. So, you don't have to worried about breaking an app while installing another. A+ Christian

1 0

Locale support
by P. Christeas 09 Jun '02

09 Jun '02

I haven't looked at wine code yet. However, I think I have an idea about locale use both in KDE and glibc-based programs. Those two use a totally different subsystem: KDE uses Qt unicode support from QString class. glibc has locale functions and supports both wide (16-bit) and byte (8-bit) strings. Here, nothing is expected to work until you call the set_locale fn. In both cases, applications (including wine) have to be locale-aware in order for things to work. Most of the apps currently have lots of bugs related to locales in strings. You can ask for my help in such cases, as I am strongly for internatinalized programms.

1 0

[Fwd: [BUGZILLA] Security Advisory For Versions of Bugzilla 2.14 Prior To 2.14.2, 2.16 Prior To 2.16rc2]
by Shachar Shemesh 09 Jun '02

09 Jun '02

FYI.

1 0

Word2K crash (window management, remote)
by Andreas Mohr 09 Jun '02

09 Jun '02

Hi all, crash for Word2K, current CVS, Insert->Object...->Microsoft WordArt 2.0: 153 if (!(parentWnd->dwStyle & WS_CLIPCHILDREN) && parentWnd->hrgnUpdate) Wine-dbg>bt Backtrace: =>0 0x405ebaae (WIN_HaveToDelayNCPAINT+0x3e(hwnd=0x1004b, uncFlags=0x0) [painting.c:153] in user32.dll.so) (ebp=40566cb4) 1 0x405ec571 (RDW_Paint+0x81(wndPtr=0x403980a0, hrgn=0x0, flags=0x50, ex=0x0) [painting.c:606] in user32.dll.so) (ebp=40566ce0 2 0x405ecae5 (RedrawWindow+0x3b1(hwnd=0x1004b, rectUpdate=0x0, hrgnUpdate=0x0, flags=0x50) [painting.c:801] in user32.dll.so) (ebp=40566d4c) 3 0x40614ba9 (PeekMessageW+0xfd(msg_out=0x447030, hwnd=0x0, first=0x0, last=0x0, flags=0x0) [message.c:2103] in user32.dll.so) 4 0x40614c1b (PeekMessageA+0x27(msg=0x447030, hwnd=0x0, first=0x0, last=0x0, flags=0x0) [message.c:2126] in user32.dll.so) (ebp=40566dbc) 5 0x0040ce4f (Wrdart32.exe..text+0xbe4f in C:\Program Files\Common Files\Microsoft Shared\WordArt\Wrdart32.exe) (ebp=00447030) 6 0x00000532 (ebp=00020040) inf loc: hwnd == 0x1004b uncFlags == 0 parentWnd == 0 The parent window seems to be a valid window handle, but the parent wnd *ptr* becomes NULL -> crash. Sounds like some code nullifies the valid parent window handle in between. Of course I suppose that window locking was supposed to take care of this. Seems like this isn't exactly the case here ;-) Any ideas ? Hmm, wait, in a trace I just found: trace:win:RedrawWindow 10048 (16a6) NULL 0,0-0,0 0000 flags=0050 trace:win:OffsetRect <- 0,0-78,13 trace:win:RDW_UpdateRgns hwnd 10048 [16a6] -> hrgn [0000], flags [0050] trace:win:RDW_Paint hwnd 10048 [16a6] -> hrgn [0000], flags [0050] err:win:WIN_FindWndPtr window 10022 belongs to other process 093bda98:Call kernel32.UnhandledExceptionFilter(40454900) ret=0043854a wine: Unhandled exception, starting debugger... So it seems like the parent window is in another process and thus WIN_FindWndPtr fails to return the handle and returns NULL. Should we handle the possibility of a foreign parent window handle by not doing anything in case of a NULL parent wndPtr in WIN_HaveToDelayNCPaint() ? Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

1 0

Games, Stuff and Whatnot
by Phil Bordelon 08 Jun '02

08 Jun '02

Hello there. I've been following the wine-devel--and, more recently, the wine-license--mailing lists for some time now. While I am a competent C and C++ programmer, I haven't had the time to really come up-to-speed with the Windows API enough to help in re-implementing it. [Part of that comes from an aversion to even learning enough about the Windows API to re-implement it.] Nevertheless, for a considerable period of time before I switched entirely to Linux, I happened to be a professional video-game reviewer. I was the primary PC game reviewer for the site, and because of that I happen to have legitimate copies of just about every major PC release for the past two years, not counting stuff in the last handful of months. [I have Max Payne, but not Morrowind, and so on.] I also happen to be a game collector, and over the years I've picked up a number of games even older than those, including a game (Surface Tension) that uses what I believe to be pre-3.0 DirectX. Meep! Anyway, the point of this letter is this--if people are planning on starting on an implementation of the whole Direct3D/DirectX thing for the WineHQ wine, I'm willing to be an official 'guinea pig.' I can provide any developer working on this with a list of games I own, and we can start banging away on getting them to work. There is one caveat: I don't reboot into Windows, so it'll have to be installable under Linux. While some older games work already, the InstallShield work from Transgaming that they're putting into the ReWind tree is probably necessary before the recent stuff will work. Eventually, I'd like to help with the code as well, but I'd like to proffer what services I can right now. Phil -- "'Original .signatures are for wimps!' .signatures are for wimps!" .signatures are for wimps!

1 0

Problems converting DLL to unix SO with winelib
by list＠vmn.com.br 07 Jun '02

07 Jun '02

Hello All At Wine-Devel! I am trying to convert a win32 DLL to a unix SO. The dll named if32dt is basically a wrapper over the serial port, interfacing some custom hardware. It is therefore a driver to the custom hw. This is part of a project to port a windows sales app to linux. There are about 6 DLLs with similar structure and my aim is to show my superiors that using winelib is much better than simply rewriting the DLL to use unix system calls. 1) I have sucessfully copied my project over to unix and built the so file The project is basicaly a couple of headers and the c file ifdt32.cpp bash# cd ifdt32/ bash# mv ifdt32.cpp ifdt32.c #the file is plain C , cpp was confusing gcc bash# winemaker --nomfc -imsvcrt.dll -I/usr/local/include/wine/msvcrt --dll . bash# ./configure bash# make bash# make install The DLL uses msvcrt so I added it. => I read some issues between msvcrt and crt in winehq.com After changing a couple lines of ifdt.c I was able to build libifdt.so . I had a lot of warnings like ifdt32.c:176: warning: comparison between pointer and integer My ifdt32.spec file is unchanged from what winemaker created name ifdt32 type win32 mode dll init DllMain import msvcrt.dll import advapi32.dll import comdlg32.dll import gdi32.dll import kernel32.dll import ntdll.dll import odbc32.dll import ole32.dll import oleaut32.dll import shell32.dll import user32.dll import winspool.drv ifdt32.c only uses msvcrt.dll, ntdll.dll , kernel32.dll, user32.dll I added simple printf calls to DllMain to see if it was being called when the SO is loaded make install correctly put libifdt.so in /usr/local/lib I ran ldconfig in /usr/local/lib with bash# ldconfig -v -n . libifdt32.so -> libifdt32.so libwine_unicode.so -> libwine_unicode.so.1.0 libwine_tsx11.so -> libwine_tsx11.so.1.0 libwine.so -> libwine.so.1.0 2) I created a trivial program to test libifdt.so bash# cat test.c #include "windows.h" #include "stdio.h" #include "stdlib.h" #include "string.h" #include "io.h" #include "conio.h" #include "fcntl.h" #include "direct.h" #include "time.h" #include "IFfunc32.h" printf("before start"); int main(void) { printf("before start"); if( IF_IFDT32_OPEN("COM2") == 0 ) { printf("We are working") ; } else { printf("Oh no!"); } } bash# make gcc -g -c test.c -I/usr/local/include/wine -I/usr/local/include/wine/msvcrt -I/home/nwine/ifdt32/ifdt32 gcc -o test test.o -lifdt32 -L/usr/local/lib This program seg faults. I have not been able to debug it with winedbg, it simply hangs with message "Starting with pid 0" bash# gdb test (gdb) b 1 Breakpoint 1 at 0x8048556: file test.c, line 1. (gdb) r Starting program: /home/nwine/ifdt32/test/test Breakpoint 1, main () at test.c:15 15 printf("before start"); (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x400387cb in dllname () from /usr/local/lib/libifdt32.so (gdb) bt #0 0x400387cb in dllname () from /usr/local/lib/libifdt32.so #1 0x8048563 in main () at test.c:15 #2 0x40057f9b in __libc_start_main () from /lib/libc.so.6 (gdb) p dllname $1 = "ifdt32" In this trace, it seems that a function named dllname is causing a segfault There is a string named dllname and it's contents are correct I think the winelib initialisation code has not been correctly called For example: the Dllmain function to start the DLL has not been called I have tried a great many things to work around this problem with no success. It is hard to debug because the seg fault happens very early and I havent been able to get winedbg to work. I have tried this on wine-20020509 and wine-20020122 with exactly the same problem. Thanks a lot for any help or pointers. Miguel Feitosa Sao Paulo - Brasil P.S> output of bash# ldd ifdt.dll libwine.so => /usr/local/lib/libwine.so (0x40010000) libwine_unicode.so => /usr/local/lib/libwine_unicode.so (0x40026000) libm.so.6 => /lib/libm.so.6 (0x40103000) libc.so.6 => /lib/libc.so.6 (0x40125000) libdl.so.2 => /lib/libdl.so.2 (0x40245000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000) ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

2 1

How to compile to include debug info
by Medland, Bill 07 Jun '02

07 Jun '02

I am trying to track down a problem that is resulting in an attempt to dereference the null pointer. Very conveniently this happens in some code for which I have the source. However winedbg reckons there is no debug information in the DLL. This is not true; there is an enormous amount in there so I guess its in the wrong format. Can anyone tell me which settings I need when compiling the DLL under VC6++ in order to allow winedbg to understand the information and give me a usable stack trace? Bill

1 0

Call for testers
by Johan Gill 07 Jun '02

07 Jun '02

Quoting a comment I made for bug# 722: This is troublesome. I can fix this problem by reenabling these things in dlls/version/info.c: /* Temporary workaround a broken behaviour of the 16-bit loader */ len = 0; /* VERSION_GetFileVersionInfo_16(filename, handle, 0, NULL); */ /* Temporary workaround a broken behaviour of the 16-bit loader */ len = 0; /* VERSION_GetFileVersionInfo_16(filename, &handle, datasize, data); */ Doing so, however, is said to break installation of Office 2000. I don't have Office 2000, so it's quite impossible for me to know what's wrong. I would like to hear from anyone having it, and who is willing to try installation of it with those calls reenabled.

1 0

Re: Problems converting DLL to unix SO with winelib
by list＠vmn.com.br 07 Jun '02

07 Jun '02

Martin, Thanks for your help. I see from your output that the diff file is correct. I think my email program is messing with the contents of the email. I had diferent errors from your email than I had from the web page. I tried editing some of the diff file but it was hopeless.... I didnt get a nice patch like your output suggests. I dont know what to put into the spec file. I read everything but winebuild source. I am not familiar enough with ELF, linking etc to understand what is going on in the source. I havent been able to get a simple example to compile and work either. This simple example doesnt need to import any Dlls. It seems that I am not writing the spec file correctly. Therefore, winelib is not init ing correctly and my DllMain function is not being called when the Shared Object inits. Any pointers? Can you send me the diff file gzipped or whatever so I can finaly make the patch work? Thanks, Miguel Quoting Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com>: > Am Fre, 2002-06-07 um 16.59 schrieb mfeitosa(a)vmn.com.br: > > > Here is the output... > > And here is mine: > > [martin@biker tools]$ cvs diff -u -r 1.39 winemaker > [martin@biker tools]$ cd .. > [martin@biker wine]$ patch -p0 --dry-run </tmp/winemaker.diff > patching file tools/winemaker > patching file documentation/winemaker.man > [martin@biker wine]$ > > Perhaps you have the wrong patch. I attach it. > Martin > > -- > Martin Wilck Phone: +49 5251 8 15113 > Fujitsu Siemens Computers Fax: +49 5251 8 20409 > Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com > D-33106 Paderborn http://www.fujitsu-siemens.com/primergy > > > > > ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

1 0

Simple Windows DLL does not work correctly with winelib - HELP
by list＠vmn.com.br 07 Jun '02

07 Jun '02

Hello All, I am trying to create a shared object from a DLL with winelib. I have been unable to make things work. Therefore I made a small example that points out the issues I am facing. I certainly appreciate your help. This has been tested on the last two versions of wine. wine-20020509 and 20020605 Say I had a windows DLL defined in mytest.c as #include <windows.h> #include <stdio.h> BOOL APIENTRY DllMain(HINSTANCE hinstDLL , DWORD fdwReason, LPVOID lpvReserved ) { printf("DllMain called"); return TRUE; } void usefullFunction() { printf("Usefull function got called"); } I put mytest.c inside a directory called mytest I then call winemaker as winemaker --dll --nomfc . I edit libmytest.spec so it looks like name meuteste type win32 mode dll init DllMain I then call configure make and make install I edit a file called callmytest.c #include "mytest.h" int main(void) { usefullFunction(); } After compiling, when calling ./callmytest I get output: Usefull function got called =>Supposed to get "DllMain got called" too It seems winelib is not initializing correctly and calling DllMain... It seems that the spec file format changed and so my spec file is incorrect. [Thanks Martin Wilck for your help) I read the libwine manual in winehq.com , wine/tools/winebuild/README , wine-devel list etc and still cant see what else I should do. Can someone help me get this simple example to work? Thanks, Miguel Feitosa This is output from make clean all rm -f *.spec.c y.tab.c y.tab.h lex.yy.c core *.orig *.rej \#*\# *~ *% .\#* meuteste.o libmeuteste.spec.o libmeuteste.tmp.o libmeuteste.so gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o meuteste.o meuteste.c ld -r meuteste.o -o libmeuteste.tmp.o strip --strip-unneeded libmeuteste.tmp.o LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH" /usr/local/bin/winebuild -fPIC -L/usr/local/lib/wine -sym libmeuteste.tmp.o -o libmeuteste.spec.c -spec ./libmeuteste.spec gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/local/include/wine -o libmeuteste.spec.o libmeuteste.spec.c gcc -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o libmeuteste.so meuteste.o libmeuteste.spec.o -lwine -lwine_unicode -lwine_uuid -lm ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

1 0

Need help debugging problem w/Quicken
by Carl Sopchak 07 Jun '02

07 Jun '02

I'm trying to get Quicken 2000 Deluxe running under Wine (on a Red Het 7.3 box). In order to use Quicken the way I want to, I need to have the internet connection going (for stock price updates). However, when I try to configure it, I can't get anywhere. When I press Edit -> Internet Connection Setup, the cursoe goes to an hourglass and hangs. If I move the cursor after that, it goes back to a normal arrow pointer. The setup dialog never pops up. I'm using the current CVS version of Wine (as of this morning, June 7). Now, I'm VERY new to Wine, and know less about Windows internals, but I've been in similar postitions and successfully resolved similar problems - with a little help... I guess I'm looking for some tips on how to debug this. I currently have these specific questions: 1) Is networking support implemented in wine yet (even partially)? If not, I guess I'll have to wait a while, as I'm not in a position (knowledge or time wise) to write something like that from scratch :-(. If it is implemented,... 2) I know about --debugmsg, and the four classes of debug messages, but I haven't come across many debug channel names, besides all, relay, and snoop. But the amount of messages that these generate lend them to be pretty unusable. Can someone point me to a list of names, tell me how to find the names in the source, or at least give me a few names that might be helpful in debuggin my problem? 3) I'm guessing that I'll probably need some documentation on the WinAPI. Does Microsoft have that on their web site? (If not, where might I find it?) 4) Does anyone know of a version of Quicken (>= Q2000) that already runs on wine? I'd be willing to upgrade if it would solve my problem... Thanks for any help you can give! Hopefully my work on this will improve wine in some small way... Carl

2 1

Deffered Debugmessages patch side effect
by Uwe Bonnes 07 Jun '02

07 Jun '02

Hallo, recent changes in debugmsg messages affected the --debugmsg -XXX behaviour. Now this command lines is a NOP. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: Problems converting DLL to unix SO with winelib
by list＠vmn.com.br 07 Jun '02

07 Jun '02

Wow, now I really lost it... I have tried to remove the imports from the spec file but then I get unresolved symbols when linking the so.. So what should it contain? Where is [if at all] the documentation for the spec file... Thanks, Miguel Quoting Martin Wilck <Martin.Wilck(a)Fujitsu-Siemens.com>: > Hi, > > winemaker in CVS is broken. Your "spec" file should not contain any > "imports" anymore, for example. > > I have submitted a patch for this a while ago to this list ("winemaker > fixes", 2002/05/22), which doesn't seem to have made it into CVS. > > Martin > > -- > Martin Wilck Phone: +49 5251 8 15113 > Fujitsu Siemens Computers Fax: +49 5251 8 20409 > Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com > D-33106 Paderborn http://www.fujitsu-siemens.com/primergy > > > > > ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

2 2

ttc & sbit patch
by Won Kyu Park 07 Jun '02

07 Jun '02

Hello, This is a quick hack for ttc fonts and it enables embeded sbits in ttc/ttf with a recent freetype library. It is based on a Korean patch but I don't know who make it :-) Regards, Won kyu Park

1 0

WinExec16 in shlexec.c
by Steven Edwards 07 Jun '02

07 Jun '02

Can we use CreateProcess here instead if WinExec? I only have this and about 6 other things stopping the mingw build Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

1 0

Minor build system change for the Windows ports
by Steven Edwards 07 Jun '02

07 Jun '02

Anyone got any input on this? We need to be able to link to imports for kernel32 other then the standard libkernel32.a. Mingw doesn't keep all of the kernel32 import information in libkernel32.a instead it is like MSVC where it has a libth32.a and libthunk32.a. What is needed here is a change to the build system that allows for importing of these libs at link time when building a dll that needs those exports. Psapi.dll needs the toolhelp lib and one of the directx dlls needs the libthunk. I submitted a dirty patch for this a week or two ago but it wasn't accepted. The other option is to make the "make implib" rule and change the search path for the import libs. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

1 0

Re: dlls/shell32/dialogs.c:RunFileDlg - implemented
by Nix N. Nix 06 Jun '02

06 Jun '02

On Thu, 2002-06-06 at 11:20, Nix N. Nix wrote: > On Thu, 2002-06-06 at 09:14, Mike McCormack wrote: > > > > You'd better use cvs diff -u (you can add diff -u to your ~/.cvsrc so as > > not to forget). > > > > You should just submit the changelog entries like this: > > > > Well, here it is with these mods then. I removed the stuff from the > ChangeLog file. Everything quoted below still holds. > > > ChangeLog: > > Added RunFileDlg with MRU list (based on the template found in > > Win98 shell32.dll) Added template to all .rc files Translated the hungarian copy of "Wine was brought to you by" > > > > Looks like good work though! I have updated the patch such that it modifies shell32_*.rc (except shell32_xx.rc, of course) to include the dialog box template. I have translated where I could. I also translated the "Wine was brought to you by:" string in shell32_Hu.rc . If you want me to put that in a separate patch, please let me know. > > > > Mike > > > > Nix N. Nix wrote: > > > I implemented RunFileDlg from dlls/shell32/dialogs.c, together with the > > > MRU list that Windoze has. I placed the MRU list stuff in the same > > > registry key as in Windoze. I had to add a dependency. The > > > "&Browse..." button requires commdlg. I didn't know how to do this in > > > the Makefile, so I used LoadLibraryEx. > > > > > > Well, here it is (diff is against CVS from around Wed Jun 5 16:00:00 > > > EDT 2002) > > Thanks for the help.

1 0

RE: Where is ELF stab documented?
by Medland, Bill 06 Jun '02

06 Jun '02

> -----Original Message----- > From: Medland, Bill [mailto:Bill.Medland@accpac.com] > Sent: Thursday, June 06, 2002 3:57 PM > To: Wine devel (E-mail) > Subject: RE: Where is ELF stab documented? > SNIP > > There is a GNU stabs documentation but I think it is not > complete. The > > only complete one might be the one in the gcc source :/ > > That's what I thought. Thanks anyway. > > Bill > or maybe http://sources.redhat.com/gdb/onlinedocs/stabs_toc.html Bill

1 0

Re: Winehq: Bugzilla responsibilities page
by Andreas Mohr 06 Jun '02

06 Jun '02

On Wed, May 29, 2002 at 12:06:22PM -0700, Andriy Palamarchuk wrote: > Changelog: > Added bugzilla responsibilities page. Hi, hmm, I'm not 100% sure about this. - why did you remove bug tracking link ? - "Talking Back" probably isn't very descriptive. I'd add something like "... (bugs etc.)" - that's Albe*r*telli - Application owners play *an* important role in the bugs handling process. - why add a whole new talkback.inc ? isn't that a bit overkill ? - why is <li>Bugs Hunting Guide</li> non-functional text ? Wow, questions over questions :-) Good job with bugz_resp.inc, BTW !! Needless to say I'll add this immediately as soon as these questions are covered :) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

3 4

RE: Where is ELF stab documented?
by Medland, Bill 06 Jun '02

06 Jun '02

> -----Original Message----- > From: Marcus Meissner [mailto:marcus@jet.franken.de] > Sent: Thursday, June 06, 2002 3:26 PM > To: Medland, Bill > Cc: Wine devel (E-mail) > Subject: Re: Where is ELF stab documented? > > > On Thu, Jun 06, 2002 at 03:14:45PM -0700, Medland, Bill wrote: > > For the sheer heck of it I was going to have a look at bug > 650. I know its > > not a high priority or anything but it intrigued me. > Anyway, to look into > > it I would want decent documentation on the format of the > stab/stabstr > > sections of the ELF files to understand what the parser > should be doing. > > Does anyone know where I can find that information? I > didn't see anything > > immediately in the Intel v1.1 specification. > > It appears not harmful (libstdc++ is pulled by libXrender.so here). > > Oh and the new debugging format of gcc 3.1 is DWARF-2, not stabs > anymore. > > There is a GNU stabs documentation but I think it is not complete. The > only complete one might be the one in the gcc source :/ That's what I thought. Thanks anyway. Bill

1 0

Do we need Direct3D? How about OpenGL?
by Roland 06 Jun '02

06 Jun '02

Hello, I just thought about this. AFAIK most good 3D games support OpenGL anyway. That means, they can run without D3D, right? If this is true maybe it would be more of an advantage to concentrate on other parts of DirectX first. Postpone D3D to a later moment...in a few years or so :)) Roland

3 2

How big is the Direct3D stuff?
by Roland 06 Jun '02

06 Jun '02

Hello, since it seems that TG is not going to release their D3D stuff, my question is: why is it so difficult to reimplement this? How big is the amount of code? Roland

6 9

Where is ELF stab documented?
by Medland, Bill 06 Jun '02

06 Jun '02

For the sheer heck of it I was going to have a look at bug 650. I know its not a high priority or anything but it intrigued me. Anyway, to look into it I would want decent documentation on the format of the stab/stabstr sections of the ELF files to understand what the parser should be doing. Does anyone know where I can find that information? I didn't see anything immediately in the Intel v1.1 specification. Bill

2 1

Re: opengl32 wglSwapLayerBuffers
by Lionel Ulmer 06 Jun '02

06 Jun '02

> I do think it's odd as well since a more basic function can handle it. > fixme:opengl:wglSwapLayerBuffers (0000087c, 00000001) > ..repeated until exiting the game. > > So it's basically switching the main layer over and over again? Yes, so they are simply 'emulating' SwapBuffers with the 'wglSwapLayerBuffers' call (as they only request swapping of the main buffer as shown by the 0x00000001 parameter given to the fuPlane parameter). > I don't think it uses other layers. Because I think there would be a > graphics corruption if it did. None have been observed so far. Anyway, as seen in the trace you posted, they seem to not use it. > Heh, since I'm a beta tester, I can ask blizz why they even use this > function, and see if they respond. You could always try... > And it's the best running game I've seen running under wine. =) A pity I am not a fan of RTS games :-) Lionel (wondering if MacOS X is not to thank for all those OpenGL + D3D games coming out) -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: imports by ordinal
by juergen.schmied＠debitel.net 06 Jun '02

06 Jun '02

>> I'd like to use in a internal wine-dll(shell32) a function exported >> by an other dll(shlwapi) by ordinal. How can I do this in a clean >> way without use of GetProcAddress in a way it works with native >> dll's too? >You have to use GetProcAddress, there is no automatic import >mechanism. That's a feature to discourage you from calling ordinal >functions ;-) shlwapi.dll exports quite a lot of functions to shell32 what would mean a lot of duplicate code ;-(. juergen

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel