- wine-devel - winehq.org

(fwd) Re: Serial port communication
by Rein Klazes 10 Mar '04

10 Mar '04

Hi, A bug reported in the users list. Because the reporter prefers just to work around the problem in his own code, I forward it here. In short: ReadFile reads a single byte alright from the serial port but at the same time returns an error GLE = ERROR_INVALID_PARAMETER. With multiple bytes there are no problems. There is a code snippet in the attached message. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: [DMUSIC] Improve dmusic loading
by Alexandre Julliard 10 Mar '04

10 Mar '04

Raphael <fenix(a)club-internet.fr> writes: > Changelog: > - debugstr_DMUS_OBJECTDESC more readable (not more limited to the 200 > characters of wine_dbg_sprintf) You should make it a separate dumping function instead of returning a single string, if the info is too large. Using a static buffer is not thread-safe. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: vsnprintf: glibc and win32 not compatible
by Jesse Allen 09 Mar '04

09 Mar '04

On Tue, Mar 09, 2004 at 01:45:59PM +0800, Jonathan Wilson wrote: > >Discovered an issue with null pointer passed for %s (Warcraft III likes to > >do that it seems). I handle it by printing "(null)". Other than that, it > >will > Have you made it do something usefull if the user passes a null for a wide > char string? (i.e. passes %S and a null string?) > (A reply to the list this time) OK, I have added %S and %C. They pretty much copy %s and %c. I have started to read through dlls/user/wsprintf.c to show me how it's really done. Though, it is not finished. So in the case if something asks for %S and gives a null pointer, it will do the same as %s and print "(null)". glibc does the same thing for %s and %ls. If anyone would like try the updated version they can download snprintf.c and snprintf.h, renamed since it implements snprintf now, from ftp://narf.dnip.net/ and copy it into dlls/msvcrt. Update Makefile.in and msvcrt.spec and it should work after that. But it it still very experimental and there is more to do. Jesse

1 0

Re: Contribution offer: Localization work
by Ivan Leo Murray-Smith 09 Mar '04

09 Mar '04

> Important: I did not want to change the sense of the original file. > Personally I think even bugs should be persistant between different > translations. ;-) Otherwise they would drift away from each other too > much (my opinion). On the other hand, I had to change some sections > slightly, as they would not make too much sense in german, could be > miss-interpreted or simply would sound ugly if translated very close to > the original. I don't know how the other translators handle this issue. As any latin student knows, you simply can't translate word by word, also you mustn't make a translation that sounds ugly. The important thing is that the file look as if it was written in the language you're translating to, not adapted from another one. Also, in computers it's important to use the same words that are already being used. For example, the italian translation of "Save file as" is "Salva file con nome" that literally means "Save the file with a name", so you can't translate literally, you have to use what is usually used for that functionality in other programs. Just go on as you have up to now. If you think something is wrong, send a patch that updates both the original and the translation. > If there is a translated Readme shouldn't there also be a translated licence > file? I'm sure there is already one translated available from GNU.org. Then > this should say LIZENZ instead of LICENSE. The GPL is licensed only for distribution without modification, you can't touch the GPL or the license information in any way shape or from. What you can do is add the translations released by the FSF, as long as you specify that the legally valid version is the english one.

1 0

unsubscribe banana67
by Andrew de Quincey 09 Mar '04

09 Mar '04

2 1

Re: Implement Drag List Control
by Dimitrie O. Paun 09 Mar '04

09 Mar '04

On March 9, 2004 2:20 pm, Robert Shearman wrote: > This patch adds full support for drag list common controls. There are no > known bugs, so as far as I am concerned this is 100% complete compared > to ComCtl32 v5.81 and probably v6.0 too. Nice! Now, to keep track of these things, I've added the following note to each of the controls that I have audited/fixed: * NOTE * * This code was audited for completeness against the documented features * of Comctl32.dll version 6.0 on Sep. 9, 2002, by Dimitrie O. Paun. * * Unless otherwise noted, we believe this code to be complete, as per * the specification mentioned above. * If you discover missing features, or bugs, please note them below. It would be nice to add something like this to the drag control as well (also, now that you have it fresh in your mind, maybe you can audit it against v6.0, as this is the version that I used for other controls). Take a look at dlls/comctl32/updown.c, dlls/comctl32/comboex.c, etc. for examples. -- Dimi.

1 0

Re: Wine as shared library patch
by Peter Dennis Bartok 09 Mar '04

09 Mar '04

Alexandre, et. al, Our WinMain doesn't get called because our patch prevents it. If it were to get called, we'd be on a different (Wine-created) stack, with all kinds of things that are hard to undo, like the exception handling, etc. The goal of my patch was to have minimal impact on Wine, and allow the *same* wine code/binaries to be used for regular use as well as shared library, so any future Wine version you create will automatically also support shared library use. I modeled the global __wine_shared_lib variable after the __wine_main_argX globals you introduced last year, assuming that following that style would create the least resistance of getting my patch accepted. Having Wine set up the TEB and stack environment and actually call our WinMain and us then trying to 'undo' that in WinMain creates potential for future breakage of our library, in case you change something related to the TEB & stack. Having a variable in kernel that prevents creation of these, on the other hand, is easy to maintain, and really has no impact on performance or coding. I will be happy to implement any suggestions you may have on how to solve it another way in a single codebase that doesn't intruce the potential of breaking it in the future. I may very well have overlooked something. Regards, Peter -----Original Message----- From: "Alexandre Julliard" <julliard(a)winehq.org> To: "Miguel de Icaza" <miguel(a)ximian.com> Cc: "Peter Dennis Bartok" <peter(a)novonyx.com>; "Robert Shearman" <R.J.Shearman(a)warwick.ac.uk>; <wine-devel(a)winehq.org> Date: 07 March, 2004 17:37 Subject: Re: Wine as shared library patch >Miguel de Icaza <miguel(a)ximian.com> writes: > >> Well, the issue is that our WinMain is never called, and we would >> rather not depend on this in our patch, but instead get the small >> global that says `Hey Wine, just return'. > >The global variable thing is ugly; we could export a different entry >point instead, but I'm not sure it's really necessary. Why doesn't >your WinMain get called? > >-- >Alexandre Julliard >julliard(a)winehq.org > > >

6 12

statvfs breakage
by Gerald Pfeifer 09 Mar '04

09 Mar '04

