wine-devel September 2010

116 participants
356 discussions

by Morten Rønne

This is related to the creation of the DOS test programs for which I have sent another mail. But this is a more generic question relating to the fact that openwatcom is a 16 bit compiler while gcc (of course) is a 32 bit compiler. Currently this have lead me to drop the inclusion of the files windef.h and winbase.h, because the definitions created aren't of the correct size (int is 16 bit, not 32 bit and so on). I am looking for a way to change windef.h so that it will create the correct base types for both 16 and 32 bit compile. Openwatcom defines the symbol __I86__ while compiling for 16 bit, is it acceptable that I use that to create 16 bit types? It seems that _MSC_VER will change a few cases of int to long, but far from enough. Is _MSC_VER intended to be a 16 bit compile flag? Or should I use something else more wine like (e.g. __WINE_16BIT_COMPILE). Also compiling 16 bit give some errors in other include files (after I have defined proper sizes for the 16 bit compile) ../../../include/winnt.h(3529): Error! E1040: Field width too large #ifdef BITFIELDS_BIGENDIAN unsigned NameIsString:1; unsigned NameOffset:31; #else unsigned NameOffset:31; unsigned NameIsString:1; #endif As it can be seen the include file uses unsigned directly and not a type like DWORD or ULONG that would be a "safe" 32 bit. Would it be acceptable to change this and others to a "proper" type which I know to be size safe? Best Regards Morten Rønne

13 years, 8 months

Re: [1/3] dsound: Add support for 32-bit IEEE float buffers

by Chris Robinson

On Thursday, September 02, 2010 1:38:29 pm Owen Rudge wrote: > These patches add support to DirectSound that allow the conversion of > 32-bit IEEE float audio buffers to PCM. Some games (e.g., Call of Duty > 5) output their audio in this format, and media players such as > foobar2000 have support for it too. You'll probably want to make sure the float values are clamped between -1 and +1 before converting, otherwise they'll wrap and cause bad static noise.

13 years, 8 months

Re: RFC: test of 16 bit wine (DOS)

by Dan Kegel

On Thu, Sep 2, 2010 at 7:50 PM, Morten Rønne <morten.roenne(a)tdcadsl.dk> wrote: >> Oh, right, win16test's Makefile and probably its test.h are kind of >> simpleminded. >> You probably want to have just one 16 bit test app per dll. >> Hopefully the test cases from win16test will be a useful starting point >> aside from their wimpy build system. > > I would like to avoid the dll part as DOS doesn't know about that and > "simply" run the program directly with tools/run_test. You might have misunderstood. By DLL I just meant the part of Wine that you're testing. In the case of DOS, the tests should probably go in krnl386.exe16/tests. > I will make some tests to see what I can fit into the test system, so it > works the same way other tests do, but as a "standalone" test. Good. That's exactly what I did with win16test. The missing part is integrating into the Wine build sytem. - Dan

13 years, 8 months

re: RFC: test of 16 bit wine (DOS)

by Dan Kegel

Morten Rønne wrote: > I have been working on creating tests for the 16 bit implementation of wine Great! Have you seen http://code.google.com/p/win16test/ ? That's for Win16 binaries, not DOS, but it might have some similarities. For instance, it also uses openwatcom. I had trouble back then getting the Linux version of openwatcom to produce win16 binaries, so I used 'winetricks openwatcom' to install the windows version. - Dan

13 years, 8 months

Please report mcicda (CDROM audio) test results

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Wine's testbt job #4280 http://testbot.winehq.org/JobDetails.pl?Key=4280 contains both a patch and a binary for new MCICDA=MCI CD-audio tests. It already contains most of what I want in the initial release but would benefit from testing on a broad range of native MS systems. Please invoke it as: mcicda_test.exe mcicda (it generates many failures on Wine but I already wrote several patches to fix them.) Some failures are still possible as there are a few rough edges, e.g. mcicda.c:222: Test failed: info upc: 0=NOERROR mcicda.c:322: Test failed: PLAY data to 00291d10: MCIERR_OUTOFRANGE mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped. It skips tests if - there's no disk in drive; - there are no audio tracks; Untested: blank RW disk Questions: - Is this patch right in mcicda/tests/ or should it be part of winmm/tests/? - Which kind of tests should I restrict to WINETEST_INTERACTIVE mode only? People may start to complain in the near future that running the Wine testsuite starts spinning their CD-ROM and even play music. (like somebody observed that the MIDI testsuite plays a few notes). Thank you for your contributions, Jörg Höhle

