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

Re: locale tests failed

by Shachar Shemesh

Paul Millar wrote: >BTW, has MS taken down their API reference from the MSDN website? I was >looking for the Win32 API reference on the MSDN web-site (to try and fix >the regression tests), but I couldn't find them. As far as I can remember, >it was available from MSDN Home --> MSDN Library --> Windows Development >--> Win32 API ... but there's only a sample chapter from a book there now. > >Cheers, > > > It's still there, just spread out a lot. Depends on what you are looking for. Usually, what I would do is type in the "search" area the name of the function, and then click on the link (careful not to click where the URL has something along the lines of "ceui", because that's windows CE). From there, everything is cross referenced, and you can click the "up". The paths to other functions have become much much much much much less convinent, but I believe the same has also happened to the latest MSDNs on CD - they are horrible user interface, to the point where you would usually rather use the online site (or an old MSDN CD). It's really interesting how MS's UI is deteriorating as time goes on (with the sole exception of Win 3.11->Win95). I have had to spend one day with Windows XP (install a friend's computer), and spent the entire time cursing about the UI. Shachar

June 12, 2002

Re: WM_GETTEXTLENGTH returns double size

by Shachar Shemesh

I am not sure about the specific case, but I do have some experience with handling DBCS in general. When using TCHAR and defining MBCS (which is the default with VCC - MS doing something nice for a change) the result (if my memory serves me correctly) is an unsigned char. This means that it is the same size as a regular char. The thing to understand when working with MBCS is that a single byte does not necessarily mean a single character. You get a stream of bytes, some will be 1 byte/character, and some 2. You are guaranteed against NULL and new line being misrepresented. For that reason alone most byte by byte processing will work on MBCS without a problem. If you are doing no string processing at all, you can simply ignore the MBCS possibility at all. Things do become messy if you want to either work on a character based calculations (i.e. - I have 7 characters in the string, despite it being 10 bytes long), if you are looking for a particular character ('\' is a nasty example), or if you want to traverse the string backwards. Traversing a MBCS string is akin to a forward iterator in STL. You have a macro (isleadbyte, IIRC) that lets you know whether the next byte is alone or part of a double byte. You are allowed to save the pointer and return to it, but when traversing the string backwards, it is very difficult for you to know whether the previous byte is a single character or not. Another problem is that the second byte of an MBCS character may be something you will find interesting on its own. Like I said before, one nasty example is when parsing a path and looking for '\' separators. There are some Japanese characters that, when coded in MBCS, result is two bytes, the second one being '\'. When the proper locale is loaded, Windows knows not to treat this '\' as a directory separator, but your programs may fail to do so (does wine?). These are the main issues when working with MBCS. I hope I have managed to help. Shachar Andriy Palamarchuk wrote: >This happens in code which unmaps message, mapped from >ASCII to Unicode. >See windows/winproc.c, function >WINPROC_UnmapMsg32ATo32W: > > case WM_GETTEXTLENGTH: > case CB_GETLBTEXTLEN: > case LB_GETTEXTLEN: > /* there may be one DBCS char for each Unicode >char */ > return result * 2; > >What is the correct way to handle double-byte >characters in this situation? >How Windows handles this? >At least can we return double values when system >metrics SM_DBCSENABLED is true? We could have a switch >in the config file for this system metrics. > >I came across this issue when used default combo box >control implementation in Delphi 6. >I assume the same issue also exists for edit controls. >The returned length is correct if I comment out the >code above. > >Existing behavior is a possible cause of bug in >entering serial numbers - when >cursor jumps to the next edit field when only half of >text is entered. > >Thanks, >Andriy > >__________________________________________________ >Do You Yahoo!? >Yahoo! - Official partner of 2002 FIFA World Cup >http://fifaworldcup.yahoo.com > > >

June 12, 2002

Re: locale tests failed

by Paul Millar

On Tue, 11 Jun 2002, [iso-8859-1] Sylvain Petreolle wrote: [Regression test output w/ locale tests failing under fr_FR] The tests also fail under en_GB: > tests/locale.c:219: Test failed: GetCurrencyFormat got > �2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx^E instead of $23.53 > tests/locale.c:226: Test failed: GetCurrencyFormat got �23.53 instead of > $23.53 It looks like the regression tests assume you are using a US locale. If you set LANG=en_US it works fine. BTW, has MS taken down their API reference from the MSDN website? I was looking for the Win32 API reference on the MSDN web-site (to try and fix the regression tests), but I couldn't find them. As far as I can remember, it was available from MSDN Home --> MSDN Library --> Windows Development --> Win32 API ... but there's only a sample chapter from a book there now. Cheers, ---- Paul Millar

June 12, 2002

WM_GETTEXTLENGTH returns double size

by Andriy Palamarchuk

This happens in code which unmaps message, mapped from ASCII to Unicode. See windows/winproc.c, function WINPROC_UnmapMsg32ATo32W: case WM_GETTEXTLENGTH: case CB_GETLBTEXTLEN: case LB_GETTEXTLEN: /* there may be one DBCS char for each Unicode char */ return result * 2; What is the correct way to handle double-byte characters in this situation? How Windows handles this? At least can we return double values when system metrics SM_DBCSENABLED is true? We could have a switch in the config file for this system metrics. I came across this issue when used default combo box control implementation in Delphi 6. I assume the same issue also exists for edit controls. The returned length is correct if I comment out the code above. Existing behavior is a possible cause of bug in entering serial numbers - when cursor jumps to the next edit field when only half of text is entered. Thanks, Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 12, 2002

Re: Problems converting DLL to unix SO with winelib

by list＠vmn.com.br

Thanks, Late last night I was looking at the makefile and saw that I could put the imports there. I tested this and it worked. I will put it in the makefile.in next...and then rerun configure. winebuild is receiving the import parameters like gcc does for includes and linking... Thanks for helping me get this far. My main question now is: Winemaker creates my winelib *.SO as libmytest.so . When trying to use is in my test app... I can´t get winebuild to understand the libmytest.so name. I have to copy libmytest.so to libmytest.dll.so I then tell winebuild to import libmytest.dll or libmytest I ALSO have to tell gcc to link mytest. If I dont tell gcc to link mytest I get unresolved symbols in the final linkage of the winelib app. If I dont tell winebuild to import libmytest.dll then the winelib DLL is not correctly initialized at run time. It seems strange to me to have to link with GCC and import with WINEBUILD. Is this correct? If so, then ideally winemaker -dll should generate names like mytest.dll instead of libmytest.so? Or winemaker after make install should create symlinks like /usr/local/lib/libmytest.so -> mytest.dll.so Miguel ---------------- > First of all, the patch may be far from perfect, I made it to suit my > own needs. I am happy about bug reports. Sure, I am using it! > > It is correct that there are no more imports in the spec file. > The import libraries are put in the Makefile.in instead, in the > xyz_IMPORTS variable, where xyz is your project name (have you rerun > ./configure ?). Yes. ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

June 12, 2002

Re: Problems converting DLL to unix SO with winelib

by Martin Wilck

Am Die, 2002-06-11 um 18.27 schrieb List vmn: > What is your patch doing ? First of all, the patch may be far from perfect, I made it to suit my own needs. I am happy about bug reports. It is correct that there are no more imports in the spec file. The import libraries are put in the Makefile.in instead, in the xyz_IMPORTS variable, where xyz is your project name (have you rerun ./configure ?). Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

June 12, 2002

O2 compilation option

by Shachar Shemesh

Hi all, I found that using the default ./configure options, the Makefiles are generated with "-g -O2" compilation options. This combination doesn't make sense to me, as what use are debug options if I cannot trace execution in a debugger. My autoconfig knowledge is not deep enough to understand whether there is a command line option to remove the "O2" from the makefiles. For the time being, I have simply modified configure by hand. Can anyone tell whether there is any better option? Shachar

June 12, 2002

Re: Problems running IE with latest release

by Andriy Palamarchuk

Con, --- Con Hennessy <CP.Hennessy(a)iname.com> wrote: > Hi, > I am trying to run IE version 4 ( I think ) however > I am > getting "unhandled exceptions". [skipped] I assume that you had IE running before, right? If this is the case you can easily help Wine developers to fix the issue if you find the patch which broke IE. This is described here: http://www.winehq.org/docs/wine-devel/cvs-regression.shtml Do you need help with CVS? Regards, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

June 11, 2002

winespy - a wine gui front-end for --debugmsg output

by max

I got the first (... very first) winespy wine front-end running. You can download at www.veneto.com/winespy/winespy.tar.gz In INSTALL and README files you'll find shorts description of usage and, of course, bugs :) Any suggestion/help appreciated ! Regards Max

June 11, 2002

Problems running IE with latest release

by Con Hennessy

Hi, I am trying to run IE version 4 ( I think ) however I am getting "unhandled exceptions". When I use the following command "wine --dll commctrl,comctl32=n iexplore.exe" I get : err:heap:HEAP_CreateSystemHeap system heap base address 0x65430000 not available err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/fonts/desktop.ini" err = 55 err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/fonts/modern.fon" err = 2 wine: Unhandled exception, starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x1581e3e4 I also tried to use : wine --dll shell,shell32,commctrl,comctl32=n --dll kernel32,netbios,netapi32,user32=b iexplore.exe but with the same results. I know how to turn tracing on, but am not sure what exactly is the problem. I've had a go at turning on the traces and got the following : 0807a828:Ret kernel32.CloseHandle() retval=00000001 ret=16013d94 0807a828:Call kernel32.OpenEventA(001f0003,00000000,16013e30 "HookSwitchHookEnabledEvent") ret=16013dbd 0807a828: open_event( access=001f0003, inherit=0, name=L"HookSwitchHookEnabledEvent" ) 0807a828: open_event() = OBJECT_NAME_NOT_FOUND { handle=0 } 0807a828:Ret kernel32.OpenEventA() retval=00000000 ret=16013dbd 0807a828:Call kernel32.TlsAlloc() ret=16013e03 0807a828:Ret kernel32.TlsAlloc() retval=00000002 ret=16013e03 0807a828:Ret PE DLL (proc=0x16013bbe,module=16012000,type=1,res=(nil)) retval=1 0807a828:trace:module:MODULE_InitDLL (0x159036b4,PROCESS_ATTACH,(nil)) - RETURN 1 0807a828:trace:module:MODULE_DllProcessAttach (ole32.dll,(nil)) - END 0807a828:trace:module:MODULE_InitDLL (shdocvw.dll,PROCESS_ATTACH,(nil)) - CALL 0807a828:trace:module:MODULE_InitDLL (0x1590349c,PROCESS_ATTACH,(nil)) - RETURN 1 0807a828:trace:module:MODULE_DllProcessAttach (shdocvw.dll,(nil)) - END 0807a828:Ret kernel32.LoadLibraryA() retval=16006000 ret=00401328 0807a828:Call kernel32.GetProcAddress(16006000,00000068) ret=00401346 0807a828:trace:win32:MODULE_GetProcAddress (16006000,0x68) 0807a828:trace:win32:PE_FindExportedFunction (104) 0807a828:Ret kernel32.GetProcAddress() retval=160070fc ret=00401346 0807a828:Call ntdll.RtlRaiseException(15b26d80) ret=16007059 0807a828:trace:seh:EXC_RtlRaiseException code=80000100 flags=1 addr=0x401726 0807a828:trace:seh:EXC_RtlRaiseException info[0]=1600da80 0807a828:trace:seh:EXC_RtlRaiseException info[1]=1600da94 0807a828:trace:seh:EXC_RtlRaiseException stub=104 0807a828: queue_exception_event( first=1, record={context={flags=00010007,eax=15b26d78,ebx=156885c4,ecx=1569f6e5,edx=15b26d80,esi=15651564,edi=00000001,ebp=15b26ce0,eip=15636943,esp=15b26cc4,eflags=00200212,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=158c58c4,dr1=1569f6b1,dr2=1581600d,dr3=158c58c4,dr6=1569f6b1,dr7=158c58c4,float={1569f6a8,15816ff5,1581600d,15b269c0,15816ff5,15b269f0,1581600d,158c58c4,1569f6d5,158c58c4,15b269f0,15b26ad0,158122f4,15b269e8,15816ff5,15b26a18,1569f6d5,1569faa7,00000000,158c58c4,34303118,15b26af8,158122f4,15b26a18,15669fb0,15b26b88,158122e3,15b26a18}},rec={code=80000100,flags=1,rec=(nil),addr=0x401726,params={1600da80,1600da94}} ) 0807a828: queue_exception_event() = 0 { handle=0 } 0807a828:trace:seh:EXC_CallHandler calling handler at 0x15651b64 code=80000100 flags=1 0807a828: queue_exception_event( first=0, record={context={flags=00010007,eax=15b26d78,ebx=156885c4,ecx=1569f6e5,edx=15b26d80,esi=15651564,edi=00000001,ebp=15b26ce0,eip=15636943,esp=15b26cc4,eflags=00200212,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=158c58c4,dr1=1569f6b1,dr2=1581600d,dr3=158c58c4,dr6=1569f6b1,dr7=158c58c4,float={1569f6a8,15816ff5,1581600d,15b269c0,15816ff5,15b269f0,1581600d,158c58c4,1569f6d5,158c58c4,15b269f0,15b26ad0,158122f4,15b269e8,15816ff5,15b26a18,1569f6d5,1569faa7,00000000,158c58c4,34303118,15b26af8,158122f4,15b26a18,15669fb0,15b26b88,158122e3,15b26a18}},rec={code=80000100,flags=1,rec=(nil),addr=0x401726,params={1600da80,1600da94}} ) 0807a828: queue_exception_event() = 0 { handle=0 } 0807a828: create_event( manual_reset=1, initial_state=0, inherit=1, name=L"" ) 0807a828: create_event() = 0 { handle=56 } wine: Unhandled exception, starting debugger... 0807a828:trace:heap:RtlAllocateHeap (158d0000,00000002,0000006c): returning 15902fa0 0807a828:trace:reg:NtOpenKey (0x80000002,L"Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug\0000\5555\008d\0000\5246\4545\3554\1590`\158d\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa\aaaa"...,f003f,0x15b2680c) 0807a828: open_key( parent=-2147483646, access=000f003f, name=L"Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug" ) Open key ERROR 0807a828: open_key() = OBJECT_NAME_NOT_FOUND { hkey=0 } 0807a828:trace:reg:NtOpenKey <- 0x0000 0807a828:trace:heap:RtlFreeHeap (158d0000,00000002,15902fa0): returning TRUE 0807a828:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x1581e3e4 0807a828:trace:seh:EXC_RtlRaiseException info[0]=00000001 0807a828:trace:seh:EXC_RtlRaiseException info[1]=00000000 0807a828: queue_exception_event( first=1, record={context={flags=00000000,eax=ea985977,ebx=156885c4,ecx=ea98593f,edx=1567a6c1,esi=00000000,edi=15b26964,ebp=15b26668,eip=1581e3e4,esp=15b26664,eflags=00210203,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x1581e3e4,params={1,0}} ) 0807a828: queue_exception_event() = 0 { handle=0 } 0807a828:trace:seh:EXC_CallHandler calling handler at 0x15651120 code=c0000005 flags=0 0807a828:trace:seh:EXC_CallHandler handler returned 2 0807a828:trace:seh:EXC_CallHandler calling handler at 0x15651b64 code=c0000005 flags=10 0807a828:trace:seh:EXC_CallHandler handler returned 1 0807a828: queue_exception_event( first=0, record={context={flags=00000000,eax=ea985977,ebx=156885c4,ecx=ea98593f,edx=1567a6c1,esi=00000000,edi=15b26964,ebp=15b26668,eip=1581e3e4,esp=15b26664,eflags=00210203,cs=0023,ds=002b,es=002b,fs=008f,gs=0000,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=c0000005,flags=0,rec=(nil),addr=0x1581e3e4,params={1,0}} ) 0807a828: queue_exception_event() = 0 { handle=0 } 0807a828:err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x1581e3e4 0807a828: terminate_process( handle=-1, exit_code=1 ) 0807a828: terminate_process() = 0 { self=1 } 0807a828: *killed* exit_code=1 yamed(a)plato:~/kde_> /home/yamed/.wine/user.reg: saving key \\User\\yamed /home/yamed/.wine/system.reg: saving key \\Machine /home/yamed/.wine/userdef.reg: saving key \\User\\.Default Server: exiting (pid=23764) Anyone able to help, or make any suggestion ? Thanks, CP

June 11, 2002

gdi functions as undefined symbol in libwine.so

by Sylvain Petreolle

Hi, Marcus showed I probably have install problems. All symbols that are in gdi.exe dll are reported as undefined symbols in libwine.so fixme:win32:ELF_FindExportedFunction function AbortDoc not found: /usr/local/lib/libwine.so: undefined symbol: AbortDoc fixme:win32:ELF_FindExportedFunction function AbortPath not found: /usr/local/lib/libwine.so: undefined symbol: AbortPath Download CVS version from scratch and reinstall didn't fix the problem. Did someone else got the problem ? I actually don't see a way to fix it. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

June 11, 2002

Re: driver question

by Steve Langasek

On Tue, Jun 11, 2002 at 11:34:14PM +0200, Patrik Stridvall wrote: > > 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. Perhaps I've relayed it in an unclear manner, but that's my failing, not the LGPL's. When I say it must interface with the rest of Wine through a clearly defined API, I mean that any changes you make to existing Wine APIs in order to interface to this new driver must be released under the LGPL: you can only keep those parts of your code closed which do not include portions of someone else's LGPLed code. Steve Langasek postmodern programmer

June 11, 2002

Re: self-registerable standard DLLs

by Tony Lambregts

John K. Hohm wrote: >I was just about ready to send the last patch to complete the comcat.dll >implementation, fixing bug 652. I don't think another bug is necessary; I'll >implement Dll[Un]RegisterServer before pronouncing the bug fixed. Hopefully >doing this in the next couple of days will be "right away" enough for you. ;-) > > > > Plenty fast enough. Tony Lambregts

June 11, 2002

RE: driver question

by Patrik Stridvall

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

June 11, 2002

Re: driver question

by Steve Langasek

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. Cheers, Steve Langasek postmodern programmer

June 11, 2002

driver question

by Hetz Ben Hamo

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

June 11, 2002

Re: self-registerable standard DLLs

by John K. Hohm

Quoting Tony Lambregts <tony_lambregts(a)telusplanet.net>: > >>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. > > > >Actually putting that in DllRegisterServer is arguably the right way > >to do it. What we should have is some kind of installation step that > >would register the Wine dlls, instead of having to put everything in > >winedefault.reg. > > > Would it be a good idea to create a bug report for this?... Or does > someone want to implement it right away... I was just about ready to send the last patch to complete the comcat.dll implementation, fixing bug 652. I don't think another bug is necessary; I'll implement Dll[Un]RegisterServer before pronouncing the bug fixed. Hopefully doing this in the next couple of days will be "right away" enough for you. ;-)

June 11, 2002

Re: null midi device

by Johan Gill

Johan Gill wrote: >On Fri, 7 Jun 2002, degs wrote: > >>I'd still have thought that some more general way to get at Wine MIDI output >>would be more useful - like the ALSA output that someone suggested, or maybe >>Arts. That way at least people have a choice what synthesiser they use - >>timidity isn't everyone's cup of tea. >> >>I might be able to help with this If anyone was going to have a stab at it. >> > >I like that approach. Since I am personally motivated, I'll have a look. > >/Johan Gill, johane(a)lysator.liu.se > Done. TiMidity++-2.12.0beta as alsa sequencer client requires no modification to wine at all, and the OSS emulation of ALSA makes the thing transparent to WINE. /Johan Gill, johane(a)lysator.liu.se

June 11, 2002

Re: builtin oleaut32

by Marcus Meissner

On Tue, Jun 11, 2002 at 06:20:25PM +0100, Ann and Jason Edmeades wrote: > 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? Just continue, but please submit blocks of functions as you finish them, so possible duplication of work is reduced. > 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? Progressively, seperated into logical components. So Alexandre and wine-patches can grasp it. ;) My experience shows that patches should not be kept too long, or they just start to diverge too muchg. > 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? If it is not shown by +relay just leave it in. Ciao, Marcus