I'm afraid the following change date: 2004/03/05 21:03:46; author: julliard; state: Exp; Use statvfs instead of statfs, and provide a default implementation in libwine_port if necessary. is not portable, as seen on FreeBSD 4.8: acrux[71]:/sw/test/wine/libs/port% make /sw/gcc-3.3.2/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o statvfs.o statvfs.c statvfs.c: In function `statvfs': statvfs.c:60: error: structure has no member named `f_namelen' Would you mind adding an autoconf test for that? (I saw that there are already a couple of those for statvfs.) Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 1

Re: Warn If GetProcAddress Fails
by Kevin Koltzau 09 Mar '04

09 Mar '04

Many apps dynamically bind to entry points to determine if features in Windows are available as well, This may cause quite a few apps to report huge numbers of warnings when there is actually nothing wrong On Monday 08 March 2004 08:44 pm, Robert Shearman wrote: > Many applications dynamically bind to entry points and can fail in > strange ways if they are not found. This patch enables users to see any > failing GetProcAddress calls that could be responsible for bad > behaviour.

2 1

vsnprintf: glibc and win32 not compatible
by Jesse Allen 09 Mar '04

09 Mar '04

Hi, Here I have filed a bug on vsnprintf: http://bugs.winehq.org/show_bug.cgi?id=2075 Basically it says, without repeating, that vsnprintf called from glibc is not quite a suitable replacement for an actual msvcrt vsnprintf. An example is given to highlight a specific issue. I have a question on how should one approach fixing this? I have thought of two different ways: 1) Create our own vsnprintf version from scratch (fairly difficult) or 2) Create a wrapper for glibc's vsnprintf that translates win32ish format statements into a glibc friendly one. (not too bad and smaller patch) We could later move in a better or complete version to improve performance. The issue intrigues me, and I find that it should be resolved at some point. I'd like to get on the right path, so I'd at least start on something that will later be accepted. Thanks, Jesse

7 9

Cygwin under Wine
by Erik de Castro Lopo 08 Mar '04

08 Mar '04

Hi all, I'm interested in running Cygwin under Wine. When trying to run the cygwin bash.exe I get the following: fixme:console:SetConsoleCtrlHandler (0x61025d10,0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x61025d10,1) - no error checking or testing yet fixme:ntdll:NtQueryInformationToken (0x60,5,0x6167010c,44,0x4078ef5c): stub fixme:ntdll:NtQueryInformationToken (0x60,1,0x616700a4,44,0x4078ef5c): stub fixme:advapi:SetTokenInformation (0x60, TokenOwner, 0x616700a4, 44): stub fixme:ntdll:NtQueryInformationToken (0x60,6,0x4078ef68,3076,0x4078ef5c): stub fixme:ntdll:NtQueryObject Unsupported information class 1 fixme:ntdll:NtQueryObject Unsupported information class 1 fixme:psapi:GetProcessMemoryInfo (hProcess=0x30, 0x4078ecb0, 40): stub I've tried hacking the Wine version of GetProcessMemoryInfo and I've had a look at the Cygwin sources to see what they are actually doing with this function. Unfortunately, I am still at a loss as to whay Cygwin expects. Anybody got any ideas on how to fix this? Cheers, Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ Linux: Because rebooting is for adding new hardware

1 0

Re: Contribution offer: Localization work
by Ivan Leo Murray-Smith 08 Mar '04

08 Mar '04

Look at the programs directory, most programs can be translated. You're usually looking for a De.rc file, if it's missing, make a second copy of the En.rc file, and call it De.rc. Now translate the strings in the file. You then have to edit the header file, this may be another rc file. In can case you can find the file by running grep En.rc * in the programs directory. Open the file, and add #include "De.rc" in alphabetical order in the list of language rc files. Once you've done this, make a patch, so your work can be easily applied to the wine source tree, a howto is at http://www.winehq.com/site/sending_patches. Also note that quite a few dlls need translating too. The file may not always be En.rc, for example in dlls/commdlg it's called cdlg_En.rc Finally, one important thing is keeping the translations up to date, so you should update the translation every time there is a change in the english resource file. Don't forget to check that the existing translations are up to date and correct. Once you've done a patch, send it, in the email body or as an attachment, to wine-patches(a)winehq.com This should give you plenty of work for now :-) Ivan.

3 2

Re: _ftime patch
by Hans Leidekker 08 Mar '04

08 Mar '04

On Monday 08 March 2004 07:56, Johannes Gajdosik wrote: > I found that the _ftime-function only returns seconds, not milliseconds. > Therefore I would like to send you a patch that uses gettimeofday(). Your efforts are appreciated but an implementation that uses Win32 API's would be better since that would make msvcrt (and thus Wine) more portable. Right now msvcrt uses only two unix API's, times() and localtime(), and I was planning to get rid of those in order to make it build on MinGW. -Hans

2 1

RtlGetDaclSecurityDescriptor crash on NULL pointer
by Bobby Bingham 08 Mar '04

08 Mar '04

Installing winamp5 with winver=winxp reveals that the wma installer calls GetSecurityDescriptorDacl with pSecurityDescriptor == NULL, which then calls RtlGetDaclSecurityDescriptor, which immediately dereferences it and crashes. Reading MSDN indicates that pSecurityDescriptor may be NULL, but I don't know the first thing about NT security descriptors, and so I'm not sure what the right way to handle it is. But I thought I'd at least point it out so someone who does know could take a look. -- Bobby Bingham

1 0

ccache gives winebuild errors?
by Rein Klazes 08 Mar '04

08 Mar '04

Hallo, Since a couple of days make fails without giving much reason why: | make[3]: Entering directory `/usr/home/projects/wine/mywine/dlls/ddraw/tests' | WINEBUILD=../../../tools/winebuild/winebuild ../../../tools/winegcc/winegcc -mconsole ddrawmodes.o testlist.o -o ddraw_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../libs -lddraw -luser32 -lgdi32 -lkernel32 -lm | Error: ccache gcc failed. | make[3]: *** [ddraw_test.exe.so] Error 2 | make[3]: Leaving directory `/usr/home/projects/wine/mywine/dlls/ddraw/tests' | make[2]: *** [tests] Error 2 | make[2]: Leaving directory `/usr/home/projects/wine/mywine/dlls/ddraw' | make[1]: *** [ddraw] Error 2 | make[1]: Leaving directory `/usr/home/projects/wine/mywine/dlls' | make: *** [dlls] Error 2 This is after a "make clean". Wine is configured to use ccache by setting CC="ccache gcc" before the ./configure && make depend && make. After another make clean and setting CC=gcc, the make succeeds. Any idea? Rein. -- Rein Klazes rklazes(a)xs4all.nl

4 6

RE: Wine as shared library patch
by Robert Shearman 08 Mar '04

08 Mar '04

