wine-devel December 2003

wine-devel@winehq.org

109 participants
267 discussions

Re: I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 11 Dec '03

11 Dec '03

Actually Shachar, I was thinking along these lines: (1) Programs in WINE are making direct calls to internal functions (which are not really Win32, but made by us using which we can use te Win32 functions as wrappers...) and that's just possible because C functions are globally callable (the only thing you really need to keep the compiler happy is the function prototype) And that's a bad thing, because while developing tools we should really forget that we are coding fo WINE, and just write using Win32 SDK APIs... Encapsulating internal WINE functions as private, and exposing them using the correct APIs would be better engineering... Just to force lazy people like us to write protable code (you see, calling internal WINE functions are a lot easier than calling the corresponding wrappers.. (2) A few things like DirectX and COM are so very closely tied with C++ objects that implementing them in C seems an overkill to me. But after knowing they are done, I have nothing against that .... (3) C++ is VERY reusable. WINE has a lot of potential for reusablity , but by doing C where it was not needed, we are unnecessarily having to spend time finding out pieces here and there in the huge code structure. WINE is recieving more interest than ever, and we can only encourage people to join us by giving something they too can reuse, and people who really work for WINE are those types who start writing their own code if they find that tracing down a function and it's references will take more time. For example, whatever I have gone through (which is VERY little BTW..), I still feel that implementing many tools like winemenubuilder or winefile would have been better in C++ Infact, I intent to do some experimentation after Xmas (I am having my semester exams now, so ..) Hope what I said reaches you all ;) Season's greetings Subhobroto <snip> On Thu, 11 Dec 2003 Shachar Shemesh wrote : >I'm sorry, it has been YEARS since I wrote anything OLE related (my very first Windows program was an OLE server, hand coded, that did a shell extension. That was my only interaction with OLE). As such, I will not presume to decide whether that statement is correct or not. </snip snip, snip..>

2 1

Re: Adding support for a USB device
by Rolf Kalbermatter 11 Dec '03

11 Dec '03

Message: 2 Date: Tue, 9 Dec 2003 14:56:16 -0800 Subject: Adding support for a USB device From: Dan Timis <timis(a)museresearch.com> To: wine-devel(a)winehq.org Hi, >I need help with supporting a particular USB device under wine. I have >to start by saying that although I am an experienced C/C++ programmer >with some Linux experience, I have almost no Windows or wine experience. > >The Windows code for which I need to provide support uses CreateFile() >to get a handle to the device. The name of the device is something >like "\\.\MyDevice0" "\\.\MyDevice1" and so on. Then, the code uses >DeviceIoControl() to read and write from/to the device. The >requirement is not to change the windows code. > >I looked through the wine code and I found this in device.c: > >static const struct VxDInfo VxDList[] > >I could add another entry into the table and write a deviceio handler >(BOOL (*deviceio)(DWORD, LPVOID, DWORD, LPVOID, DWORD, LPDWORD, >LPOVERLAPPED);). I wrote some test code in Linux using libusb reading >and writing to the device so I know what to do inside the deviceio >handler. > >Is this the right approach? If so, what do I need to do to get >CreateFile to return the right handle? I think it really depends on the type of device and the possibility to rewrite the device driver or not. \\.\MyDevice0 is just a device driver name which at some point is registered in the registry with the appropriate VXD, SYS, or WDM driver file. If you know the exact DeviceIOControls called into that driver with its parameters and all, you could rewrite the VXD, SYS or WDM driver to call directly the appropriate Unix device driver calls and maybe compile it as a Winelib driver. With a bit hacking in the CreateFile function it should be possible to call such a driver over DeviceIOControl or you could add the according code to the above mentioned VXDList. >Or should I write an external driver that gets loaded by wine? If so, >how would I do that? What are the chances that the Windows driver for >this device would just work with wine? If you don't know these details and want to use the original device driver you are probably out of luck. The current CreateFile implementation is not really up to the task of loading an external native device driver and invoke it over the DeviceIOControl (which could probably be remedied with a little hacking at this point) and what is much more problematic there is little or no support for a lot of the Windows kernel services most device driver usually expect to be able to call. When they are not able to link to one or more of those functions at load time, loading of the device driver will simply fail in Wine, as it does with normal DLL files under all Win32 implementations, too. Rolf Kalbermatter

3 3

Crash early in running msiexec.exe
by Dan Kegel 11 Dec '03

11 Dec '03

This is on RH9 SMP with wine-20031118. Trying to run the MS SFU 3.0 (hey, I got it for $5 from that special offer they ran on slashdot a couple weeks ago...) setup.exe from the commandline yields the crash: Unhandled exception: page fault on read access to 0x0049002e in 32-bit code (0x400b73fd). In 32-bit mode. 0x400b73fd (NTDLL.DLL.RtlInitAnsiString+0x19 in NTDLL.DLL): repne scasb %es:(%edi) Wine-dbg>bt Backtrace: =>0 0x400b73fd (NTDLL.DLL.RtlInitAnsiString+0x19 in NTDLL.DLL) (ebp=4071e8f8) 1 0x400b7628 (NTDLL.DLL.RtlCreateUnicodeStringFromAsciiz+0x20 in NTDLL.DLL) (ebp=4071e918) 2 0x407bf5ad (USER32.DLL.MessageBoxIndirectA+0x119 in USER32.DLL) (ebp=4071e984) 3 0x407bf422 (USER32.DLL.MessageBoxExA+0x5e in USER32.DLL) (ebp=4071e9c4) 4 0x407bf38f (USER32.DLL.MessageBoxA+0x23 in USER32.DLL) (ebp=4071e9e4) 5 0x004010f7 (msiinst.exe.EntryPoint+0xf7 in msiinst.exe) (ebp=00000001) Seems a shame to bail out so early. Any suggestions for which --debugmsg channel to turn on? Best I could find was +process,+ntdll,+string which output the following right before the crash: ... trace:string:wvsnprintfA "Y:\\instmsi.exe /D:E:\\IXP001.TMP\\" trace:process:CreateProcessW app (null) cmdline L"E:\\IXP001.TMP\\msiinst.exe /i instmsi.msi REBOOT=REALLYSUPRESS /q" trace:process:find_exe_file looking for L"E:\\IXP001.TMP\\msiinst.exe" trace:process:find_exe_file Trying native exe L"E:\\IXP001.TMP\\msiinst.exe" trace:ntdll:NtReadFile (0x34,(nil),(nil),(nil),0x4051dca0,0x4051dd44,0x00000040,(nil),(nil)),partial stub! trace:ntdll:NtReadFile (0x34,(nil),(nil),(nil),0x4051dca0,0x4051dcdc,0x00000004,(nil),(nil)),partial stub! trace:ntdll:NtReadFile (0x34,(nil),(nil),(nil),0x4051dca0,0x4051dd24,0x00000014,(nil),(nil)),partial stub! trace:process:CreateProcessW starting L"E:\\IXP001.TMP\\msiinst.exe" as Win32 binary trace:process:__wine_kernel_init starting process name=L"E:\\IXP001.TMP\\msiinst.exe" file=0x4 argv[0]="E:\\IXP001.TMP\\msiinst.exe" trace:ntdll:NtReadFile (0x4,(nil),(nil),(nil),0xbfffd438,0xbfffd4dc,0x00000040,(nil),(nil)),partial stub! trace:ntdll:NtReadFile (0x4,(nil),(nil),(nil),0xbfffd438,0xbfffd474,0x00000004,(nil),(nil)),partial stub! trace:ntdll:NtReadFile (0x4,(nil),(nil),(nil),0xbfffd438,0xbfffd4bc,0x00000014,(nil),(nil)),partial stub! trace:process:__wine_kernel_init starting Win32 binary L"E:\\IXP001.TMP\\msiinst.exe" - Dan

2 4

Re: PATCH for Bugs 1844 and 1845
by Andreas Rosenberg 11 Dec '03

11 Dec '03

I sent two patches about a week ago. The first one: "Bug 1844: Point Size in DLG_TEMPLATE may be negative" made it into the CVS (I browsed with: http://cvs.winehq.com/cvsweb) The second "Bug 1845: Return values of CharUpperA and CharLowerA" did not. Any reasons to reject this patch? I also wrote an conformance test for this problem. Did the case mentioned on the WINE web site happen? "Rejected patches might receive a note in the wine-devel mailing list, and accidentally ignored patches will disappear into a silent, featureless void. Please resubmit if this happens to your patch." -- Andy

2 1

Re: Patch for bug 1848 - TrackPopupMenu returns wrong result, when menu is canceled
by Dimitrie O. Paun 11 Dec '03

11 Dec '03

On December 11, 2003 01:20 pm, Andreas Rosenberg wrote: > + if (!(menu = MENU_GetMenu( hmenu ))) > + { > + SetLastError(ERROR_INVALID_MENU_HANDLE); /* - added by A.Rosenberg > 2003.12.11 */ + return FALSE; > + } No need to add the 'added by ...' comment, it uglifies the code needlessly. That info is available in the log. Also, please try to follow the style of the file, nowhere do we use this bracketing style. -- Dimi.

1 0

multi-level subdirs under dlls/
by Dimitrie O. Paun 11 Dec '03

11 Dec '03

Hi folks, I know people are concerned right now with more important matters, but given that (1) we're cleaning up the tree, and (2) we're getting close to 0.9, I figured it maybe time to bring this up. Namely, under dlls/ we have by and large a flat structure, with the exception of a few 'special' cases (there's always have to be special cases :/). I find this rather upsetting, for the following reasons: -- the organization is confusing since it implies some sort of dependency that's not there (they are all .dlls) -- it makes grepping so much more difficult. Instead of the simple: grep BLAH dlls/*/*.[ch] we need to resort to find, etc. -- it makes scripts in general needlessly complicated -- it hides those parts in the depth of tree -- it is inconsistent with the rest of our DLLs Now, I know that this is mainly historical, but why not fix it? Yeah, we're going to loose a bit of CVS history, but not quite, because the move can mark that so in the log. So we're only making 'cvs log' on a few files a bit more complicated, but we're simplifying every day operation by so much. I think it's a clear win. Here is the list of the offending DLLs: ddraw/d3ddevice ddraw/dclipper ddraw/ddraw ddraw/direct3d ddraw/dpalette ddraw/dsurface dinput/joystick dinput/keyboard dinput/mouse gdi/enhmfdrv gdi/mfdrv msacm/imaadp32 msacm/msg711 msacm/msadp32 msacm/winemp3 msvideo/msrle32 user/dde wineps/data winmm/joystick winmm/mcianim winmm/mciavi winmm/mcicda winmm/mciseq winmm/mciwave winmm/midimap winmm/wavemap winmm/wineoss winmm/winearts winmm/winealsa winmm/winenas winmm/wineaudioio winmm/winejack Pretty please... -- Dimi.

3 3

Partial success: RoughDraft 2.11
by Dan Kegel 11 Dec '03

11 Dec '03

On a whim, I tried out RoughDraft 2.11 under wine-20031118 this morning. It installed and ran with some anomolies (e.g. the installer's EULA doesn't display at all!, .doc import works really poorly, a few pixels misplaced here and there, can't invoke web browser to display help), but it might be good enough for some users. It's a free download at http://www.rsalsbury.co.uk/rd.htm and I recommend it as a test app. His FAQ says no Linux or Mac port is planned, so there must be interest out there, and he'd probably be tickled pink if Wine improved to the point where it ran his app well enough for aunt Tilly to use. Sources not available but the author seems like a good guy, and would probably be willing to work with us if we really needed it (especially if we fixed a few things first, like that EULA display problem). - Dan

3 2

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 11 Dec '03

11 Dec '03

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he would let his elves use C++ in WINE. (Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', and you can make your wishes at 'wine-devel[at]winehq.com'..) You see, Santa was always so good - he answered people's prayers and got together his obedient elves to run Win32 on Non-Windows platforms! However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain C, and thus developments in those areas were soon in limbo. But that could be solved using yet another language called C++ - if only Santa would let it be. Oh please Santa ! Let us adultrate WINE with C++, please. It's not that we will rewrite everything in C++ once we get the green signal - things like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but what about MFC, COM, OLE ? Not that I expect to compile native MFC source using WineLib, but at least we can write the runtimes so that native MFC apps can atleast run under WINE ? DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM and already our implementations have structure object pointers running wild, whereas encapsulation would have done away with it ! As a simple explanation, we might take our 'This' hack wheras C++ would let have us use it as 'this' without even us worrying about it ! Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX source as I do not have a graphics base at all ..) where initializing a few member variables from a constructor would have done away with some redundancy. Most of the time we are passing around multilevel pointers when a simple reference would have done: For example a call like Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )'] can be made to a simple Stream_LoadString(sString); using C++ if we had the prototype rewritten to 'static HRESULT Stream_LoadString(LPWSTR& pstr )' and making it a member function of IStream (and thus the 'IStream* stm' and 'BOOL unicode' would be member variables..) We have code like that all over the place whenever COM etc comes into play and "That's Not A Good Thing(TM)" ! Please give us the green card - alternately, a new test branch may also be created just to see if C++ would work.All C++ based modfications would goto that tree. If that test branch works and delivers, it maybe merged into the main WINE tree, otherwise if it fails to deliver just remove it after a stipulated period ! If WINE stuck to C only because some platforms do not support C++, then will Win32 apps run on such OS at all ? Things like SPARC do not need MS Apps at all (though SPARC has C++..) For a expert discussion on C++ please see http://www.research.att.com/~bs/blast.html Microsoft themselves use C++ : <quote> Microsoft: Literally everything at Microsoft is built using various flavors of Visual C++ - mostly 6.0 and 7.0 but we do have a few holdouts still using 5.0 :-( and some products like Windows XP use more recent builds of the compiler. The list would include major products like: Windows XP Windows NT (NT4 and 2000) Windows 9x (95, 98,

9 12

dlls/oleaut32/tests/vartype.c problems
by Gerald Pfeifer 11 Dec '03

11 Dec '03

The new file dlls/oleaut32/tests/vartype.c, add by the following commit revision 1.1 date: 2003/12/11 05:25:44; author: julliard; state: Exp; Jon Griffiths <jon_p_griffiths(a)yahoo.com> Test almost all of the low level variant functions adds a couple of warnings: vartype.c:4118: warning: integer constant is too large for "long" type vartype.c:4118: warning: integer constant is too large for "long" type vartype.c:4118: warning: integer constant is too large for "long" type vartype.c:4119: warning: integer constant is too large for "long" type vartype.c:4119: warning: integer constant is too large for "long" type vartype.c:4119: warning: integer constant is too large for "long" type The problem is, that in the use of EXPECTDEC(0,0,0,0x100000000), the constant is 0x100000000 is too large for both long and unsigned long. This could be addressed by writing it as 0x100000000ULL (unsigned long long), but in that case the uses in the EXPECTDEC macro seem wrong, as they cast the value to long and unsigned long, respectively. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 0

Re: oleaut32 low level tests
by Dmitry Timoshkov 11 Dec '03

11 Dec '03

"Jon Griffiths" <jon_p_griffiths(a)yahoo.com> wrote: > Jon Griffiths <jon_p_griffiths(a)yahoo.com> > > +dlls/oleaut32/tests/vartype.c dlls/oleaut32/tests/Makefile.in > Test almost all of the low level variant functions The only failure I have here: vartype.c:3340: Test failed: hres=0x0, type=8 (should be VT_BSTR), *bstr='1' It's again win2k SP4 with Russian locale. -- Dmitry.

1 0

← Newer
1
...
16
17
18
19
20
21
22
...
27
Older →

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 December 2003