Vista - COOL EDIT 2000

A really neat commercial, no-longer-marketed program for editing audio files
(see Subject) tends to crash on Windows Vista. No such behavior is evident
on Windows XP. Performing certain operations using various controls causes
the program to crash on a storage limits violation. Vista takes the trap and
launches Visual Studio as an assist. Apparently, some register that is
supposed to contain an address instead contains a ZERO. Increasingly it
appears that the Vista runtime environment is sufficiently different that
programs that work on XP are not expected to run unchanged on Vista. This
comes when the semantics of control objects change unbidden. That which has
been learned concerning those semantics on an old OS do not apply on a new
OS. Solution: Learn to live with the problems.
--
William McIlroy

William McIlroy wrote:
Not sure of it's any use to you at all but would Audacity do what you
want without any hassle?

http://audacity.sourceforge.net/

"William McIlroy" <WilliamMcIlroy@xxxxxx> wrote ...
Hi William,

Actually in the case of an unhandled exception, Vista launches whatever is
the default debugger on the system. On a plain, vanilla installation of
Vista, this will be Windows Error Reporting (WER), as accessed via Control
Panel, Problem Reports and Solutions. WER will send a report of the crash
back to Microsoft. If a significant number of crashes are detected in
popular applications, Microsoft will produce a hotfix or compat shim, or
notify the 3rd party ISV they need to fix their app (obviously no use, if
the ISV doesn't support their app any more).

When you install Visual Studio on a machine, it will configure itself to be
the default debugger, by writing itself to the AeDebug key. In previous
versions of Windows you could restore Dr Watson as the default system
debugger, by running "drwtsn32 -I". I'm not sure how you get WER back in
place on Vista (probably not hard; just, I dunno how).

If you run with Visual Studio as the default debugger, the assumption is you
will use the Visual Studio debugger to analyse and understand the cause of
the crash. It's clearly a null pointer being passed, the question is: why?
It is unlikely any change to a documented API in Vista would result in Null
pointers; more likely, the Cool Edit app was relying on undocumented
internal structures, which have now shifted location in Vista. That's why
they were undocumented!
On the contrary: Microsoft has provided extensive documentation, plus free
tools, to developers to help maintain compatibility. The first "Longhorn"
(ie, Vista) developer conference was back in 2003, and there have been a ton
of presentations and materials published since then. See the Vista
Compatibility portal for developers:

Windows Vista Application Compatibility
http://msdn2.microsoft.com/en-us/win.../aa904987.aspx

The Application Compatibility Toolkit 5.0 provides tools to analyse the
behaviour of legacy programs, and detect many "improper" programming
practices:
http://technet.microsoft.com/en-us/w.../aa905066.aspx

All the API changes in Vista are documented in MSDN. These changes are also
collected in documents like:

The Windows Vista and Windows Server 2008 Developer Story: Application
Compatibility Cookbook
http://msdn2.microsoft.com/en-us/library/aa480152.aspx


On a more general note - Microsoft does not break backwards compatibility
for no good reason. In fact, they go to extreme lengths to preserve
compatibility for old applications. Although it's not visible to the end
user, there's a engine running inside Vista - the shimeng.dll and
apphelp.dll DLLs - whose sole purpose is to tweak Vista in various small
ways, so that many popular, older applications can continue running in the
new Vista environment. This "shim engine" adds support for literally
hundreds of applications which otherwise could not run on Vista. Designing
and maintaining the shim engine is a major dev project - reflecting
Microsoft's commitment to compatibility. The compatibility shims are updated
via Windows Update, as shims for additional applications become available
from Microsoft.

However .... for years, Microsoft has been heavily criticised (perhaps
rightly) for not being strong on security. In the Vista release, Microsoft
has taken security very seriously. Which has paid off, Vista is an operating
system which is actually secure enough to survive in today's lethally
virulent networked environment, and secure enough to compete with rival
operating systems. By and large this is a Good Thing; because in the past,
users had been stuck in a continuous, expensive struggle to maintain
computer security in the face of security weaknesses in those earlier
versions of Windows. The struggle to stay secure is by no means over, but it
is easier, less costly, and less time consuming with Vista. A side effect of
this improved security is that some applications will no longer run on
Vista - mainly apps which which were developed using unsafe, insecure
practices which are now deprecated.

For a fascinating inside look at the compatibility engineering effort at
Microsoft, I highly recommend Raymond Chen's outstanding book "The New Old
Thing". This has a warts-and-all, dirty-laundry, no-one's-feelings-spared
look at the struggle to maintain compatibility in Windows. An excellent book
for any developer.

http://www.amazon.com/Old-New-Thing-...0435414&sr=8-1

I agree that compatibility is an important issue. And maybe Microsoft could
do a better job. But it's not like they just changed things around for the
hell of it, and left the user base to just suffer.

You might have already tried this, but you could try adjusting Cool edit's
compatibility to an earlier version of Windows. Right-click the main EXE
file, choose Properties, select the Compatibility tab, and check the
checkbox for "Run in compatibility mode" and select Windows 98 (or whatever)
from the drop down list. This doesn't bypass all compatibility problems, but
it will solve some- especially those involving changes to "semantics of
control objects".

Regards,
--
Andrew McLaren
amclar (at) optusnet dot com dot au

I am aware that Microsoft attempts to mitigate the effects of changes it
makes to its operating systems. This shows a very good understanding of how
changes seriously impact users in the real world. Shims are a good thing
because they reduce complaints. Shims are a bad thing because they can open
security holes. One man's "undocumented feature" is another man's hours of
experimentation to discover how something really behaves and subsequent
relying on hard-won learned system behavior staying the same over successive
OS releases. Why the experimentation? Because documentation is treated as a
second-class citizen. It only hints at what programmers need to know. It is
in no way a mathematically rigorous contract between Microsoft and
programmers. This probably is because writing documentation is difficult,
never done, and the underlying facts are always changing. Fortunately, in my
case, the program in question does not fail often enough to be a serious
challenge. Still, when it crashes, it is disappointing.
--
William McIlroy



"Andrew McLaren" wrote:

"William McIlroy" <WilliamMcIlroy@xxxxxx> wrote in
message news:0547805A-3E0E-4A64-8799-A3376CA2ADEC@xxxxxxI am new to Vista Home Prem. And I had not yet reinstalled Cool Edit 2000,
so this is a disappointment. I have now installed it and it seems to be
working. However if I select part of a waveform and try to "cut" the
selection, the "cut" is greyed out. Do you have that problem?

Regards
Doug

"William McIlroy" <WilliamMcIlroy@xxxxxx> wrote...Umm ... so, you want we should take the shims out? Reduce the
compatibility??
Well, I don't want to actually *defend* Microsoft's documentation, because I
spend a good slice of every working day swearing and cursing at MSDN, etc.

But to date, I haven't seen too many vendors providing "mathematically
rigorous" documentation of their APIs. Not IBM with CICS or MVS, not Oracle
with OCI, not Sun with Java, not BEA with WebLogic ... I could go on. I
understand what you want; and hell, I've even programmed in Eiffel (which I
greatly respect as a language, btw). But those kinds of contracts rarely
exist for non-trivial or non-hugely-expensive systems. It's an ongoing
problem in software engineering, and no vendor has solved it yet. Just read
any issue of the IEEE Transactions on Software Engineering, to see why this
is not yet a solved problem. Sometimes IBM is marginally better than
Microsoft at documenting stuff; other times, Microsoft has marginally better
docs than IBM. Often they both have better docs than Oracle, and none are as
good as the Java docs. But these are all minor variations on a theme; no
vendor is significantly, qualitatively better than any other vendor, in this
regard.

