> Where neither source mentioned that there was anything "proved in > court", as there was never a trial on that matter.
Right, it wasn't. So the rumour part was _only_ the mention of "proved in court", which it didn't quite reach. But it isn't a rumour at all that MS-DOS 7 and 8 were unnecessarily tied to MS Windows 4. Regarding that, more of the sources specify in detail that Caldera showed (and even some of Microsoft's developers that worked on MS Windows 4 and MS-DOS 7 explained/agreed) that both of them could very easily have been separated: http://www.maxframe.com/DR/Info/fullstory/tech.html (lots of details) http://news.bbc.co.uk/2/hi/business/600488.stm (mentions settlement that instead happened, and "Caldera was able to demonstrate publicly Windows 95 running with DR-DOS", and "it was thought unlikely that Microsoft would win because of the strength of the evidence that Caldera had partially disclosed") > There was an out-of-court settlement before it came to a trial, which > beside apparently putting some money in Caldera's It is right that the settlement occurred instead. > robs us now to actual see what was claimed and what in fact the ties > between Windows 95 and DOS at that point was... Even as we don't have the implementation, the first source above does specify a lot of details. And here's a less official, though also interesting source: a post authored by Matthias Paul on 2007-12-18. It also has some technical comments: http://www.msfn.org/board/topic/109018-windows-98-in-dr-dos/page__view__findpost__p__721209 MP> [...] "WinGlue" basically just faked a number of undocumented MP> interfaces and data structures, [...] it was decided to fork MP> the kernel and directly add full MS-DOS 7.0 (and later 7.1) MP> support into the DR-DOS kernel. The DOS 7 compatible fork was MP> nicknamed DR-DOS "WinBolt" [...] So, WinGlue ("Scheibenkleister") was a basic device driver to make MS Windows 4 load, and WinBolt was a 7.02-ish fork of the kernel to fully support the new interfaces. The post also acknowledges that a different fork went on to be released as 7.03. > Rather to the contrary, if it would be that close, thunking should > not be necessary in the first place (or to a far lesser extend). Without the parenthetical remark, you would be incorrect, because at least pointers/buffers do have to be translated or made compatible somehow, no matter how close the systems are [unless hypothetically the 32-bit APIs artificially were limited to only using 16-bit registers and pointers]. > And the issue of "16 bit thunking in Windows 95" ran itself out > after more and more programs where specifically written for Win32 > instead of relying on old Windows 3.x 16bit code/DLLs. That's to be expected regardless of thunking details. Regards, Chris ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