Peter Dennis Bartok wrote: > This patch allows to use Wine as a shared library. It will allow the > Mono project to use Wine as the backend for it's System.Windows.Forms > implementation. It looks as though Alexandre has done a good job with kernel32 and ntdll since the last time using Wine with Mono was mentioned on this list. > ChangeLog: > * Alters initialization code to return control to caller instead of > executing application if __wine_shared_lib flag is set. Perhaps this could be changed to a static variable in process.c > * Adds winelib executable (wine-sharedlib) that a consumer can use > to initialize Wine as a shared library, to load Wine DLLs and to import > functions from DLLs. wine-sharedlib doesn't look very clean at the moment. Tabs are inconsistent and you forgot to change MonoWineInit to SharedWineInit in one of the comments. Why do you link to kernel32 and user32 and then use dlsym to get the function address? What is VideoDLL supposed to be for? Why does the comment for WinMain say it is never called and then have a load of junk in it? If you can resolve these issues then we can have a single Wine for Win32 and S.W.F! Rob

4 7

RE: Add support for TB_GETMETRICS and TB_SETMETRICS messages
by Robert Shearman 07 Mar '04

07 Mar '04

Dmitry Timoshkov wrote: > > Hello, > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Add support for TB_GETMETRICS and TB_SETMETRICS messages. > > diff -u cvs/hq/wine/dlls/comctl32/toolbar.c wine/dlls/comctl32/toolbar.c > --- cvs/hq/wine/dlls/comctl32/toolbar.c 2004-03-07 > 17:24:46.000000000 +0800 > +++ wine/dlls/comctl32/toolbar.c 2004-03-07 18:12:44.000000000 +0800 > @@ -5871,6 +5871,60 @@ TOOLBAR_SysColorChange (HWND hwnd) > } > > > +static LRESULT TOOLBAR_GetMetrics(HWND hwnd, LPTBMETRICS lpMetrics) > +{ > + TOOLBAR_INFO *infoPtr = TOOLBAR_GetInfoPtr (hwnd); > + > + if (lpMetrics->cbSize != sizeof(TBMETRICS)) > + return 0; > + > + if (lpMetrics->dwMask & TBMF_PAD) > + { > + lpMetrics->cxPad = infoPtr->nButtonWidth; > + lpMetrics->cyPad = infoPtr->nButtonHeight; > + } > + if (lpMetrics->dwMask & TBMF_BARPAD) > + { > + lpMetrics->cxBarPad = infoPtr->nWidth; > + lpMetrics->cyBarPad = infoPtr->nHeight; > + } > + if (lpMetrics->dwMask & TBMF_BUTTONSPACING) > + { > + lpMetrics->cxButtonSpacing = infoPtr->szPadding.cx; > + lpMetrics->cyButtonSpacing = infoPtr->szPadding.cy; I don't think this is quite right. MSDN says that cxButtonSpacing is "Width of the space between toolbar buttons", where as padding is "used to create a blank area between the edge of the button and the button's image and/or text". If experimentation proves that they are the same then a nice comment saying MSDN is wrong would be appropriate. Rob

2 4

wine-20040213 doesn't compile on Linux w/ 2.6.3 kernel and gcc-3.3.3
by Tom Williams 07 Mar '04

07 Mar '04

I had successfully built wine-20040213 before upgrading to the 2.6.3 Linux kernel and XFree86 4.4.0. After upgrading to XFree86 4.4.0 (from source distribution), wine would crash when I would try to run a Windows app so I decided to rebuild wine so it would use the XFree86 4.4.0 headers and libs, etc. Now, when I compile wine-20040213, it stops with this compile error: make[2]: Leaving directory `/build/wine-20040213/dlls/newdev' make[2]: Entering directory `/build/wine-20040213/dlls/ntdll' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o cdrom.o cdrom.c In file included from /usr/include/linux/cdrom.h:14, from cdrom.c:63: /usr/include/asm/byteorder.h:14: error: syntax error before "__u32" /usr/include/asm/byteorder.h:28: error: syntax error before "__u64" In file included from /usr/include/linux/byteorder/little_endian.h:11, from /usr/include/asm/byteorder.h:57, from /usr/include/linux/cdrom.h:14, from cdrom.c:63: /usr/include/linux/byteorder/swab.h:133: error: syntax error before "__u16" /usr/include/linux/byteorder/swab.h:146: error: syntax error before "__u32" /usr/include/linux/byteorder/swab.h:160: error: syntax error before "__u64" make[2]: *** [cdrom.o] Error 1 make[2]: Leaving directory `/build/wine-20040213/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/build/wine-20040213/dlls' make: *** [dlls] Error 2 tom@linux:~/build/wine-20040213$ Based on this discussion on the gcc-help mailing list: http://gcc.gnu.org/ml/gcc-help/2004-03/msg00057.html it looks like the "__KERNEL__" option needs to be specified so that __attribute_const__ can be properly defined and cdrom.c can then be compiled. I haven't tried it yet but I'm guessing adding __KERNEL__ to the "extradefs" macro in the dlls/ntdll/Makefile.in file might do the trick. I'm going to try that now and see what happens. Has this problem already been encountered and addressed? Thanks... Peace... Tom

2 2

Wine and Macromedia in (Heise) News
by Stefan Leichter 06 Mar '04

06 Mar '04

Hello, in http://www.heise.de/newsticker/meldung/45275 (german only) it is states that Macromedia currently modifies their Web-Authoring-System Flash MX to run with wine. After that they like to port it to linux. Bye Stefan

2 1

winegcc and wrc
by Chris Seaton 06 Mar '04

06 Mar '04

I'm having problems with winegcc and wrc. Both were working great on my system but then I had to move to a different setup. wrc seems to work (it doesn't complain at all and produces an object file) but when I link the generated object file to all my program I get "Error: winewrap failed": ... winegcc -I../../library --debug -c -o obj/utilities.o utilities.c wrc -o obj/resources.o resources.rc winegcc -mwindows -o bin/cspassword.exe obj/*.o -L../../library/bin -lcspassword -lcomctl32 Error: winewrap failed. make: *** [bin/cspassword.exe] Error 2 I'm using the latest snapshot. As I said it was all working fine before I moved system. What could be causing this? Thanks, Chris Seaton

2 2

Crash running MS Word '97
by Dan Kegel 05 Mar '04

05 Mar '04

Yesterday's CVS crashes when I run Word '97 with it, load a (largish) document, and quit. I guess Wine is passing back a null pointer and Word doesn't like it. Here's the stack: Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x505be71e). Symbol hack_digit (0000:4007c890) is invalid In 32-bit mode. 0x505be71e (MSSP232.DLL.SpellCloseUdr+0x1b595 in MSSP232.DLL): movl 0x4(%esi),%ecx Wine-dbg>bt Backtrace: =>0 0x505be71e (MSSP232.DLL.SpellCloseUdr+0x1b595 in MSSP232.DLL) (ebp=4060dc94) 1 0x505b1db7 (MSSP232.DLL.SpellCloseUdr+0xec2e in MSSP232.DLL) (ebp=4060dcc4) 2 0x505a3ea8 (MSSP232.DLL.SpellCloseUdr+0xd1f in MSSP232.DLL) (ebp=40470002) 3 0x83c68900 (MSSP232.DLL..reloc+0x336a1900) (ebp=05bb11e8) *** Invalid address 0x05bb11e8 - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Rel.: Calmira.org
by RadchenkoSG＠yukos.ru 05 Mar '04

05 Mar '04

Please, fix this-> http://www.calmira.org (@Wine User Guide, p.53). This domain has been hijacked by a domain harvester. Calmira-team asks to remove all links to calmira.org from related pages and update them to it's new domain: calmira.net (<-http://www.calmira.de/, news). Respectfully, Sergey Radchenko.

1 0

Followup on Borland C++ 5.5
by Michael Pyne 05 Mar '04

05 Mar '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, If it helps, the patch that I was referred to a week or so ago regarding the linker for Borland C++ 5.5 hanging did work, after some modifications. It is attached to this message. Basically, I translated the VirtualAlloc() call into it's NtAllocateVirtualMemory() equivalent to solve the unresolved symbol errors, and just plain left out the check at the end of the function for the region size. Hope that's OK. Obviously this patch isn't suitable for inclusion into Wine proper since it seems to merely patch over a different problem. I've recompiled Wine with full debug information and such, and if someone knows what I should look for or do, I'd be more than willing to provide debug output to nail down the error. I've tracked down the infinite loop to NTDLL_wait_for_multiple_objects() in dlls/ntdll/sync.c. For some reason, whatever the program is waiting on doesn't ever seem to occur (unless, of course, the above patch is applied?!?). Please let me know if there's anything I can do to help close this bug permanently. :-) Regards, - Michael Pyne -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFASCZaqjQYp5Omm0oRAvWBAJ9M26Gct10rxLdPKJm5fHl3JPzDTQCgypIW NQ2wE4FNElbm5ohhuXvu7eA= =JcS+ -----END PGP SIGNATURE-----

1 0

Patch Status Check
by Mike Kost 05 Mar '04

05 Mar '04

Alexandre, Can you report on the status of the following patches. I havn't spotted them in CVS and they've been out there for almost 2 weeks now. Austerlitz patch #1 - play audio file with + in filename http://www.winehq.org/hypermail/wine-patches/2004/02/0287.html Austerlitz patch #2 - Calculate the DIB size http://www.winehq.org/hypermail/wine-patches/2004/02/0286.html The patches were tested and appear to solve bug #2011 http://bugs.winehq.org/show_bug.cgi?id=2011 Mike Kost mike at tashcorp dot net

2 1

Re: Fix for programs that store VirtualQueryEx results in signed integers (eg. The Borland Linker)
by Alexandre Julliard 05 Mar '04

05 Mar '04

Troy Rollo <wine(a)troy.rollo.name> writes: > + * The problem with emulating this is that on Linux the top of the stack is at > + * 0xbfffffff and below, so reserving even the balance of this range would > + * artificially limit stack growth. We could move the stack, but it's too late > + * to do that here because there will be pointers to things on the stack > + * that will be affected - moving the stack would need to be done in main() in > + * loader/main.c, which would then be responsible for moving it back (this would > + * be done with mremap and subsequent adjustment to the stack pointer). Actually we don't run on the main stack, so allocating the space above 0x80000000 would definitely be possible, the stack doesn't need to grow there. -- Alexandre Julliard julliard(a)winehq.org

3 8

WinCE application support for WINE and ReactOS
by Steven Edwards 04 Mar '04

04 Mar '04

Hello All, This is all very experimental. I am working on in the ReactOS tree and it might not even work for larger apps but I am happy with the results so far. I was thinking the other day that ReactOS and WINE/Linux might get a big boost if we can push support in the embedded enviroment so I started taking a look at WinCE and Microsoft Embedded Visual C++ 4.0 .BTW: Its a free download now. http://www.microsoft.com/downloads/details.aspx?FamilyID=1dacdb3d-50d1-41b2… I started looking at WinCE and thought it would be nice if we could be source compatible with WinCE apps and binary compatbile on x86. Well it seems that WinCE apps dont differ much from standard Win32 apps execpt the subsystem ID is differnt. If you attempt to run a WinCE application on Windows it will say that its not able to run. Ok no problem, we just run "editbin /subsystem:windows blah.exe" and check it out. Now the app is looking for coredll.dll. No problem there I have created a stub coredll.dll that just forwards all calls to the proper Win32 dlls such as user32, kernel32, etc..... .....and check it out. My little messagebox test works on Windows. Ok soon then I go and run the same test on ReactOS but this time I run a copy of messagebox without changing the subsystem ID...Hey what do you know. It works =). I talked with Alexandre about it a bit and he said that WINE like ReactOS also shouldnt care about the subsystem ID so if someone is interested in testing just drop the messagebox programs and coredll.dll in to a directory and give it a shot. I am having trouble getting more complex apps (hello world) to work atm so I think i am just going to take a break and clear my head for a few days. Some of the WinCE API and Win32 is not 100% compatible so we cant just forward all parts to the Win32 implementation but I think we can do it for most of it. If anyone is interested in helping out the source is in the ROS CVS tree and attached to this email...... binary.zip messagebox.exe - wince messagebox program msgbox.exe - wince messagebox program with subsystem id changed to Windows. wincehel.exe - Hello World WinCE app wincehelw.exe - Hello World WinCE app with subsystem id changed to Windows. coredll.dll - WinCE Win32 API commctl.dll - WInCE common controls API. source.zip coredll - dummy forwarder dll commctl - dummy stub dll for common controls Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster http://search.yahoo.com

1 0

WinCE application support for WINE and ReactOS
by Steven Edwards 04 Mar '04

04 Mar '04

Hello All, This is all very experimental. I am working on in the ReactOS tree and it might not even work for larger apps but I am happy with the results so far. I was thinking the other day that ReactOS and WINE/Linux might get a big boost if we can push support in the embedded enviroment so I started taking a look at WinCE and Microsoft Embedded Visual C++ 4.0 .BTW: Its a free download now. http://www.microsoft.com/downloads/details.aspx?FamilyID=1dacdb3d-50d1-41b2… I started looking at WinCE and thought it would be nice if we could be source compatible with WinCE apps and binary compatbile on x86. Well it seems that WinCE apps dont differ much from standard Win32 apps execpt the subsystem ID is differnt. If you attempt to run a WinCE application on Windows it will say that its not able to run. Ok no problem, we just run "editbin /subsystem:windows blah.exe" and check it out. Now the app is looking for coredll.dll. No problem there I have created a stub coredll.dll that just forwards all calls to the proper Win32 dlls such as user32, kernel32, etc..... .....and check it out. My little messagebox test works on Windows. Ok soon then I go and run the same test on ReactOS but this time I run a copy of messagebox without changing the subsystem ID...Hey what do you know. It works =). I talked with Alexandre about it a bit and he said that WINE like ReactOS also shouldnt care about the subsystem ID so if someone is interested in testing just drop the messagebox programs and coredll.dll in to a directory and give it a shot. I am having trouble getting more complex apps (hello world) to work atm so I think i am just going to take a break and clear my head for a few days. Some of the WinCE API and Win32 is not 100% compatible so we cant just forward all parts to the Win32 implementation but I think we can do it for most of it. If anyone is interested in helping out the source is in the ROS CVS tree and attached to this email...... binary.zip messagebox.exe - wince messagebox program msgbox.exe - wince messagebox program with subsystem id changed to Windows. wincehel.exe - Hello World WinCE app wincehelw.exe - Hello World WinCE app with subsystem id changed to Windows. coredll.dll - WinCE Win32 API commctl.dll - WInCE common controls API. source.zip coredll - dummy forwarder dll commctl - dummy stub dll for common controls Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster http://search.yahoo.com

1 0

Re: Make icon extraction for 16 bit icons work
by Alexandre Julliard 04 Mar '04

04 Mar '04

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Changelog: > Martin Pilka <mpilka(a)codeweavers.com> > Make icon extraction for 16 bit icons work. This should really be done with PrivateExtractIcons instead of adding more 16-bit dependencies in our Winelib apps. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: run authenticated over a NT domain aplications
by Juan Lang 04 Mar '04

04 Mar '04

Hi Marco, Marco escribio: > Hi , > i'm traying to run with wine a legacy aplication that > needs to be run by > a loged in user under NT Domain. That aplication > needs to be > authenticated on the server to access the SQL server. > Looking on google > i've found a post about logonUser patch from Martin > Wilks (snip) > Whi this patch was removed from the > development? Are you sure this patch solves the problem for you? Have you tried the application? What errors do you get? If the patch works, you can apply it to wine yourself and use your copy of wine. You can try resubmitting it to wine-patches and see what AJ says :) > Is there any other way to run aplications of those? The application queries SQL server? It may be possible to run the SQL server ODBC drivers; try doing a google search for this. Boaz Harrosh reported some success using the MS ODBC driver manager in Wine, see this thread: http://www.winehq.org/hypermail/wine-devel/2004/01/0466.html Good luck, --Juan __________________________________ Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster http://search.yahoo.com

1 0

Fwd: Fw: New setupapi stuff
by Steven Edwards 04 Mar '04

04 Mar '04

I am not going to have a chance to merge this. We have fixed a few more minor bugs in InstallHInfSection. Thanks Steven Note: forwarded message attached. __________________________________ Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster http://search.yahoo.com

1 0

(no subject)
by Ivan Leo Murray-Smith 04 Mar '04

04 Mar '04

The email http://www.winehq.com/hypermail/wine-patches/2004/03/0032.html contains a zip attachment, that contains a .scr file, chances are it's a virus. If it is, please remove it from the archive. Ivan.

1 0

Office '97 test: installer good, app not usable
by Dan Kegel 04 Mar '04

04 Mar '04

A friend wanted to borrow my old laptop while she's in the hospital, so I scurried around and got wvdial and fvwm95 working on my old 133MHz 48MB RAM, 1.1GB disk Redhat 6.2 laptop, then built the latest Wine. Ran into two minor problems, but basically it built just fine. Took all night, but hey, what do you expect for a 133MHz laptop? Then the real test: Office '97. The installer worked very, very well. Only flaw was some letters were cut off on the right hand side of the pacifier dialogs during install. This is the best I've seen it in the four or five years I've been trying this. Running Office was another matter. I only tested it a bit, but there's a display problem: text is displayed invisible in the main document pane on the same line you're editing. If you refresh, everything's there. Not terribly usable. Sigh. I guess I'll dig up the copy of Crossover I bought for testing a while ago. Wonder if that even works with such an old Linux, though... - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

4 4

RE: wine/ objects/dc.c dlls/x11drv/x11drv.spec dll ...
by Robert Shearman 04 Mar '04

04 Mar '04

> > Log message: > Changed the CreateDC driver entry point to use an HDC > instead of a DC > pointer. > > Patch: http://cvs.winehq.org/patch.py?id=11356 > > Old revision New revision Changes Path > 1.56 1.57 +1 -1 wine/dlls/x11drv/x11drv.spec > 1.26 1.27 +1 -1 wine/dlls/wineps/wineps.spec > 1.34 1.35 +1 -1 wine/dlls/ttydrv/ttydrv.spec [...] Why change the prototypes in the .spec files? The first parameter is still a pointer, even if it is now void* instead of DC*. Rob

2 1

tests for winsock and msvcrt won't link
by Dan Kegel 04 Mar '04

04 Mar '04

I updated to CVS yesterday, and now I get an error when building wine, namely: winsock and msvcrt tests won't link because they can't find accept and feof, respectively. Commenting out the SUBDIRS= lines in those two DLLs' Makefiles got me past it (I think; it's still building). This problem was not present in the most recent snapshot. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

3 4

avi file save is not work.
by kscho 04 Mar '04

04 Mar '04

Hi! when i test wine-20040121 , it works fine. but wine-2040213 is not work. the function of AVIMakeCompressedStream is not returned AVRERR_OK . i tested each dlls(avifil32.dl.so, ntdll.dll.so,...). finally i found i replace kernel32.dll.so(in the wine-20040121) it works fine. How I can do it ? Thanks in advance

2 1

X11DRV_GLX_CreateDriver
by Maurizio Monge 04 Mar '04

04 Mar '04

Hi, if found a commented X11DRV_GLX_CreateDriver in the x11drv dll, did anyone try to write a glx backend and stopped for some reason? I was just planning to write a OpenGL backend for directdraw (i.e. using glDrawPixels, etc), as i think it would be almost as fast as dga and far more stable, but does anyone think it would be a bad idea? Thanx Maurizio

3 2

want to debug winemine
by Guruprasad B. B. 04 Mar '04

04 Mar '04

Hi, i copied winemine source to a separate directory (winemine2) then i compiled winemine2 using winemaker. it created a shared object file (winemine2.exe.so). i am able to launch winemine2 application fine. what i want to do is debug the winemine source code.. say, i want to set a breakpoint in main.c( part of winemine source code) i can't do that unless i have a winemine2.exe. please help me figure out a way to debug this compiled source code thanks Guruprasad ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

1 0

WineHQ: fix some nasty problems in TODO
by Dimitrie O. Paun 04 Mar '04

04 Mar '04

This one is fairly high importance, the page looks rather crappy ATM. My bad, sorry for the mess. ChangeLog Properly finish the <a> tags marking the sections. -- Dimi. Index: templates/en/todo_lists.template =================================================================== RCS file: /home/wine/lostwages/templates/en/todo_lists.template,v retrieving revision 1.26 diff -u -r1.26 todo_lists.template --- templates/en/todo_lists.template 3 Mar 2004 19:34:28 -0000 1.26 +++ templates/en/todo_lists.template 4 Mar 2004 05:18:45 -0000 @@ -287,7 +287,7 @@ </ol> - <a name="ui"><h3> D. User Interface </h3> + <a name="ui"></a><h3> D. User Interface </h3> <ol> <li> Visible region handling in server <span class=inprogress>[IN PROGRESS]</span> <ul> @@ -305,7 +305,7 @@ </ol> - <a name="formats"><h3> E. File Formats </h3> + <a name="formats"></a><h3> E. File Formats </h3> <ol> <li> Finalize the .spec file format <span class=done>[DONE]</span> <ul> @@ -328,7 +328,7 @@ </ol> - <a name="api"><h3> F. Exported API </h3> + <a name="api"></a><h3> F. Exported API </h3> <ol> <li> Finish DLL separation Phase 1 <span class=done>[DONE]</span> <ul> @@ -353,7 +353,7 @@ </ol> - <a name="tools"><h3> G. Tools </h3> + <a name="tools"></a><h3> G. Tools </h3> <ol> <li> Winebuild: build DLLs from .def files <span class=done>[DONE]</span> <ul> @@ -412,7 +412,7 @@ </ol> - <a name="misc"><h3> H. Miscellaneous </h3> + <a name="misc"></a><h3> H. Miscellaneous </h3> <ol> <li> Testing daemon to run as a Windows service <span class=inprogress>[IN PROGRESS]</span> <ul> @@ -454,7 +454,7 @@ </ol> - <a name="code"><h3> I. Source Code </h3> + <a name="code"></a><h3> I. Source Code </h3> <ol> <li> Move controls/*, windows/* -> dlls/user/ <span class=inprogress>[IN PROGRESS]</span> <ul>

1 0

kernel32.dll.so isn't work with video for window(AVIMakeCompressedStream)
by kscho 04 Mar '04

04 Mar '04

Hi~, I runed avi related program work with wine-20040121, It works fine. thanks this~ but I tested wine-20040213, AVIMakeCompressedStream isn't work properly, therefore not returned GetAvailableSystemCodec in my function. below is my test code. when i replace kernel32.dll.so (in the wine-20040121) it works. How can I do? thanks in advance -----------------------my test code ------------------------------ #define AVIIF_KEYFRAME 0x00000010L // this frame is a key frame. static const struct tREC_FOURCC{ FOURCC fcc; char *name; } recommended_fcc[] = { { mmioFOURCC('m','p','4','3'), "mpeg4_3" }, // Microsoft MPEG4 V3 { mmioFOURCC('m','p','4','2'), "mpeg4_2" }, // Microsoft MPEG4 V2 { mmioFOURCC('d','i','v','x'), "divx" }, { mmioFOURCC('I','V','5','0'), "indeo_5" }, { mmioFOURCC('I','V','4','0'), "indeo_4" }, }; static char empty_audio_frame[SAMPLED_SMSIZE_8*4]; BOOL GetAvailableSystemCodec(PAVIWRITER paw) { int i; if(paw->ip.flags & AW_CODEC_FORCCC) { paw->opts.fccHandler = paw->ip.codecFourcc; paw->codec_name = NULL; if(AVIERR_OK == AVIMakeCompressedStream(&paw->psCompressed, paw->ps, &paw->opts, NULL)) { return TRUE; } } memset(&paw->opts, 0, sizeof(paw->opts)); for(i=0; i<sizeof(recommended_fcc)/sizeof(struct tREC_FOURCC); i++) { paw->opts.fccHandler = recommended_fcc[i].fcc; paw->codec_name = recommended_fcc[i].name; if(AVIERR_OK == AVIMakeCompressedStream(&paw->psCompressed, paw->ps, &paw->opts, NULL)) { return TRUE; } } return FALSE; }

1 0

run authenticated over a NT domain aplications
by Marco Rodriguez M. 03 Mar '04

03 Mar '04

Hi , i'm traying to run with wine a legacy aplication that needs to be run by a loged in user under NT Domain. That aplication needs to be authenticated on the server to access the SQL server. Looking on google i've found a post about logonUser patch from Martin Wilks ( http://www.winehq.org/hypermail/wine-patches/2002/11/0110.html) that works with pam and winbind. Whi this patch was removed from the development? Is there any other way to run aplications of those? Are there some one who can help me to or have a tutorial or a HOWTO to run this kind of aplications? Or maybe i'ts imposible for now.... i hope not, this is very improtant to completely migrate propietary aplication an legacy sistem to O.S. T.I.A. -- Marco Rodriguez M. marco[(a)]ubiobio.cl U. Bio Bio Concepcion Chile

1 0

Re: Re: Native NetBSD audio driver
by wine＠frotz.org 03 Mar '04

03 Mar '04

> What is the plan for combining these audio drivers? One thing that is common > to each driver are the functions that handle the wave headers, adding, > removing > etc. I understand the desire to extract common code from drivers that have largely been cut and paste from the OSS driver's boilerplate, but I hope this merge won't restrict new drivers to an implementation that uses this boilerplate. I'm developing from the ground up a new ALSA/OpenAL driver which I intend to provide a "best quality" PCM DirectSound experience for gaming. The driver uses ALSA's DMIX plugin device, so it should interoperate with similarly configured arts, jack, etc. servers. It supports secondary buffers and 3D. The intent is to take advantage of HW support for these features when available. As yet I have had no need to reuse code from the OSS driver. Legacy waveOut/ waveIn interfaces will be implemented using the driver's DirectSound interfaces. The driver is very pre-alpha and development is admittedly very slow. However, when it is ready -- if there is interest -- I would like to post it to wine-patches for code review and addition to CVS. --d

1 0

ImmAssociateContextEx missing
by Jesse Allen 03 Mar '04

03 Mar '04

Hi, I have noticed that when you load up Warcraft III, and then quit the game, that it will pop up with a messagebox error message complaining about a memory location, 0xdeadbeef. I have also noticed this message: err:win32:PE_fixup_imports No implementation for imm32.dll.2(ImmAssociateContextEx) imported from C:\war3\war3.exe, setting to 0xdeadbeef I looked for ImmAssociateContextEx in imm32, and its not there, not even in the imm32.spec file. I implemented a stub for ImmAssociateContextEx, and then ran the game. It now comes up with my stub message upon exiting the game: fixme:imm:ImmAssociateContextEx (0x20021, (nil), 16): stub So apparently war3.exe has a reference to ImmAssociateContextEx, and detects the bad address, and immediately exits with an error. Applying the patch allows the game to exit normally. I have the patch attached. Any comments? Jesse --- wine/dlls/imm32/imm.c 2004-03-02 13:55:57.000000000 -0700 +++ wine-new/dlls/imm32/imm.c 2004-03-02 16:49:23.000000000 -0700 @@ -255,6 +255,15 @@ } /*********************************************************************** + * ImmAssociateContextEx (IMM32.@) + */ +BOOL WINAPI ImmAssociateContextEx(HWND hWnd, HIMC hIMC, DWORD dwFlags) +{ + FIXME("(%p, %p, %ld): stub\n", hWnd, hIMC, dwFlags); + return FALSE; +} + +/*********************************************************************** * ImmConfigureIMEA (IMM32.@) */ BOOL WINAPI ImmConfigureIMEA( --- wine/dlls/imm32/imm32.spec 2004-02-02 17:12:03.000000000 -0700 +++ wine-new/dlls/imm32/imm32.spec 2004-03-02 16:21:47.000000000 -0700 @@ -1,4 +1,5 @@ @ stdcall ImmAssociateContext(long long) +@ stdcall ImmAssociateContextEx(long long long) @ stdcall ImmConfigureIMEA(long long long ptr) @ stdcall ImmConfigureIMEW(long long long ptr) @ stdcall ImmCreateContext()

2 1

Re: Native NetBSD audio driver
by Yorick Hardy 03 Mar '04

03 Mar '04

I started now with the integration of the OSS and NetBSD audio drivers. Before I get too far, I would like to hear suggestions/criticisms. 1) I created the directory dlls/winmm/drvcommon (perhaps there is a better name ?) 2) moved dlls/winmm/wineoss/oss.c and dlls/winmm/winenbsd/nbsd.c to the single integrated file dlls/winmm/drvcommon/drv.c. 3) renamed the files dlls/winmm/wineoss/oss.h and dlls/winmm/winenbsd/nbsd.h to dlls/winmm/wineoss/drv.h and dlls/winmm/winenbsd/drv.h respectively. 4) Update the respective Makefile.in to use the integrated dlls/winmm/drvcommon/drv.c The idea is that eventually winenbsd and wineoss only have the drv.h and the spec file. drv.h will define all driver specific names/functions. I must stress that I am only concerned with the OSS and NetBSD drivers at the moment. Is this too much? Or can someone suggest a better solution? Kind regards, -- Yorick Hardy Tel: +2711 489 3640 | Fax: +2711 489 2067 | Office: C-Ring 517 Auckland Park Campus | Rand Afrikaans University | South Africa Department of Applied Mathematics : http://general.rau.ac.za/apm Standard Bank Academy for Information Technology : http://csweb.rau.ac.za

