Re: Windows 7 64-bit?
On Fri, 26 Jul 2013 22:49:55 +0100 Ken Sharp wrote: > > > On 26/07/13 19:42, Rosanne DiMesio wrote: > > But admins no longer have the power to delete users, so there's nothing I > > can do to stop him from continually resubmitting it. > > This is a real pain. Was it intentional or a bug that's slipped in? > > I believe it was taken away after the AppDB was hacked a couple of years ago. -- Rosanne DiMesio
Re: Windows 7 64-bit?
On 26/07/13 19:42, Rosanne DiMesio wrote: But admins no longer have the power to delete users, so there's nothing I can do to stop him from continually resubmitting it. This is a real pain. Was it intentional or a bug that's slipped in?
Re: Windows 7 64-bit?
On Fri, 26 Jul 2013 16:47:36 +0100 Ken Sharp wrote: > I have to ask: > > Do we really think that this user is running Wine 1.0.1 on Windows 7 64-bit? > http://appdb.winehq.org/objectManager.php?sClass=version&iId=28587&iTestingId=79589 > > No; letting it through was my mistake. This was actually the third time he submitted it. The previous two times I caught it and told him to select a valid distro, but I missed it this time. I realized it after I had approved it and have already deleted the whole entry. The user who keeps submitting it is market...@smartpixel.com, so I doubt this is anything more than a ploy to improve his site's search engine ranking. But admins no longer have the power to delete users, so there's nothing I can do to stop him from continually resubmitting it. -- Rosanne DiMesio
Re: Windows 7 64-bit?
Am 26.07.2013 17:47, schrieb Ken Sharp: > I have to ask: > > Do we really think that this user is running Wine 1.0.1 on Windows 7 64-bit? > http://appdb.winehq.org/objectManager.php?sClass=version&iId=28587&iTestingId=79589 > > Ask him what he really wanted to choose.
Windows 7 64-bit?
I have to ask: Do we really think that this user is running Wine 1.0.1 on Windows 7 64-bit? http://appdb.winehq.org/objectManager.php?sClass=version&iId=28587&iTestingId=79589
Re: iphlpapi: sync spec file to Windows 7 (1/2)
Austin English writes: > From the keeping Focht happy/thanking him for debugging my bugs department :) New stubs should be commented out until there is evidence that some application is using them. -- Alexandre Julliard julli...@winehq.org
Re: Matching Windows 7 folder locations?
Hello Dan, wdrwo> Windows 7 changed the folders in c:/users/$USERNAME around a bit. not only 'a bit'. There are a lot of changes in the folder structure since Vista: See URL: <http://msdn.microsoft.com/en-us/library/dd378457(v=VS.85).aspx> -- Joerg Schiermeier
Re: Matching Windows 7 folder locations?
Hi, Note that these changes were introduced in Windows Vista, so applications that are being actively maintained should have no issues with these changes. Also note that on localized versions localized folder names link to the English physical folder, so the folder structure is more consistenc across localized versions of Windows. Legacy applications on the other hand are a different story and application compatibility hacks have to be used anyway. Changing shell folder names and and linking legacy names is most likely a working solution since that also was introducted in Windows Vista and was not refined in Windows 7. Kornél Jerome Leclanche wrote: I suspect there are badly behaved apps on both sides of the road, however these apps are legitimately broken; would they even work on a non-english version of windows? If there was a choice to be made though, for what it's worth, I always hated the spaces too. J. Leclanche On Fri, Apr 22, 2011 at 10:30 PM, Dan Kegel wrote: Windows 7 changed the folders in c:/users/$USERNAME around a bit. My Documents is now just a link to the new folder Documents Application Data is now just a link to the new folder AppData/Roaming Local Settings is now just a link to the new folder AppData/Local How is this going to affect Wine? Well-behaved apps that use CSIDL_PERSONAL to get at "My Documents" or "Documents" will work regardless, but users or badly behaved apps might start expecting the shorter directory names sometime. (I always hated the spaces, anyway.)
Re: Matching Windows 7 folder locations?
I suspect there are badly behaved apps on both sides of the road, however these apps are legitimately broken; would they even work on a non-english version of windows? If there was a choice to be made though, for what it's worth, I always hated the spaces too. J. Leclanche On Fri, Apr 22, 2011 at 10:30 PM, Dan Kegel wrote: > Windows 7 changed the folders in c:/users/$USERNAME around a bit. > > My Documents is now just a link to the new folder Documents > Application Data is now just a link to the new folder AppData/Roaming > Local Settings is now just a link to the new folder AppData/Local > > How is this going to affect Wine? Well-behaved apps that use > CSIDL_PERSONAL to get at "My Documents" or "Documents" will > work regardless, but users or badly behaved apps might start expecting > the shorter directory names sometime. (I always hated the spaces, anyway.) > > >
Matching Windows 7 folder locations?
Windows 7 changed the folders in c:/users/$USERNAME around a bit. My Documents is now just a link to the new folder Documents Application Data is now just a link to the new folder AppData/Roaming Local Settings is now just a link to the new folder AppData/Local How is this going to affect Wine? Well-behaved apps that use CSIDL_PERSONAL to get at "My Documents" or "Documents" will work regardless, but users or badly behaved apps might start expecting the shorter directory names sometime. (I always hated the spaces, anyway.)
Re: shell32/tests: Fix IShellFolderView test failure under Windows 7.
On 8 November 2010 17:32, Reece Dunn wrote: > On 8 November 2010 04:45, Austin Lund wrote: >> On 8 November 2010 11:49, James McKenzie wrote: >>> Thus a second test case needs to be >>> developed that is only for Windows7 and the remaining test skipped for >>> Windows7. Something like what we do for Unicode tests for Windows9x/ME. >> >> Isn't the rule that the tests should only check windows versions >> before testing behaviour if that is what applications to a similar >> thing, otherwise the test isn't required? > > The rule is not to check Windows version, but to infer the DLL version > (e.g. by checking for methods only available in newer versions of > Windows). That way, installing a new version of shlwapi.dll via > Internet Explorer on older systems does not break those tests. That seems like a test which is necessarily true, but not sufficient. If the DLL ABI does not change the tests results might. In the spirit of the rule described on the wiki (and quoted above), it would seem highly unusual for a program to test for the presence or absence of an unrelated function before depending on some result. The use of broken() has taken me a while to understand. I believe it is better understood as not "broken" in particular, but a behaviour that wine should not reproduce but sometimes windows might (or does).
Re: shell32/tests: Fix IShellFolderView test failure under Windows 7.
On 8 November 2010 04:45, Austin Lund wrote: > On 8 November 2010 11:49, James McKenzie wrote: >> Thus a second test case needs to be >> developed that is only for Windows7 and the remaining test skipped for >> Windows7. Something like what we do for Unicode tests for Windows9x/ME. > > Isn't the rule that the tests should only check windows versions > before testing behaviour if that is what applications to a similar > thing, otherwise the test isn't required? The rule is not to check Windows version, but to infer the DLL version (e.g. by checking for methods only available in newer versions of Windows). That way, installing a new version of shlwapi.dll via Internet Explorer on older systems does not break those tests. In this case, the older behaviour is deprecated, so at least needs a: todo_wine ok(broken(hr == S_OK) /* <= Vista */ || hr == E_FAIL /* Win7 */, ...) or the test case needs to be removed (as different versions of Windows have conflicting behaviour, so applications cannot rely on either). If an application requires this to work the test should be: ok(hr == S_OK /* Required by SomeApp */ || broken(hr == E_FAIL) /* Win7 */, ...) - Reece
Re: shell32/tests: Fix IShellFolderView test failure under Windows 7.
On 8 November 2010 11:49, James McKenzie wrote: > Thus a second test case needs to be > developed that is only for Windows7 and the remaining test skipped for > Windows7. Something like what we do for Unicode tests for Windows9x/ME. Isn't the rule that the tests should only check windows versions before testing behaviour if that is what applications to a similar thing, otherwise the test isn't required?
Re: shell32/tests: Fix IShellFolderView test failure under Windows 7.
On 11/7/10 6:41 PM, David Hedberg wrote: On Mon, Nov 8, 2010 at 01:22, Vitaliy Margolen wrote: -ok(hr == S_OK, "got (0x%08x)\n", hr); +ok(hr == S_OK || hr == E_FAIL /* Win7 */, "got (0x%08x)\n", hr); This can't be correct. It either works or it fails. Can't be both at the same time. You should look into why it's failing on Win7 and correct the test so it succeeds. I guess it makes the test a bit less useful for catching any errors, but reading between the lines at msdn makes me suspect that passing NULL for the pidl here simply doesn't work under Windows 7. I just tried the same thing on a IShellFolderView created from the windows directory and it gave the same result (still the default shellview I guess). Assuming for the moment that this is indeed the only result you'd ever get, should I find a way to skip it on windows 7 or mark one of the results as broken? I don't quite see either alternative as very helpful in this case, but I might be wrong. Just my .02 USD (in other words, 2 cents) as a long term QA person, not as a Wine Developer. A test should not fail unless that is the desired result. However, marking an existing test as having new failure condition is not correct. Now, it may be true that the test passes up to and including Windows2008 but now fails on Windows7. Thus a second test case needs to be developed that is only for Windows7 and the remaining test skipped for Windows7. Something like what we do for Unicode tests for Windows9x/ME. This is not the first test that a failure will be a pass on Windows7 where a failure is not desired on prior versions of Windows. Unfortunately, I don't know what to do at this point, but maybe there is a new function that exists only in Windows7 for shell32 that can be used for the test. James McKenzie
Re: shell32/tests: Fix IShellFolderView test failure under Windows 7.
On Mon, Nov 8, 2010 at 01:22, Vitaliy Margolen wrote: >> >> - ok(hr == S_OK, "got (0x%08x)\n", hr); >> + ok(hr == S_OK || hr == E_FAIL /* Win7 */, "got (0x%08x)\n", hr); > > This can't be correct. It either works or it fails. Can't be both at the > same time. You should look into why it's failing on Win7 and correct the > test so it succeeds. > I guess it makes the test a bit less useful for catching any errors, but reading between the lines at msdn makes me suspect that passing NULL for the pidl here simply doesn't work under Windows 7. I just tried the same thing on a IShellFolderView created from the windows directory and it gave the same result (still the default shellview I guess). Assuming for the moment that this is indeed the only result you'd ever get, should I find a way to skip it on windows 7 or mark one of the results as broken? I don't quite see either alternative as very helpful in this case, but I might be wrong. David
Re: shell32/tests: Fix IShellFolderView test failure under Windows 7.
On 11/07/2010 04:06 PM, David Hedberg wrote: -ok(hr == S_OK, "got (0x%08x)\n", hr); +ok(hr == S_OK || hr == E_FAIL /* Win7 */, "got (0x%08x)\n", hr); This can't be correct. It either works or it fails. Can't be both at the same time. You should look into why it's failing on Win7 and correct the test so it succeeds. Vitaliy
Re: [1/5] d3d9: Ignore a Windows 7 failure in the d3d9 depth clamp test
You might as well just set the initial value to 1.0. Note that this seems to succeed on at least some setups though: http://test.winehq.org/data/4d3aec55ea41cb0f47a9da82de1665ad1b16f3de/win7_Win7-x86/d3d9:visual.html Also, does this work for the d3d8 version of the test?
Re: kernel32/tests: Pass test on error code returned by Windows 7
--- On Mon, 10/5/09, Paul Vriens wrote: From: Paul Vriens Subject: Re: kernel32/tests: Pass test on error code returned by Windows 7 To: "Dmitry Kislyuk" Cc: wine-devel@winehq.org Date: Monday, October 5, 2009, 12:49 AM On 10/05/2009 05:09 AM, Dmitry Kislyuk wrote: > > > --- On *Sun, 10/4/09, Paul Vriens //* wrote: > > > From: Paul Vriens > Subject: Re: kernel32/tests: Pass test on error code returned by > Windows 7 > To: dim...@rocketmail.com > Cc: wine-devel@winehq.org > Date: Sunday, October 4, 2009, 4:20 AM > > On 10/04/2009 09:10 AM, Dmitry Kislyuk wrote: > >> + ok( GetLastError() == 0xdeadbeef || GetLastError() == 2 /* Win > 7 */, > >> + "expected 0xdeadbeef or 2, got %d\n", GetLastError()); > > >Don't use magic numbers, ERROR_FILE_NOT_FOUND would be better. > > >-- Cheers, > > >Paul. > > Hi Paul, > > All of the tests in this group of tests are the same way. Magic > numbers instead of defines. I wanted to stay consistent with that. > > If Alexandre doesn't apply it I will resend with using > ERROR_FILE_NOT_FOUND per your suggestion. > > Thank you for looking at my patch. > > Dmitry > >Hi Dmitry, >The 'magical numbers' you are talking about in profile.c are not error >codes but the return values from for example GetPrivateProfileStringA >(number of characters). >-- >Cheers, >Paul. Thank you, I modified the patch and resent it. Dmitry
Re: kernel32/tests: Pass test on error code returned by Windows 7
On 10/05/2009 05:09 AM, Dmitry Kislyuk wrote: --- On *Sun, 10/4/09, Paul Vriens //* wrote: From: Paul Vriens Subject: Re: kernel32/tests: Pass test on error code returned by Windows 7 To: dim...@rocketmail.com Cc: wine-devel@winehq.org Date: Sunday, October 4, 2009, 4:20 AM On 10/04/2009 09:10 AM, Dmitry Kislyuk wrote: >> + ok( GetLastError() == 0xdeadbeef || GetLastError() == 2 /* Win 7 */, >> + "expected 0xdeadbeef or 2, got %d\n", GetLastError()); >Don't use magic numbers, ERROR_FILE_NOT_FOUND would be better. >-- Cheers, >Paul. Hi Paul, All of the tests in this group of tests are the same way. Magic numbers instead of defines. I wanted to stay consistent with that. If Alexandre doesn't apply it I will resend with using ERROR_FILE_NOT_FOUND per your suggestion. Thank you for looking at my patch. Dmitry Hi Dmitry, The 'magical numbers' you are talking about in profile.c are not error codes but the return values from for example GetPrivateProfileStringA (number of characters). -- Cheers, Paul.
Re: kernel32/tests: Pass test on error code returned by Windows 7
--- On Sun, 10/4/09, Paul Vriens wrote: From: Paul Vriens Subject: Re: kernel32/tests: Pass test on error code returned by Windows 7 To: dim...@rocketmail.com Cc: wine-devel@winehq.org Date: Sunday, October 4, 2009, 4:20 AM On 10/04/2009 09:10 AM, Dmitry Kislyuk wrote: >> + ok( GetLastError() == 0xdeadbeef || GetLastError() == 2 /* Win 7 */, >> + "expected 0xdeadbeef or 2, got %d\n", GetLastError()); >Don't use magic numbers, ERROR_FILE_NOT_FOUND would be better. >-- Cheers, >Paul. Hi Paul, All of the tests in this group of tests are the same way. Magic numbers instead of defines. I wanted to stay consistent with that. If Alexandre doesn't apply it I will resend with using ERROR_FILE_NOT_FOUND per your suggestion. Thank you for looking at my patch. Dmitry
Re: kernel32/tests: Pass test on error code returned by Windows 7
On 10/04/2009 09:10 AM, Dmitry Kislyuk wrote: +ok( GetLastError() == 0xdeadbeef || GetLastError() == 2 /* Win 7 */, +"expected 0xdeadbeef or 2, got %d\n", GetLastError()); Don't use magic numbers, ERROR_FILE_NOT_FOUND would be better. -- Cheers, Paul.
Re: Windows 7
2009/4/3 Austin English : > On Fri, Apr 3, 2009 at 3:06 PM, Henri Verbeet wrote: >> 2009/4/3 Austin English : >>> I'm not sure what the dwbuildnumber should be, I can't find that >>> information anywhere...Anywho, this should work. >>> >> RC1 was 0x1b9c, I think. > > Where do you get that information from? > The screenshot in the wikipedia article :-) (http://upload.wikimedia.org/wikipedia/en/b/bd/Windows_7.png) Although if someone had an actual copy you could just call GetVersionEx().
Re: Windows 7
On Fri, Apr 3, 2009 at 3:06 PM, Henri Verbeet wrote: > 2009/4/3 Austin English : >> I'm not sure what the dwbuildnumber should be, I can't find that >> information anywhere...Anywho, this should work. >> > RC1 was 0x1b9c, I think. Where do you get that information from? > The final build number isn't known yet, of > course, which is also a reason why it doesn't make sense to add thise > before it's actually released. That's why I didn't submit it to wine-patches ;-). -- -Austin
Re: Windows 7
2009/4/3 Austin English : > I'm not sure what the dwbuildnumber should be, I can't find that > information anywhere...Anywho, this should work. > RC1 was 0x1b9c, I think. The final build number isn't known yet, of course, which is also a reason why it doesn't make sense to add thise before it's actually released.
Re: Windows 7
On Fri, Apr 3, 2009 at 2:32 PM, David Gerard wrote: > Austin and I were trying to work it out last night from the Win 7 beta > :-) Is there any software on Earth that looks specifically for Windows > 7 as yet? I had my roommate try CPU-Z, but it shows Windows Vista. -- -Austin
Re: Windows 7
2009/4/3 Austin English : > On Thu, Apr 2, 2009 at 3:58 PM, Stefan Dösinger > wrote: >> Am Donnerstag, 2. April 2009 13:07:18 schrieb Fred .: >>> Yeah, I know. >>> It is on the way though. It will be released. >>> So I would like to be able to choose Windows 7. >> Feel free to send a patch ;-) > I'm not sure what the dwbuildnumber should be, I can't find that > information anywhere...Anywho, this should work. Austin and I were trying to work it out last night from the Win 7 beta :-) Is there any software on Earth that looks specifically for Windows 7 as yet? - d.
Re: Windows 7
On Thu, Apr 2, 2009 at 3:58 PM, Stefan Dösinger wrote:
> Am Donnerstag, 2. April 2009 13:07:18 schrieb Fred .:
>> Yeah, I know.
>> It is on the way though. It will be released.
>> So I would like to be able to choose Windows 7.
> Feel free to send a patch ;-)
>
I'm not sure what the dwbuildnumber should be, I can't find that
information anywhere...Anywho, this should work.
--
-Austin
diff --git a/dlls/ntdll/version.c b/dlls/ntdll/version.c
index bf9db4d..cd8e61c 100644
--- a/dlls/ntdll/version.c
+++ b/dlls/ntdll/version.c
@@ -53,6 +53,7 @@ typedef enum
WIN2K3, /* Windows 2003 */
WINVISTA,/* Windows Vista */
WIN2K8, /* Windows 2008 */
+WIN7,/* Windows 7 */
NB_WINDOWS_VERSIONS
} WINDOWS_VERSION;
@@ -148,6 +149,12 @@ static const RTL_OSVERSIONINFOEXW
VersionData[NB_WINDOWS_VERSIONS] =
sizeof(RTL_OSVERSIONINFOEXW), 6, 0, 0x1771, VER_PLATFORM_WIN32_NT,
{'S','e','r','v','i','c','e',' ','P','a','c','k',' ','1',0},
0, 0, VER_SUITE_SINGLEUSERTS, VER_NT_SERVER, 0
+},
+/* WIN7 */
+{
+sizeof(RTL_OSVERSIONINFOEXW), 6, 1, 0x1772, VER_PLATFORM_WIN32_NT,
+{' ',0},
+0, 0, VER_SUITE_SINGLEUSERTS, VER_NT_WORKSTATION, 0
}
};
@@ -166,6 +173,7 @@ static const char * const
WinVersionNames[NB_WINDOWS_VERSIONS] =
"win2003,win2k3", /* WIN2K3 */
"vista,winvista", /* WINVISTA*/
"win2008,win2k8", /* WIN2K8 */
+"win7", /* WIN7 */
};
diff --git a/programs/winecfg/appdefaults.c b/programs/winecfg/appdefaults.c
index 28ec4fe..2a102ab 100644
--- a/programs/winecfg/appdefaults.c
+++ b/programs/winecfg/appdefaults.c
@@ -48,6 +48,7 @@ static const struct
const char *szProductType;
} win_versions[] =
{
+{ "win7","Windows 7", 6, 1, 0x1772,VER_PLATFORM_WIN32_NT, " ",
0, 0, "WinNT"},
{ "win2008", "Windows 2008", 6, 0, 0x1771,VER_PLATFORM_WIN32_NT,
"Service Pack 1", 0, 0, "ServerNT"},
{ "vista", "Windows Vista", 6, 0, 0x1770,VER_PLATFORM_WIN32_NT, " ",
0, 0, "WinNT"},
{ "win2003", "Windows 2003", 5, 2, 0xECE, VER_PLATFORM_WIN32_NT,
"Service Pack 1", 1, 0, "ServerNT"},
Re: Windows 7
Am Donnerstag, 2. April 2009 13:07:18 schrieb Fred .: > Yeah, I know. > It is on the way though. It will be released. > So I would like to be able to choose Windows 7. Feel free to send a patch ;-)
Re: Windows 7
Yeah, I know. It is on the way though. It will be released. So I would like to be able to choose Windows 7. On Thu, Apr 2, 2009 at 8:32 AM, Austin English wrote: > On Wed, Apr 1, 2009 at 6:34 AM, Fred . wrote: >> I can put Windows XP, Vista, 2003, 2008. But not Windows 7. >> >> >> > > It's not officially released yet, it's still a beta. > > -- > -Austin >
Re: Windows 7
On Wed, Apr 1, 2009 at 6:34 AM, Fred . wrote: > I can put Windows XP, Vista, 2003, 2008. But not Windows 7. > > > It's not officially released yet, it's still a beta. -- -Austin
Windows 7
I can put Windows XP, Vista, 2003, 2008. But not Windows 7.
Re: [TOOLS] Add Windows 7
James Hawkins wrote:
> On Sat, Jan 10, 2009 at 3:32 AM, Paul Vriens
> wrote:
>> Hi,
>>
>> We have our first Windows 7 test results :
>> http://test.winehq.org/data/a69c86d3f517f659ba47495f77deac2df671fb03/vista_windows7-virtualbox/version.html
>>
>> I'm not sure if '7' is a nice/correct header though. Maybe "Win7" ?
>>
>> This also means we need to add it to winecfg.
>>
>> Changelog
>> Add Windows 7
>>
>> --
>> Cheers,
>>
>> Paul.
>>
>>
>> >From b8ec6ca34b85f7ba1ae736ef35ee380b1b5721f0 Mon Sep 17 00:00:00 2001
>> From: Paul Vriens
>> Date: Sat, 10 Jan 2009 12:28:57 +0100
>> Subject: [PATCH] Add Windows 7
>>
>> ---
>> winetest/build-index |3 ++-
>> winetest/dissect |6 --
>> winetest/gather |6 --
>> 3 files changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/winetest/build-index b/winetest/build-index
>> index 2813ae8..0f257ad 100755
>> --- a/winetest/build-index
>> +++ b/winetest/build-index
>> @@ -27,11 +27,12 @@ my %xp = (name => "XP");
>> my %w2k3= (name => "2003");
>> my %vista = (name => "Vista");
>> my %w2k8= (name => "2008");
>> +my %w7 = (name => "7");
>> my %unknown = (name => "Other");
>> my %wine= (name => "Wine");
>>
>
> I'm behind on my emails this weekend, so I don't know if this has been
> committed yet or not, but it seems like win7 is a better name than w7.
>
Just sent a new patch to fix this differently.
('w7' btw is the internally used name. '7' would be what you see as the header
on test.winehq.org.)
--
Cheers,
Paul.
Re: [TOOLS] Add Windows 7
Austin English wrote: > On Sun, Jan 11, 2009 at 11:24 PM, James Hawkins wrote: >> On Sat, Jan 10, 2009 at 3:32 AM, Paul Vriens >> wrote: >>> Hi, >>> >>> We have our first Windows 7 test results : >>> http://test.winehq.org/data/a69c86d3f517f659ba47495f77deac2df671fb03/vista_windows7-virtualbox/version.html >>> >>> I'm not sure if '7' is a nice/correct header though. Maybe "Win7" ? >>> >>> This also means we need to add it to winecfg. >>> >>> Changelog >>> Add Windows 7 >>> >>> -- >>> Cheers, >>> >>> Paul. >>> >>> >>> >From b8ec6ca34b85f7ba1ae736ef35ee380b1b5721f0 Mon Sep 17 00:00:00 2001 >>> From: Paul Vriens >>> Date: Sat, 10 Jan 2009 12:28:57 +0100 >>> Subject: [PATCH] Add Windows 7 >>> >>> --- >>> winetest/build-index |3 ++- >>> winetest/dissect |6 -- >>> winetest/gather |6 -- >>> 3 files changed, 10 insertions(+), 5 deletions(-) >>> >>> diff --git a/winetest/build-index b/winetest/build-index >>> index 2813ae8..0f257ad 100755 >>> --- a/winetest/build-index >>> +++ b/winetest/build-index >>> @@ -27,11 +27,12 @@ my %xp = (name => "XP"); >>> my %w2k3= (name => "2003"); >>> my %vista = (name => "Vista"); >>> my %w2k8= (name => "2008"); >>> +my %w7 = (name => "7"); >>> my %unknown = (name => "Other"); >>> my %wine= (name => "Wine"); >>> >> I'm behind on my emails this weekend, so I don't know if this has been >> committed yet or not, but it seems like win7 is a better name than w7. >> >> -- >> James Hawkins >> >> >> > > Is Windows 7 the beta name, or the finalized name? Perhaps we should > wait until it's finalized? The main reason for this patch was to not clutter the Vista group with this Windows 7 stuff. Maybe a patch that moves version 6.1 to "Other" is better for now? Or we can explicitly check for 6.0 which means 6.1 will be moved to 'Other" automagically. I'll sent a new patch. We can than worry about Windows 7 (or whatever the name will be) when time comes. -- Cheers, Paul.
Re: [TOOLS] Add Windows 7
On Sun, Jan 11, 2009 at 11:24 PM, James Hawkins wrote: > On Sat, Jan 10, 2009 at 3:32 AM, Paul Vriens > wrote: >> Hi, >> >> We have our first Windows 7 test results : >> http://test.winehq.org/data/a69c86d3f517f659ba47495f77deac2df671fb03/vista_windows7-virtualbox/version.html >> >> I'm not sure if '7' is a nice/correct header though. Maybe "Win7" ? >> >> This also means we need to add it to winecfg. >> >> Changelog >> Add Windows 7 >> >> -- >> Cheers, >> >> Paul. >> >> >> >From b8ec6ca34b85f7ba1ae736ef35ee380b1b5721f0 Mon Sep 17 00:00:00 2001 >> From: Paul Vriens >> Date: Sat, 10 Jan 2009 12:28:57 +0100 >> Subject: [PATCH] Add Windows 7 >> >> --- >> winetest/build-index |3 ++- >> winetest/dissect |6 -- >> winetest/gather |6 -- >> 3 files changed, 10 insertions(+), 5 deletions(-) >> >> diff --git a/winetest/build-index b/winetest/build-index >> index 2813ae8..0f257ad 100755 >> --- a/winetest/build-index >> +++ b/winetest/build-index >> @@ -27,11 +27,12 @@ my %xp = (name => "XP"); >> my %w2k3= (name => "2003"); >> my %vista = (name => "Vista"); >> my %w2k8= (name => "2008"); >> +my %w7 = (name => "7"); >> my %unknown = (name => "Other"); >> my %wine= (name => "Wine"); >> > > I'm behind on my emails this weekend, so I don't know if this has been > committed yet or not, but it seems like win7 is a better name than w7. > > -- > James Hawkins > > > Is Windows 7 the beta name, or the finalized name? Perhaps we should wait until it's finalized? -- -Austin
Re: [TOOLS] Add Windows 7
On Sat, Jan 10, 2009 at 3:32 AM, Paul Vriens wrote: > Hi, > > We have our first Windows 7 test results : > http://test.winehq.org/data/a69c86d3f517f659ba47495f77deac2df671fb03/vista_windows7-virtualbox/version.html > > I'm not sure if '7' is a nice/correct header though. Maybe "Win7" ? > > This also means we need to add it to winecfg. > > Changelog > Add Windows 7 > > -- > Cheers, > > Paul. > > > >From b8ec6ca34b85f7ba1ae736ef35ee380b1b5721f0 Mon Sep 17 00:00:00 2001 > From: Paul Vriens > Date: Sat, 10 Jan 2009 12:28:57 +0100 > Subject: [PATCH] Add Windows 7 > > --- > winetest/build-index |3 ++- > winetest/dissect |6 -- > winetest/gather |6 -- > 3 files changed, 10 insertions(+), 5 deletions(-) > > diff --git a/winetest/build-index b/winetest/build-index > index 2813ae8..0f257ad 100755 > --- a/winetest/build-index > +++ b/winetest/build-index > @@ -27,11 +27,12 @@ my %xp = (name => "XP"); > my %w2k3= (name => "2003"); > my %vista = (name => "Vista"); > my %w2k8= (name => "2008"); > +my %w7 = (name => "7"); > my %unknown = (name => "Other"); > my %wine= (name => "Wine"); > I'm behind on my emails this weekend, so I don't know if this has been committed yet or not, but it seems like win7 is a better name than w7. -- James Hawkins
Windows 7
I read an interesting article on slashdot today: http://tech.slashdot.org/tech/08/04/04/1437258.shtml > Windows 7 will be a from-the-ground-up packaging of the Windows codebase; > partially source, > but not binary compatible with previous versions of Windows." Sounds like they format, i.e. maybe they use sth. other than PE then. But even if they don't, I guess this could be a problem for the existing wine codebase and require some infrastructural changes to it. However, I don't know much about these things though and it's possible that I'm completely wrong, but I though I'd just post this to wine-devel in case anybody is interested. Feel free to discuss, or not to discuss, do whatever you want with this information ;-) Maybe we're lucky and people turn away from windows completely this time and we don't even need to care about Windows 7 xD (though this is unlikely to happen, but dreams never die...) Best regards, Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/index.html
