About the only killer app I want..
-
A complete revamp of the API. I know it would break every program on the market, but IMO it'd be worth it to cut out a lot of the clutter which is simply there for backward compatibility. With the release of the .Net framework coming along, perhaps making the new API completely managed, and deprecating C/C++/ASM in favour of C++/CLI would be a step in the right direction
Between the idea And the reality Between the motion And the act Falls the Shadow
-
Computafreak wrote:
deprecating C/C++/ASM in favour of C++/CLI would be a step in the right direction
Only if masochism is your direction. :)
If there was a better coherence between native and managed code, then I'd be happy to use it. Unfortunately, there are too many differences at the moment (gcnew vs. new, char * vs String, etc). Better support is what's needed
Between the idea And the reality Between the motion And the act Falls the Shadow
-
A complete revamp of the API. I know it would break every program on the market, but IMO it'd be worth it to cut out a lot of the clutter which is simply there for backward compatibility. With the release of the .Net framework coming along, perhaps making the new API completely managed, and deprecating C/C++/ASM in favour of C++/CLI would be a step in the right direction
Between the idea And the reality Between the motion And the act Falls the Shadow
Computafreak wrote:
A complete revamp of the API
I suspect Microsoft would say that with the advent of .NET, you've got it! If you ignore the WIn32 API (go on, try - put blinkers on if you can see it glinting at you from the corner of your minds-eye), then .NET looks pretty much like a new Windows API?
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Computafreak wrote:
A complete revamp of the API
I suspect Microsoft would say that with the advent of .NET, you've got it! If you ignore the WIn32 API (go on, try - put blinkers on if you can see it glinting at you from the corner of your minds-eye), then .NET looks pretty much like a new Windows API?
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Which is fine if you're developing using .NET. If you use C++, then you get the full blast of hundreds of overcomplicated functions using enough #defines to kill somebody
Between the idea And the reality Between the motion And the act Falls the Shadow
Computafreak wrote:
use C++
Microsoft's response would then be People outside Microsoft still use C++???. At least judging by their C++ efforts in Visual Studio...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
A complete revamp of the API. I know it would break every program on the market, but IMO it'd be worth it to cut out a lot of the clutter which is simply there for backward compatibility. With the release of the .Net framework coming along, perhaps making the new API completely managed, and deprecating C/C++/ASM in favour of C++/CLI would be a step in the right direction
Between the idea And the reality Between the motion And the act Falls the Shadow
-
A complete revamp of the API. I know it would break every program on the market, but IMO it'd be worth it to cut out a lot of the clutter which is simply there for backward compatibility. With the release of the .Net framework coming along, perhaps making the new API completely managed, and deprecating C/C++/ASM in favour of C++/CLI would be a step in the right direction
Between the idea And the reality Between the motion And the act Falls the Shadow
Computafreak wrote:
perhaps making the new API completely managed, and deprecating C/C++/ASM in favour of C++/CLI would be a step in the right direction
You forgot the joke icon. :laugh:
It is a crappy thing, but it's life -^ Carlo Pallini
-
Which is fine if you're developing using .NET. If you use C++, then you get the full blast of hundreds of overcomplicated functions using enough #defines to kill somebody
Between the idea And the reality Between the motion And the act Falls the Shadow
Computafreak wrote:
If you use C++, then you get the full blast of hundreds of overcomplicated functions using enough #defines to kill somebody the script kiddies
FTFY.
It is a crappy thing, but it's life -^ Carlo Pallini
-
Microsoft have done a lot of work on a legacy free OS called Midori, that's what I'm waiting for. Similar thread creation times to Linux etc.
Visit http://www.notreadytogiveup.com/[^] and do something special today.
Trollslayer wrote:
thread creation
thread or process? I thought process creation time was the big differentiator between WinNT (and its VMS heritage) and Unix?
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
In an earlier thread, I mentioned that perhaps Microsoft's only way to really get upgrades to the new OS is to build some killer apps and tie them to the new version. For many of us, there really is not a new killer app we can think of we would want. Same for me, but there is.. What I am waiting for and I think I will get with W7 this next yaer is a tablet type system which I can use all by GUI and not need a keyboard for most things that will have multi-touch screen. This should come with W7 this fall on laptops with a swivel screen as the multi-touch is built into the W7. This is about the only upgrade I plan for years as there just is not much more I see a need for in the near future. All I need is a large screen tablet type machine that removes most of my need for a mouse or keyboard. That should keep me going for the next five years. What about you? What is the killer app or killer features that would move you to W7 or beyond?
Rocky <>< Recent Blog Post: Backup or Move Mozilla settings and data easily! Thinking about Silverlight? www.SilverlightCity.com
Rocky Moore wrote:
What about you? What is the killer app or killer features that would move you to W7 or beyond?
Multiplayer Solitaire :cool:
-
If there was a better coherence between native and managed code, then I'd be happy to use it. Unfortunately, there are too many differences at the moment (gcnew vs. new, char * vs String, etc). Better support is what's needed
Between the idea And the reality Between the motion And the act Falls the Shadow
They both are *completely* different, so I won't be expecting them not to have differences. I am not saying MS has done their best as far as providing us options for being able to mix these two when needed, but for me, COM Interop has sufficed.
It is a crappy thing, but it's life -^ Carlo Pallini
-
They both are *completely* different, so I won't be expecting them not to have differences. I am not saying MS has done their best as far as providing us options for being able to mix these two when needed, but for me, COM Interop has sufficed.
It is a crappy thing, but it's life -^ Carlo Pallini
I expect differences - they use completely different libraries, etc. But it would be useful if W7 could start to reduce those, so that they could be connected fairly easily. C++/CLI has got the potential to go a lot further than it is now, and making changes so that it would operate with a new API would certainly bring it closer to the end goal of having a language which cleanly connects managed and unmanaged code OT: Univoters: stop it. If you have a disagreement, post it. Univoting with no explanation just shows that you lack the intellect to put across your objections
Between the idea And the reality Between the motion And the act Falls the Shadow
-
I expect differences - they use completely different libraries, etc. But it would be useful if W7 could start to reduce those, so that they could be connected fairly easily. C++/CLI has got the potential to go a lot further than it is now, and making changes so that it would operate with a new API would certainly bring it closer to the end goal of having a language which cleanly connects managed and unmanaged code OT: Univoters: stop it. If you have a disagreement, post it. Univoting with no explanation just shows that you lack the intellect to put across your objections
Between the idea And the reality Between the motion And the act Falls the Shadow
Computafreak wrote:
C++/CLI has got the potential to go a lot further than it is now,
For instance, the lack of intellisense for C++/CLI with VS 2010 onwards? I don't see C++/CLI is going to be used by many people. Just my opinion though. :)
Computafreak wrote:
it would operate with a new API would certainly bring it closer to the end goal of having a language which cleanly connects managed and unmanaged code
So, you are essentially saying that the interoperability between managed and unmanaged code needs to be better. If that's the case, then I might agree - like I said in my previous post, they could do better. But I fail to see the need for a completely new API here.
It is a crappy thing, but it's life -^ Carlo Pallini
-
In an earlier thread, I mentioned that perhaps Microsoft's only way to really get upgrades to the new OS is to build some killer apps and tie them to the new version. For many of us, there really is not a new killer app we can think of we would want. Same for me, but there is.. What I am waiting for and I think I will get with W7 this next yaer is a tablet type system which I can use all by GUI and not need a keyboard for most things that will have multi-touch screen. This should come with W7 this fall on laptops with a swivel screen as the multi-touch is built into the W7. This is about the only upgrade I plan for years as there just is not much more I see a need for in the near future. All I need is a large screen tablet type machine that removes most of my need for a mouse or keyboard. That should keep me going for the next five years. What about you? What is the killer app or killer features that would move you to W7 or beyond?
Rocky <>< Recent Blog Post: Backup or Move Mozilla settings and data easily! Thinking about Silverlight? www.SilverlightCity.com
"My Documents" tye folder to be cloud hosted and available no matter what machine I log into.
'--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
-
Rocky Moore wrote:
What about you? What is the killer app or killer features that would move you to W7 or beyond?
Multiplayer Solitaire :cool:
Buy a pack of cards you cheapskate!
It is a crappy thing, but it's life -^ Carlo Pallini
-
Computafreak wrote:
C++/CLI has got the potential to go a lot further than it is now,
For instance, the lack of intellisense for C++/CLI with VS 2010 onwards? I don't see C++/CLI is going to be used by many people. Just my opinion though. :)
Computafreak wrote:
it would operate with a new API would certainly bring it closer to the end goal of having a language which cleanly connects managed and unmanaged code
So, you are essentially saying that the interoperability between managed and unmanaged code needs to be better. If that's the case, then I might agree - like I said in my previous post, they could do better. But I fail to see the need for a completely new API here.
It is a crappy thing, but it's life -^ Carlo Pallini
Rajesh R Subramanian wrote:
For instance, the lack of intellisense for C++/CLI with VS 2010 onwards? I don't see C++/CLI is going to be used by many people. Just my opinion though. Smile
That's one thought.
Rajesh R Subramanian wrote:
So, you are essentially saying that the interoperability between managed and unmanaged code needs to be better. If that's the case, then I might agree - like I said in my previous post, they could do better.
You're correct, that's what I'm saying.
Rajesh R Subramanian wrote:
But I fail to see the need for a completely new API here.
To give the API designers a second chance. At the moment, the API seems bloated and overcomplicated. If they were able to completely re-design it, they could do a better job by making it cleaner and simpler. For example, the basic CreateProcess function takes ten arguments. How many of those arguments are needed regularly, when all you may want to do is start a program?
Between the idea And the reality Between the motion And the act Falls the Shadow
-
Rajesh R Subramanian wrote:
For instance, the lack of intellisense for C++/CLI with VS 2010 onwards? I don't see C++/CLI is going to be used by many people. Just my opinion though. Smile
That's one thought.
Rajesh R Subramanian wrote:
So, you are essentially saying that the interoperability between managed and unmanaged code needs to be better. If that's the case, then I might agree - like I said in my previous post, they could do better.
You're correct, that's what I'm saying.
Rajesh R Subramanian wrote:
But I fail to see the need for a completely new API here.
To give the API designers a second chance. At the moment, the API seems bloated and overcomplicated. If they were able to completely re-design it, they could do a better job by making it cleaner and simpler. For example, the basic CreateProcess function takes ten arguments. How many of those arguments are needed regularly, when all you may want to do is start a program?
Between the idea And the reality Between the motion And the act Falls the Shadow
Computafreak wrote:
reateProcess function takes ten arguments. How many of those arguments are needed regularly, when all you may want to do is start a program?
Well, that depends. If all I wanted to do was to "just start a program", I'd call ShellExecute[^] instead. There are many ways to do it though, and each function exists for a reason. CreateProcess[^] provides you with more control and options, so you don't have to use it for just starting a program. Some have come a long way (exists for backward compatibility and cannot be eradicated - for instance WinExec[^], which takes only 2 arguments, but it isn't recommended). Another inch further, and things get complicated. :)
It is a crappy thing, but it's life -^ Carlo Pallini
-
Computafreak wrote:
reateProcess function takes ten arguments. How many of those arguments are needed regularly, when all you may want to do is start a program?
Well, that depends. If all I wanted to do was to "just start a program", I'd call ShellExecute[^] instead. There are many ways to do it though, and each function exists for a reason. CreateProcess[^] provides you with more control and options, so you don't have to use it for just starting a program. Some have come a long way (exists for backward compatibility and cannot be eradicated - for instance WinExec[^], which takes only 2 arguments, but it isn't recommended). Another inch further, and things get complicated. :)
It is a crappy thing, but it's life -^ Carlo Pallini
That's kind of my point. There are lots of functions, which often have only one purpose between them. When it's possible to overload functions and use classes, how many functions are necessary? Why have two functions which do the same thing, except that one just provides more information?
Rajesh R Subramanian wrote:
Some have come a long way (exists for backward compatibility and cannot be eradicated - for instance WinExec[^], which takes only 2 arguments, but it isn't recommended).
If they've come a long way, when the capabilities of computers are almost continually changing, then chances are that they're outdated and not up to scratch in terms of security - WinExec is a good example of this
Between the idea And the reality Between the motion And the act Falls the Shadow
-
Microsoft have done a lot of work on a legacy free OS called Midori, that's what I'm waiting for. Similar thread creation times to Linux etc.
Visit http://www.notreadytogiveup.com/[^] and do something special today.
Trollslayer wrote:
Microsoft have done a lot of work on a legacy free OS called Midori, that's what I'm waiting for.
My theory on this is that they're going to be using minwin to leverage it into the OS. Insert midori in place of minwin, then lift the rest of the legacy win32/64 stack up from ring0 to ring1 so that all the bugs/cruft in it can't breach the heart of the kernal. Then add a new midori based APIs on the side for new apps to use.
The European Way of War: Blow your own continent up. The American Way of War: Go over and help them.