wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

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

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

Jump to page:

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