I'm leaning toward this not really being a "good thing" in the near term... however it may end up being so in the long run. I wonder if Mark will still use Delphi for his MMC plugins?
I am afraid what will be missing will be Russinovich "clear speaking". And I hope it would not be forced to rewrite sysinternals utilities using .NET... maybe they will be still 300k... but requiring a 30MB framework!
In the respect that SysInternals supported OS versions right back to Win95, and MS refuses to support any OS except for XP, this has some VERY negative implications for the industry on the whole.
After all, XP is hardly the defacto OS. Heck I recently had to use some SysInternals apps on a Win95 machine. Why win95? Because the station ran custom ISA cards without HAL compatible drivers to drive external hardware. Updating was not an option. Thankfully SysInternals apps helped trace system behavior enough to resolve some issues.
Will I be able to do that next year? Only if it is an XP machine. The year after that? It better be vista or you'll be out of luck.
I liked MS as a candidate to buy DevCo, but for this particular product? Forget it, it is a disaster.
My Opinion is the opposit of Allen's: in the short term, it won't be so bad, but long term, I don't have much faith in Microsoft being able to maintain the quality, insight and "clear speaking" of SysInternals.
Microsoft nowadays is synonym of "golden retirement", not of "technology central". :/
Kent Morwath -> Since the sysinternals guys use VC++ from MS to write their tools that access older OSes, I think your fears are groundless in this area. Unless the Win32 api suddenly becomes changes radically, or exe wrappers change to bind to an OS, a compiler is a compiler for win32.
If you want to suggest Kylix as an alternative, don't even bother. Kylix is dead - apparently the IDE isn't even compatible with current versions of Linux (although the command line compiler still works if you want to do a LOT of extra work). Because of this, I don't consider any target other than win32/dotnet valid for Delphi.
So, while my fears about end user apps are well justified by company policy, the basis for your fears have clear holes in them based on exactly the same evidence.
I'll wait to see who they sell DevCo to before deciding if/how soon I need to migrate any long life projects to C#.
Kent -> Again, since the SysInternals guys used the MICROSOFT compiler to develop apps that support unsupported MS OS versions, your argument that MS compilers will bind you to the latest OS is totally groundless.
The fact that MS only releases end user apps that support the current OS has no bearing on the fact that the development tools CAN target older OS platforms.
Again, fear that apps that previously supported old OS versions now owned by MS will no longer support those OS versions -> totally justified. Fear that MS writes compilers that only support the current OS -> Completely groundless.
No contradiction there whatsoever.
As for not tying yourself to MS technologies? Instead you are binding yourself to Borland technologies. Based on Borland's poor judgement in the past, that doesn't make any more sense. Of course, you depend on third party vendors to provide libraries to access non-ms technologies.
Oh wait, you can get libraries for MS compilers that let you do exactly the same thing. In fact, since MOST libraries are available with C/C++ source, Delphi is actually MORE shortsighted in many cases, and I've run out of numbers for the number of third party libraries I can't use because Borland was too lazy to add proper .lib c/c++ integration into Delphi.
Please keep your comments related to the post on which you are commenting. No spam, personal attacks, or general nastiness. I will be watching and will delete comments I find irrelevant, offensive and unnecessary.
I am afraid what will be missing will be Russinovich "clear speaking". And I hope it would not be forced to rewrite sysinternals utilities using .NET... maybe they will be still 300k... but requiring a 30MB framework!
ReplyDeleteSad sad news.... :(
ReplyDeletePheraps Microsoft needed some really smart brains...
ReplyDeleteIn the respect that SysInternals supported OS versions right back to Win95, and MS refuses to support any OS except for XP, this has some VERY negative implications for the industry on the whole.
ReplyDeleteAfter all, XP is hardly the defacto OS. Heck I recently had to use some SysInternals apps on a Win95 machine. Why win95? Because the station ran custom ISA cards without HAL compatible drivers to drive external hardware. Updating was not an option. Thankfully SysInternals apps helped trace system behavior enough to resolve some issues.
Will I be able to do that next year? Only if it is an XP machine. The year after that? It better be vista or you'll be out of luck.
I liked MS as a candidate to buy DevCo, but for this particular product? Forget it, it is a disaster.
Don't they use Delphi at Microsoft for some projects (non dev-tool related)? <g>
ReplyDeleteI hope part of the deal is that Mark can continue to use it..
My Opinion is the opposit of Allen's: in the short term, it won't be so bad, but long term, I don't have much faith in Microsoft being able to maintain the quality, insight and "clear speaking" of SysInternals.
ReplyDeleteMicrosoft nowadays is synonym of "golden retirement", not of "technology central". :/
=====
ReplyDeleteMicrosoft is evaluating how the Winternals products and technologies can be integrated within Microsoft offerings to maximize customer value
=====
1) Take a product
2) Spend money purchasing the rights to it
3) Employ the authors
4) Increase your expenditure and operating costs
How does making me pay for something indirectly give me better value than downloading it free of charge from the author?
Im with you, it may mean a better util in the long run, but, will it be the same quality? free? etc..
ReplyDeleteKent Morwath -> Since the sysinternals guys use VC++ from MS to write their tools that access older OSes, I think your fears are groundless in this area. Unless the Win32 api suddenly becomes changes radically, or exe wrappers change to bind to an OS, a compiler is a compiler for win32.
ReplyDeleteIf you want to suggest Kylix as an alternative, don't even bother. Kylix is dead - apparently the IDE isn't even compatible with current versions of Linux (although the command line compiler still works if you want to do a LOT of extra work). Because of this, I don't consider any target other than win32/dotnet valid for Delphi.
So, while my fears about end user apps are well justified by company policy, the basis for your fears have clear holes in them based on exactly the same evidence.
I'll wait to see who they sell DevCo to before deciding if/how soon I need to migrate any long life projects to C#.
Kent -> Again, since the SysInternals guys used the MICROSOFT compiler to develop apps that support unsupported MS OS versions, your argument that MS compilers will bind you to the latest OS is totally groundless.
ReplyDeleteThe fact that MS only releases end user apps that support the current OS has no bearing on the fact that the development tools CAN target older OS platforms.
Again, fear that apps that previously supported old OS versions now owned by MS will no longer support those OS versions -> totally justified. Fear that MS writes compilers that only support the current OS -> Completely groundless.
No contradiction there whatsoever.
As for not tying yourself to MS technologies? Instead you are binding yourself to Borland technologies. Based on Borland's poor judgement in the past, that doesn't make any more sense. Of course, you depend on third party vendors to provide libraries to access non-ms technologies.
Oh wait, you can get libraries for MS compilers that let you do exactly the same thing. In fact, since MOST libraries are available with C/C++ source, Delphi is actually MORE shortsighted in many cases, and I've run out of numbers for the number of third party libraries I can't use because Borland was too lazy to add proper .lib c/c++ integration into Delphi.
apparently the IDE isn’t even compatible with current versions of Linux (although the command line compiler casinĂ² online
ReplyDelete