3 3

Re: SysParametersInfoW->A crosscall (fixed)
by tony_lambregts＠telusplanet.net 03 Mar '04

03 Mar '04

Alexandre, is there any reason that this patch isn't applied? http://www.winehq.org/hypermail/wine-patches/2004/02/0332.html -- Tony Lambregts

2 1

Re: winemaker fixes
by Dimitrie O. Paun 02 Mar '04

02 Mar '04

On Tue, 2 Mar 2004, Francois Gouget wrote: > winemaker is pretty broken since it has been patched to call winegcc. I > suspect it was not tested. Hey, I can't do everything! :))) I just wanted to get the ball rolling. > We must specify '-lmsvcrt' if using the msvcrt. Please don't, it's not needed. If you want to use msvcrt, please pass the -mno-cygwin switch. if that doesn' work, it's a bug in winegcc. > There is still work to do: > > 1. Linking with uuid is broken. I suspect winegcc finds the Unix > /lib/libuuid.so first and links with that instead of with our libuuid.a > library. That shouldn't happen. Can you please run winegcc with the -v flag, and send the output my way please? > 2. wrc does not find 'windows.h' (yes, some RC files #include Win32 > headers). wrc should know about the location of the headers like winegcc > (since our Makefile don't know anything about where the Wine headers are > anymore). I've verified the source and it should. Maybe you can produce a --debug=FF trace? > 4. We have lost the autoconf integration. We should encapsulate our macros so they can conveniently be used by people in their configure.ac scripts. I think that's the proper way to get autoconf integration. > 5. Nothing works if Wine has not been installed. This is quite > impractical for Wine developers. It's true, but there are many reasons you need to install Wine to be able to use Winelib. I doubt it will change in the near future. > 6. winegcc is not rebuilt if the '--prefix' changes. Maybe AJ can fix the Makefile. I think winegcc.o should depend on the Makefile. > 7. Building dlls does not work yet but that was expected and Dimi is > working on it. In progress :) -- Dimi.

3 2

Re: Native NetBSD audio driver
by Eric Pouech 02 Mar '04

02 Mar '04

Yorick Hardy a écrit : > This patch adds the audio driver winenbsd using the native NetBSD > audio system as an alternative to OSS. On the one hand > this is useful to directly make use of the features of the NetBSD > audio system instead of using emulation, on the other hand > it is another driver to maintain and is quite close to the wineoss driver. > If the driver is accepted, I think the NetBSD support for wineoss > should remain for testing and for the main driver. I really think we're starting to create a real mess for the audio drivers. It's always useful to have drivers access the HW at the lowest level, so we should support NetBSD. However, if the iface is rather close to OSS, I'd rather suggest we try to integrate all the drivers with the same features into a single piece of driver > diff -urN /home/yorick/software/wine/wine/dlls/Makefile.in ./dlls/Makefile.in > --- /home/yorick/software/wine/wine/dlls/Makefile.in Sat Feb 14 19:20:00 2004 > +++ ./dlls/Makefile.in Sat Feb 21 23:43:35 2004 > @@ -1745,6 +1749,7 @@ > winmm/winejack/winejack.drv$(DLLEXT): winmm/winejack > msacm/winemp3/winemp3.acm$(DLLEXT): msacm/winemp3 > winmm/winenas/winenas.drv$(DLLEXT): winmm/winenas > +winmm/winenas/winenbsd.drv$(DLLEXT): winmm/winenbsd *** this should be winenbsd A+

7 8

Cross compiling Wine with MinGW
by Hans Leidekker 02 Mar '04

02 Mar '04

Hi, I spent some time cross compiling all of Wine with MinGW according to this recipe: http://winehq.com/?issue=123#Cross-compiling Wine and I thought you might be interested in the results. I can report a bug in Wine's makefiles right away: having those vxd's in subdirectories that end in .vxd causes make to barf on targets like this one: ifsmgr.vxd$(DLLEXT): ifsmgr.vxd/ifsmgr.vxd$(DLLEXT) $(RM) $@ && $(LN_S) ifsmgr.vxd/ifsmgr.vxd$(DLLEXT) $@ because, if $(DLLEXT) is empty, it will try to create a link with a name that's already there as a directory. Of all dlls these don't compile: x11drv kernel32 gdi32 ws2_32 comctl32 icmp iphlapi msvcrt ntdll rpcrt4 shlwapi vnb.vxd wininet wsock32 x11drv, kernel32, gdi32 and ntdll being predictable, because they build directly on X11 and Unix API's. Same goes for the networking related dlls (ws2_32, icmp and iphlpapi, vnb.vxd, wininet, wsock32). msvcrt is close to building because what I saw was mostly header clashes, which could be fixed with proper guards I think. rpcrt4 fails because it uses one Unix API, gettimeofday, and both comctl32 and shlwapi suffer from the bug in dlltool that Dmitry reported and fixed recently. -Hans

3 3

Re: Re: Native NetBSD audio driver
by chmorgan＠charter.net 02 Mar '04

02 Mar '04

What is the plan for combining these audio drivers? One thing that is common to each driver are the functions that handle the wave headers, adding, removing etc. I'm also weary of any kind of combination that includes OSS as OSS is depreciated and has been replaced by Alsa. I'm also concerned with the arts, jack and nas drivers being left out of this merge. While many of the audio drivers have a lot in common there are a LOT of subtle differences that are necessary for things to work correctly. Maybe Eric and others could comment on what they see as being able to be combined, although I've worked a bit on audio drivers I'm drawing mostly a blank. Thanks, Chris > > From: Yorick Hardy <yha(a)na.rau.ac.za> > Date: 2004/03/02 Tue AM 04:38:41 EST > To: wine-devel(a)winehq.org > CC: yha(a)na.rau.ac.za > Subject: Re: Native NetBSD audio driver > > I started now with the integration of the OSS and NetBSD audio drivers. > Before I get too far, I would like to hear suggestions/criticisms. > > 1) I created the directory dlls/winmm/drvcommon > (perhaps there is a better name ?) > 2) moved dlls/winmm/wineoss/oss.c and dlls/winmm/winenbsd/nbsd.c > to the single integrated file dlls/winmm/drvcommon/drv.c. > 3) renamed the files dlls/winmm/wineoss/oss.h and dlls/winmm/winenbsd/nbsd.h > to dlls/winmm/wineoss/drv.h and dlls/winmm/winenbsd/drv.h respectively. > 4) Update the respective Makefile.in to use the integrated > dlls/winmm/drvcommon/drv.c > > The idea is that eventually winenbsd and wineoss only have the drv.h > and the spec file. drv.h will define all driver specific names/functions. > I must stress that I am only concerned with the OSS and NetBSD drivers > at the moment. > > Is this too much? Or can someone suggest a better solution? > > Kind regards, > > -- > Yorick Hardy > Tel: +2711 489 3640 | Fax: +2711 489 2067 | Office: C-Ring 517 > Auckland Park Campus | Rand Afrikaans University | South Africa > Department of Applied Mathematics : http://general.rau.ac.za/apm > Standard Bank Academy for Information Technology : http://csweb.rau.ac.za > > >