However, you can be pretty sure of a few things:

- if a feature, API or structure is undocumented, you use it at risk. There
is *no* guarantee it will be preserved in future versions.

- if a feature, API or structure is documented,. there is a very high degree
of probability that it will be preserved in version upgrades, *or* there
will be a clear indication that it has been deprecated or withdrawn, *or* it
will fail gracefully not violently.

Whatever other merits of the DoJ's action against Microsoft, MSDN is now
subject to legal scrutiny, as Microsoft's *legally binding* agreement of how
its APIs will behave. I believe, from informal discussions with Microsoft
developers, that they take documenting APIs very seriously indeed. Not with
mathematical rigour, certainly; it's still a human and fallible task - but
for example, if something appears in MSDN which is wrong or wasn't meant to
be there, the Microsoft guys then have to go and actually implement that
feature; in case an ISV has already used it; they can't just cross it out.
And so on.

I'd be very confident the reason the Cool Edit app is crashing is *not*
related to any kind of change Microsoft has made to a published API. More
likely, the ISV has done as you suggest, and grovelled in some undocumented
structure or API. "Ah-ha, this DISKIO_CONTEXT ScopeIndex is just the field I
need!" they cried, and then they use it in their code. But if ScopeIndex is
undocumented, and silently dropped in the next release of Windows (silently,
because it was never documented to begin with) then when running on on
Vista, the ISV's code tries to read from ... a non-existent field! Pulling
in a NULL is a distinct possibility. In fact, I can almost guarantee that no
deliberate change to an API will result in a successful null reference being
returned. It just wouldn't happen. Not even a crappy first-year programmer
would do that (well, maybe a crappy first year programmer ... but not
Windows devs).

As I say, I don't wish to defend or gild Microsoft too much, because (a) I
myself, as a porgrammer, wrestle with their documentation, and have pulled
out what little grey hair I have left, trying to get things working; and (b)
I have seen many, many Windows bugs over the years, were something does
indeed pass an inappropriate null pointer, or similar weird defect, and it
has been a genuine, died-in-the-wool, no-questions-asked BUG in Windows.

But - is the crash in Cool Edit caused by a lack of compatibility in Vista?
I seriously doubt it.

BTW, see here for a few funny stories from Raymond Chen about "undocumented
features":
http://blogs.msdn.com/oldnewthing/ar.../23/45481.aspx
http://blogs.msdn.com/oldnewthing/ar...01/459023.aspx
http://blogs.msdn.com/oldnewthing/ar...07/545295.aspx
His book has ~400 pages of such stories!
Well, if Visual Studio catches the exception, you should be able to debug it
(I'm making the possibly presumptuous presumption that if you have Visual
Studio installed and you care about API documentation, you also know how to
write and debug programs). First, make sure your symbol path is correct:
http://www.microsoft.com/whdc/devtoo...ebugstart.mspx
then reproduce the problem. Walk back along the stack, looking for the place
where the null pointer came in as a parameter. Then look up that function's
doco in MSDN, and see what changes (if any) were described, for Vista. In
fact you'll probably find that no changes are described; and/or that the
null pointer comes from a ISV-defined function which grovelled in
undocumented spaces.

However, I do accept that you have an app which ran fine on XP, and no
longer runs okay on Vista. I've owned several apps lilke that myself. And,
yeah: it is frustrating. But it's probably wrong to blame Vista, per se.

Regards,
--
Andrew McLaren
amclar (at) optusnet dot com dot au

Cool Edit 2000 performs almost flawlessly on Vista except for the occasional
crashes. I just tried the Cut function: no problem. I took the advice of
another poster and configured the icon for launching Cool Edit 2000 so that
Vista will provide it an environment like Windows 98. I will live with the
UAC nonsense that this step produces to see whether Cool Edit 2000 stops
crashing.
--
William McIlroy



"The Old Bloke" wrote:

I have Cool Edit 2000 running in the XP sp2 mode, and I get no crashes. The
Cut function works OK initially, until I do a zoom in, or expand the
waveform time line. From this point on the "cut" is greyed out.

I have a dual boot system. A bit of a pain, but it works without a problem
under True XP

Doug




"William McIlroy" <WilliamMcIlroy@xxxxxx> wrote in
message news0D1EDCC-9707-4A10-9095-0D777757C15C@xxxxxx

Been a while since I last used Cool Edit 2000. Tried a bit more, and yes it
is a wonderful, intuitive programme. I have solved the "Cut" problem. It
only is a problem when I have Paused, rather than "Stop". I have just used
it for about one hour, and it was stable, no crashes, nor errors. However I
did each installation .exe, including the registration exe and noise
reduction exe as "run as administrator".

Cool Edit 2000 lives on ....

Doug

"William McIlroy" <WilliamMcIlroy@xxxxxx> wrote in
message news0D1EDCC-9707-4A10-9095-0D777757C15C@xxxxxx

I got Cool Edit 2000 way back when... I used it on XP... I was able to
move it from my old machine to my new machine when I got one with no
trouble... run the install and then the license thing... I got a new
laptop last year with Vista Ultimate. I took the source files from my
desktop and transfered them via LAN to the laptop. I ran each and it
appeared Cool Edit 2000 had installed. I click on the desktop icon and
there's a brief flicker and then nothing! Nothing in Task Manager...
Just for giggles, I ran the ce2k.exe (the license thing). It does the
install then brings up CE2K with a sample wav. I clear the sample wav
and can record on this demo with all functionality. Has anyone had a
similar problem? What was the solution? Thanx.

L


--
es336td
Posted via http://www.vistaheads.com