September 2010 - Wine-Devel

Re: Console issues in recent git

by Jerome Leclanche

It's a GUI. J. Leclanche On Thu, Sep 2, 2010 at 8:41 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > Le 02/09/2010 03:29, Jerome Leclanche a écrit : >> >> Anyone else's terminal emulators really acting up since the last git >> batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if >> there is a wine process running, until it's killed. This is probably a >> konsole bug, but still... >> >> CC eric. >> >> -- >> J. Leclanche >> >> >> > > not really > is the program you're running a CUI or GUI exec ? > if it's a CUI, then it's normal as it's supposed to get all your current > input > if it's a GUI (without a win32 console), then it's more questionnable > > A+ > > -- > Eric Pouech > "The problem with designing something completely foolproof is to > underestimate the ingenuity of a complete idiot." (Douglas Adams) > > > >

Sept. 2, 2010

Re: RFC: Compiling as 16 bit

by Morten Rønne

On 02-09-2010 21:21, Alexandre Julliard wrote: > Morten Rønne<morten.roenne(a)tdcadsl.dk> writes: > > >> 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? >> > I don't think it makes sense to invest time into developing a 16-bit > Winelib environment, and we certainly don't want to add 16-bit crap in > the standard Win32 headers. These things should be part of the 16-bit > compiler environment. > > I can understand that, but the problem is that in order to write proper test of the 16 bit environment I need to include the definitions of the structs that make up the 16 bit execution environment e.g. wine/winbase16.h and others. That file (and probably also the others) will in turn include windef.h and winbase.h, which will in turn include winnt.h and so on. Ending up in a problem due to size errors. Or are you saying that I should change wine/winbase16.h to not include windef.h and winbase.h and make sure that they don't include anything from "windows 32" include files? Or should I duplicate all those file for the test enviroment, so that I have to maintain the same structs in two different files? Best Regards Morten Rønne

Sept. 2, 2010

Re: Console issues in recent git

by Eric Pouech

Le 02/09/2010 03:29, Jerome Leclanche a écrit : > Anyone else's terminal emulators really acting up since the last git > batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if > there is a wine process running, until it's killed. This is probably a > konsole bug, but still... > > CC eric. > > -- > J. Leclanche > > > not really is the program you're running a CUI or GUI exec ? if it's a CUI, then it's normal as it's supposed to get all your current input if it's a GUI (without a win32 console), then it's more questionnable A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Sept. 2, 2010

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

by Dan Kegel

On Thu, Sep 2, 2010 at 7:20 PM, Morten Rønne <morten.roenne(a)tdcadsl.dk> wrote: >> Have you seen http://code.google.com/p/win16test/ ? > > I only get one file for all tests in one directory, e.g. the kernel32 tests > are in this file. > -rwxr-xr-x 1 mr mr 1548553 2010-08-23 20:11 kernel32_test.exe.so 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.

Sept. 2, 2010

Re: RFC: Compiling as 16 bit

by Alexandre Julliard

Morten Rønne <morten.roenne(a)tdcadsl.dk> writes: > 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? I don't think it makes sense to invest time into developing a 16-bit Winelib environment, and we certainly don't want to add 16-bit crap in the standard Win32 headers. These things should be part of the 16-bit compiler environment. -- Alexandre Julliard julliard(a)winehq.org

Sept. 2, 2010

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

by Morten Rønne

On 02-09-2010 20:47, Dan Kegel wrote: > On Thu, Sep 2, 2010 at 6:26 PM, Morten Rønne<morten.roenne(a)tdcadsl.dk> wrote: > >>> Have you seen http://code.google.com/p/win16test/ ? >>> >> Yes, I have seen those tests. But they run as independent programs for each >> test. Wine (as it is now) creates one big program that is able to run all >> tests. >> >> So I am not sure if it is acceptable to use that approach. >> > IIRC win16test mirrors Wine's approach exactly. Is the "one big program" > you're talking about programs/winetest? I think it bundles the little > executables > into an archive. There's no reason it can't bundle up the 16 bit apps > and run them. > - Dan > > I only get one file for all tests in one directory, e.g. the kernel32 tests are in this file. -rwxr-xr-x 1 mr mr 1548553 2010-08-23 20:11 kernel32_test.exe.so And when I ask programs/winetest to extract files only I end up with only one kernel32_test.exe file. And not every single test as it own program. I am aware that programs/winetest can bundle and run the testprograms as single entities, but that is not the way it is done for the windows 32 bit tests. So I would just like to be sure what would be accepted before I try to make a final patch series. Best Regards Morten Rønne

Sept. 2, 2010

RFC: Compiling as 16 bit

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

Sept. 2, 2010

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

by Dan Kegel

On Thu, Sep 2, 2010 at 6:47 PM, Dan Kegel <dank(a)kegel.com> wrote: > IIRC win16test mirrors Wine's approach exactly. Is the "one big program" > you're talking about programs/winetest? I think it bundles the little > executables > into an archive. There's no reason it can't bundle up the 16 bit apps > and run them. Though you might have to turn off upx in programs/winetest/Makefile.in for 16 bit executables...

Sept. 2, 2010

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

by Dan Kegel

On Thu, Sep 2, 2010 at 6:26 PM, Morten Rønne <morten.roenne(a)tdcadsl.dk> wrote: >> Have you seen http://code.google.com/p/win16test/ ? > > Yes, I have seen those tests. But they run as independent programs for each > test. Wine (as it is now) creates one big program that is able to run all > tests. > > So I am not sure if it is acceptable to use that approach. IIRC win16test mirrors Wine's approach exactly. Is the "one big program" you're talking about programs/winetest? I think it bundles the little executables into an archive. There's no reason it can't bundle up the 16 bit apps and run them. - Dan

Sept. 2, 2010

Re: AW: Please report mcicda (CDROM audio) test results

by Saulius Krasuckas

* On Thu, 2 Sep 2010, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > > According to http://de.wikipedia.org/wiki/Compact_Disc > "CD-Extra" is a multi-session disc. So it would be like Jeff Zaroyko's > disc. Yes, both K3B and "Nero Info Tool v2" reports two sessions on my disk. > I don't know whether he retried that one with the mcicda tests now in > git. It would be nice to indicate disks containing tracks of different types (sessions) in the log and to extract some info from the data track. Then we would know for sure :) Drive info would be also interesting to see in the log. > Wikipedia says that the Mixed Mode CDs have been largely replaced with > multi-session ones. Given Jeff's output it looks like mcicda only sees > the audio section of multi session discs. Care to confirm? Already done, it says: "no mixed data+audio CD": http://test.winehq.org/data/cc945706a4933cda0d204ba07a13e93fccb66d18/me_s2-… I haven't looked at the code and don't know MCI. Is there nothing more to be done with CD-Extra? S.

Sept. 2, 2010