>Windows Virtual PC is in fact a new product starting with Windows 7.
Windows Virtual PC is just a later and a bit crippled version of MS Virtual PC 2004/2007, which grew out of Connectix Virtual PC.
It’s NOT HyperV. Client HyperV is included with WIndows 8.
It should be evident I knew that already when I said “I have used Windows Virtual PC it and its predecessors for driver development for years and years”. But thanks for backing me on yet another example of deteriorating development tools.
That’s the reason that’s been cited. THEY say (not me, so don’t pile on) that apps commonly use GetVersionEx to determine compatibility (so-called “you must be this high to ride” checks).
You have been using an outdated, crippled, virtual machine system for years for something that it was not intended to support… and you use the fact that this same old, crippled, outdated, hacked-up, niche-market piece of software that you used is no longer maintained as the reason the “development environment is deteriorating”?
That’s just plain odd, but you know… If that suits you, go for it. What you see is a function of where you sit, after all.
Peter
OSR
xxxxx@gmail.com wrote:
I thought your opening post illustrated pretty well. Devcon does not cope well with the emergence of 64-bit processors and limited users. I don’t know what you call it, but I will say it in all caps to emphasize my position. I call that DETERIORATING.
Your position is unreasonable. Run the 64-bit tool on the 64-bit
system. Problem solved.
And, you need to remember that Devcon is a SAMPLE. Many people think
of it as a finished tool, but it’s not. It is a SAMPLE that
demonstrates how to use the SetupDi APIs. If you want it to warn you
in a 32/64 mixup, well go FIX it. You have the source code.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
xxxxx@osr.com wrote:
That’s the reason that’s been cited. THEY say (not me, so don’t pile on) that apps commonly use GetVersionEx to determine compatibility (so-called “you must be this high to ride” checks).
Let us look for a moment at the problems with that position.
(1) 15 years. That’s how long Microsoft has warned people not to do
this. It’s been in the documentation. If someone has written an
application in 2012 that ignores a 15 year old warning, they pretty much
deserve what they get, no matter how large of a customer they are.
(2) The idiom is “you must be at least this high to ride”. No one with
a brain has done “you must be exactly this high to ride” since the 20th
Century, and people without brains don’t count. An app that checks for
8.0 is going to continue to work when told it is running 8.1. Thus, I
do not believe for a MOMENT that there is one single application that
would actually break had this functionality been left intact.
(3) Let’s assume there ARE some brainless idiots who did write a “you
must be exactly this high to ride” test, and who complained to Microsoft
about it. How many of those apps do you suppose there are? I’ll wager
real dollars I could count them with my fingers. Does that justify
destroying a perfectly good API and breaking all those existing binaries
that used the API for informational purposes?
We’ve heard before how many decisions are driven by “appcompat”. I
assert that, in this case, that process failed miserably.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
You give app developers way too much credit. The number of apps that break when we change the version number (and nothing else in the OS) is in the high 80%+ last time I looked. In that light, lying about the version number solves that problem quite cleanly (clearly at the cost of the remaining %age that don’t break)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, September 13, 2013 9:46 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 32-Bit DEVCON on 64-Bit Windows
xxxxx@osr.com wrote:
That’s the reason that’s been cited. THEY say (not me, so don’t pile on) that apps commonly use GetVersionEx to determine compatibility (so-called “you must be this high to ride” checks).
Let us look for a moment at the problems with that position.
(1) 15 years. That’s how long Microsoft has warned people not to do this. It’s been in the documentation. If someone has written an application in 2012 that ignores a 15 year old warning, they pretty much deserve what they get, no matter how large of a customer they are.
(2) The idiom is “you must be at least this high to ride”. No one with a brain has done “you must be exactly this high to ride” since the 20th Century, and people without brains don’t count. An app that checks for
8.0 is going to continue to work when told it is running 8.1. Thus, I do not believe for a MOMENT that there is one single application that would actually break had this functionality been left intact.
(3) Let’s assume there ARE some brainless idiots who did write a “you must be exactly this high to ride” test, and who complained to Microsoft about it. How many of those apps do you suppose there are? I’ll wager real dollars I could count them with my fingers. Does that justify destroying a perfectly good API and breaking all those existing binaries that used the API for informational purposes?
We’ve heard before how many decisions are driven by “appcompat”. I assert that, in this case, that process failed miserably.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I can fix it. In fact, now that I remember that you need to use 64-bit on 64-bit and 32-bit on 32-bit I’m good to go, personally. I’ve effectively “fixed it” for myself.
But MY fixing devcon for MYSELF doesn’t help the six zillion other people after me who’ll make the same mistake. It’s obviously a common enough mistake, given that you have made this same mistake yourself.
After discovering this issue back in 2009, wouldn’t it have been nice if the dev owner added the one check I mentioned? At the cost of (almost) zero extra complexity, that would have saved at least ME from about an hour’s needless annoyance. I wonder how many other devs would be saved similar annoyance.
I’ve learned the lesson. All I’m doing is trying to advocate on behalf of those who come after me.
What I *should* have done is simply take the time to find out who the dev owner is and ask him directly if he’d be willing to make the change. I suspect I actually KNOW who currently maintains this tool, but I’m not sure. I thought posting here would be more fun, but given this thread, I guess I was wrong.
Peter
OSR
> You have been using…something that it was not intended to support
Microsoft advocated Virtual PC for kernel debugging and that is plain as day. So I am not sure what “not intended” refers to.
… and you use the fact that this same old, crippled, outdated, hacked-up,
niche-market piece of software that you used is no longer maintained
I think we agree here. There was a time VPC could have been considered top of the class for kernel debugging. Now it is the worst.
> Microsoft advocated Virtual PC for kernel debugging and that is plain as day
Hyper-V works fine, even across the net - when the HV host and the machine running WinDbg are different.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Hyper-V runs Windows guest just fine. I’ve a Linux guest but i haven’t used
it heavily to see if it’s ok. My FreeBSD guest has some very strange issues
on Hyper-V so that it’s not usable at all. However, it’s runs perfectly on
any other non-msft hypervisor.
On Fri, Sep 13, 2013 at 6:32 PM, Maxim S. Shatskih
wrote:
> > Microsoft advocated Virtual PC for kernel debugging and that is plain as
> day
>
> Hyper-V works fine, even across the net - when the HV host and the machine
> running WinDbg are different.
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
I don’t know what applications you profile, but the number of UM programmers
I have met who remember to check the OS version I can count on one hand.
So I am still at loss as to why specific app compat shims aren’t better than
generically breaking an API.
Certainly,applications that Microsoft has never heard of would do better off
even if the few that get tested are brain dead
“Doron Holan” wrote in message news:xxxxx@ntdev…
You give app developers way too much credit. The number of apps that break
when we change the version number (and nothing else in the OS) is in the
high 80%+ last time I looked. In that light, lying about the version number
solves that problem quite cleanly (clearly at the cost of the remaining %age
that don’t break)
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, September 13, 2013 9:46 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 32-Bit DEVCON on 64-Bit Windows
xxxxx@osr.com wrote:
That’s the reason that’s been cited. THEY say (not me, so don’t pile on)
that apps commonly use GetVersionEx to determine compatibility (so-called
“you must be this high to ride” checks).
Let us look for a moment at the problems with that position.
(1) 15 years. That’s how long Microsoft has warned people not to do this.
It’s been in the documentation. If someone has written an application in
2012 that ignores a 15 year old warning, they pretty much deserve what they
get, no matter how large of a customer they are.
(2) The idiom is “you must be at least this high to ride”. No one with a
brain has done “you must be exactly this high to ride” since the 20th
Century, and people without brains don’t count. An app that checks for
8.0 is going to continue to work when told it is running 8.1. Thus, I do
not believe for a MOMENT that there is one single application that would
actually break had this functionality been left intact.
(3) Let’s assume there ARE some brainless idiots who did write a “you must
be exactly this high to ride” test, and who complained to Microsoft about
it. How many of those apps do you suppose there are? I’ll wager real
dollars I could count them with my fingers. Does that justify destroying a
perfectly good API and breaking all those existing binaries that used the
API for informational purposes?
We’ve heard before how many decisions are driven by “appcompat”. I assert
that, in this case, that process failed miserably.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
If a driver critically depends on the OS version, then perhaps it IS
important that it “break” if the OS version changes. Lying about the
version should be configurable, like it is for UM apps. It should not be
the default that it lies.
The number of times I have had to check the OS version in a user app I can
count on the thumbs of one hand. In that case, I had to choose which DLL
to load so a Win32 function could be properly simulated on MS-DOS (aka
Windows 98)
joe
I don’t know what applications you profile, but the number of UM
programmers
I have met who remember to check the OS version I can count on one hand.
So I am still at loss as to why specific app compat shims aren’t better
than
generically breaking an API.Certainly,applications that Microsoft has never heard of would do better
off
even if the few that get tested are brain dead“Doron Holan” wrote in message news:xxxxx@ntdev…
You give app developers way too much credit. The number of apps that break
when we change the version number (and nothing else in the OS) is in the
high 80%+ last time I looked. In that light, lying about the version
number
solves that problem quite cleanly (clearly at the cost of the remaining
%age
that don’t break)-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, September 13, 2013 9:46 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 32-Bit DEVCON on 64-Bit Windowsxxxxx@osr.com wrote:
> That’s the reason that’s been cited. THEY say (not me, so don’t pile
> on)
> that apps commonly use GetVersionEx to determine compatibility
> (so-called
> “you must be this high to ride” checks).Let us look for a moment at the problems with that position.
(1) 15 years. That’s how long Microsoft has warned people not to do this.
It’s been in the documentation. If someone has written an application in
2012 that ignores a 15 year old warning, they pretty much deserve what
they
get, no matter how large of a customer they are.(2) The idiom is “you must be at least this high to ride”. No one with a
brain has done “you must be exactly this high to ride” since the 20th
Century, and people without brains don’t count. An app that checks for
8.0 is going to continue to work when told it is running 8.1. Thus, I do
not believe for a MOMENT that there is one single application that would
actually break had this functionality been left intact.(3) Let’s assume there ARE some brainless idiots who did write a “you must
be exactly this high to ride” test, and who complained to Microsoft about
it. How many of those apps do you suppose there are? I’ll wager real
dollars I could count them with my fingers. Does that justify destroying
a
perfectly good API and breaking all those existing binaries that used the
API for informational purposes?We’ve heard before how many decisions are driven by “appcompat”. I assert
that, in this case, that process failed miserably.–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer