well, since it's waiting anyway... to add some speculations about stuff
the DSP part is likely fairly self-contained, because the system ran well under Mac OS9
(which is as far from Windoze as you can think)
I'd rather expect problems with enforced security handling of memory blocks which has become a major issues since buffer overflow (and similiar) attacks. Scope acts as a kind of compiler in many cases and must modify execution code in memory during runtime. The original system was completely unlimited in that context, as M$ either wasn't aware of such potential 'security problems' or simply ignored them.
I wouldn't want to bet my right arm on any fix (or strategy) M$ offers... they are well known for clumpsy solutions.
Assuming that Scope does 'compile' stuff, the original module (which may not even be a CWA design) could reveal flaws in specific circumstances NOW, which were not traceable under a 32bit OS.
Even the smart MacOS memory handling had similiar issues - and Apple's developement team had coders of the highest regard in industry that time.
One may assume that these 2 ideas have some probability at least...
Such stuff is more difficult to handle, as you don't fix some messed window content (for example), which you could directly adress.
Instead you deal with a code generator, whose (abstract) results may fail in some way... and typically only under specific circumstances.
I have no idea if this really applies, but it's a valid scenario that could cause tremendous delays due to 'late discoveries' of bugs or whatever you like to call that.
As we all know THERE IS NO flawless software out today - it cannot be.
The shere size of the object code gives you a good estimation how many lines of code were required.
It's impossible to iron out everything above a give maximum because there's not enough time.
BUT... that's only half of the story.
Even if someone would in fact write a flawless piece of code, it HAS TO run in an environment that definitely IS NOT flawless to the same degree.
I've lost track, but when M$ released Win2k, they claimed to have fixed 45k bugs from Win98.
Code size has increased in magnitudes since then... go figure yourself
(not sure about the versions as it's been some time, but the 45k is correct)
We also know from experience that mobo chipsets can be pretty buggy, too.
Some bugs even make it to features and aren't fixed on the hardware, but by specific code to handle them...
It's a jungle out there...
That's why I'm not even surprised that a company like Sonic Core has to delay their schedule in the way we currently experience.
You can't simply fight that with headcount - this is not about stylesheets for a website.
It's fairly abstract code handling... not using (something like) a C compiler, but writing the complier itself.
And this device has to work in an environment that's beyond your own control...
(to be honest... it's also beyond reason... but that's mho and a different story)
You get the idea ?
cheers, Tom