13 years, 8 months

Re: winmm/tests: Share common function dbg_mcierr.

by testbot＠testbot.winehq.org

13 years, 8 months

Our wiki disallows chinese text?

by Dan Kegel

The chap I mentioned earlier is starting off by trying to translate wiki pages into Chinese. http://wiki.winehq.org/FrontPage now has a Chinese entry at the bottom, but there's a hitch: when I try putting a bit of chinese text into http://wiki.winehq.org/Chinese the wiki refuses to save it, saying Sorry, can not save page because "葡" is not allowed in this wiki Is that because we don't have anyone who can monitor the wiki for chinese spam? How can we allow creation of Chinese pages? - Dan

13 years, 8 months

Re: [PATCH 5/6] winmm/tests: MCI_STATUS returns DWORD_PTR, unlike other commands.

by testbot＠testbot.winehq.org

13 years, 8 months

Mono integration, and when do we ship Mono with Wine?

by Vincent Povirk

Dan Kegel recently listed this as a possible 1.4 goal: > Mono integration similar to the current Gecko integration He may have meant one or both of the following things: 1. A more-or-less complete mscoree.dll that works based on the mono embedding api, as well as replacements for all the utilities that ship with .NET. 2. A wine-mono package similar to the current wine-gecko package to be installed automatically in new prefixes. I am making very slow progress with 1. I believe the current major shortcomings are functions that create COM wrappers for managed objects (ClrCreateManagedInstance and DllGetClassObject) and functions that search for and load different .NET versions (I believe these will be needed so that the managed objects we create will load and function properly). Mono already provides COM wrappers, so all we have to do is create the objects and pass COM wrappers to applications. I'm making this judgment based on the limited pool of mscoree bugs in the Wine bugzilla. I wish more people would file bugs when Mono doesn't work. I figure 2 can't be very technically difficult in and of itself, but when will we be ready to do that? What are the requirements? Do we want to go the "offer to download and install on first use" route first, and if so when will we be ready for that? Do those functions I mentioned earlier have to actually work first? The one hard requirement I have and have not met is that a working mono package can be built by me using only free software and that I can explain the build process to other people. I can do this for the core runtime and libraries, but I cannot do this for the gluezilla dependency. This gluezilla thing is sort of explained here: http://www.mono-project.com/WebBrowser Basically, .NET provides a web browser control, which Mono implements based on Gecko (or, optionally, WebKit). The official installer of Mono for Windows, which is what anyone who uses Mono in Wine uses, ships with Mozilla. It also ships with gluezilla, which is a C++ library that helps the managed code link Gecko. I don't think it'd be acceptable to leave out WebBrowser support. I am not currently able to create a Windows build of gluezilla or gecko using only free software. As I understand it, the official Windows build relies on Visual Studio. I do not know whether it's feasible for gluezilla to link to wine gecko, so that we don't have to install two versions of gecko. I also know that shipping gluezilla and gecko on Windows is wrong. Mono's wiki tells me that it's possible in .NET to access the underlying IE embedding objects through the winforms api, and those only exist if we're embedding IE. So the correct approach is to embed IE (in this case, Wine's IE replacement) by writing another WebBrowser backend. I don't know how hard that is. Maybe it'd make a good Summer of Code project? So, does anyone have other requirements, or thoughts on resolving the WebBrowser requirement?

13 years, 8 months

Re: [5/5] msi/test: Add tests for 64-bit properties.

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4928 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8387: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8398: Test failed: Expected "C:\winetest\", got "" package.c:8409: Test failed: Expected "C:\winetest\", got "" package.c:8459: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8470: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8479: Test failed: Expected "C:\", got "" package.c:8485: Test failed: Expected "C:\winetest\", got "" package.c:8506: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8515: Test failed: Expected "C:\winetest\FileName1", got ""

13 years, 8 months

Jump to page:

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 September 2010