1 0

Re: winegcc: portability
by Kirill Smelkov 02 Mar '04

02 Mar '04

1 Март 2004 05:52, Dimitrie O. Paun написал: > OK, this is it. I've included the new config.h.in for > patch review convenience. Please run > > autoheader > autoconf > > after applying it. With this stuff in the tree, we should > be able to build programs/* with it. Next on the list is > -shared support... > > ChangeLog > Instrument winegcc to use the compilers and options detected > at configure time. Add support for parsing/formatting a string > array from/to a char string. Add option to disable short wchar > support in winegcc. And what about next (removed from winemaker by your recent patch) -fpermissive, -fms-extensions -fno-for-scope ? They are very handy when porting win32 apps. -- Kirill.

2 3

Re: Cross compiling Wine with MinGW
by Hans Leidekker 02 Mar '04

02 Mar '04

On Sunday 29 February 2004 20:49, Juan Lang wrote: > > Shouldn't wininet build on ws2_32 and thus compile? > > I think it should be investigated... > > wininet currently depends on OpenSSL and BSD (unix) > sockets. I think the way OpenSSL is being used makes > it rather hard to use ws2_32 instead, but if someone > wants to take that on that would help. I'm trying to > implement SSL in secur32.dll so wininet can use this, > but it will take me a while (it's rather large). > Helpers welcome :) > > I can fix up vnb.vxd, it really should build on MinGW, > whether or not it's useful to do so. I'll send a > patch shortly. If I include winsock2.h, get rid of the sys/socket.h, netinet/in.h and arpa/inet.h includes and additionally link to ws2_32 it builds on MinGW as well as Wine. > Hans, why didn't wsock32 build? It looks like > configure should protect you against missing headers > and whatnot; it mostly forwards to iphlpapi and > ws2_32. It's missing some constants: ../../../wine/dlls/wsock32/protocol.c:144: `SOCK_STREAM' undeclared (first use in this function) ../../../wine/dlls/wsock32/protocol.c:155: `SOCK_DGRAM' undeclared (first use in this function) These are in winsock.h but protocol.c only includes winsock2.h When I change the include to winsock.h I get: ../../../wine/include/winsock.h:25:4: #error Please use Winsock2 in Wine winsock2.h says: FIXME: Still missing required Winsock 2 definitions. MinGW and MSVC versions of winsock2.h have the defines, so I guess we need to add them. Attached patch does so. -Hans Changelog: add protocol type constants.

2 2

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