June 11, 2002

RE: builtin oleaut32

by Medland, Bill

> -----Original Message----- > From: Ann and Jason Edmeades [mailto:us(a)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

June 11, 2002

builtin oleaut32

by Ann and Jason Edmeades

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

June 11, 2002

Re: Linux patch for supporting shortcuts and symlinks on VFAT

by Brian Vincent

> 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

June 11, 2002

Re: FPU patch for bug 586

by Ove Kaaven

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; }

June 11, 2002

Re: GLU32 patch

by Vincent Béron

Marcus Meissner a écrit : > > 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? It's a libGLU 1.3 extension, and MSDN doesn't have any record of it. The glu32.dll in opengl95.exe (Microsoft's OpenGL distribution) doesn't have that function either, although from what I understood it could be included in individual card drivers. Should we limit our implementation to what Microsoft did, or should we implement more if a newer version of a standard came out since then? > > And you will need to add checks for glu.h in configure.ac too. Yes, of course. Forgot about it. > > Ciao, Marcus Thanks, Vincent

June 11, 2002

Re: Problems converting DLL to unix SO with winelib

by List vmn

Hi Martin, I finaly got the patch to work. The problem was with my mail client. I am now at the office and using eudora and things worked... A question, When I use the patched winemaker , I get a spec file with out any imports at all, even the ones specified on the command line. When I compile/link I get unresolved symbols. I then dont know what to do so I add the import lines back to the spec file and it links/compiles.... What am I missing here? What is your patch doing ? Thanks, Miguel At 17:17 7/6/2002 +0200, you wrote: >Am Fre, 2002-06-07 um 16.59 schrieb mfeitosa(a)vmn.com.br: > > > Here is the output... > >And here is mine: > >[martin(a)biker tools]$ cvs diff -u -r 1.39 winemaker >[martin(a)biker tools]$ cd .. >[martin(a)biker wine]$ patch -p0 --dry-run </tmp/winemaker.diff >patching file tools/winemaker >patching file documentation/winemaker.man >[martin(a)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(a)Fujitsu-Siemens.com >D-33106 Paderborn http://www.fujitsu-siemens.com/primergy > > > >

June 11, 2002