|
Tim Stubbs wrote:
Meh, i'm injecting my code into the kernel..
Tim Stubbs
 )))))
|
|
|
|
|
I wrote my OpenWindows in Concurrent Clean !
Kochise
In Code we trust !
|
|
|
|
|
But with Longhorn, managed frameworks will be more in line with the OS, which is also supposed to be more managed. I think.
Marc
MyXaml
Advanced Unit Testing
YAPO
|
|
|
|
|
Yes, Marc I remember years back there was talk at Microsoft of an OO API, IIRC I think this was part of Cairo, maybe this is what we are finally seeing.
My Blog ^
|
|
|
|
|
Marc Clifton wrote:
But with Longhorn, managed frameworks will be more in line with the OS
And what underlying language will be managing them there frameworks? I doubt MS will be doing kernel/ring 0 development in .NET anytime soon. Besides, Windows is slow enough as it is.
Oddly enough, I remember a day when people used to say native code was the only way to go. Well, that is until MS said it wasn't anymore and then all of the sudden native is so passé. Seems to me Java programmers aren't crazy but rather forward thinking (even if it is slow) -- in this regards.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote:
I doubt MS will be doing kernel/ring 0 development in .NET anytime soon. Besides, Windows is slow enough as it is.
True, but the impetus for a fully managed code seems to be there:
"Yes, Longhorn is based on the NT Kernel.
Longhorn will not be a fully managed OS, but will for a large degree be built on managed code. All new APIs will be managed.
WinFX the new API for Longhorn and beyond is the foundation for the future when we achieve a fully managed OS. How long will it take? Hard to say, we will learn a lot from building Longhorn and go from there. "
Source[^] (look for the comment and reply with the word "kernel" it it).
Marc
MyXaml
Advanced Unit Testing
YAPO
|
|
|
|
|
I beleive the interfaces, ala API, will be managed. The core however will not unless MS wants Windows to be even slower. That means that there will still be a way to take advantage of newer features w/o .NET but it propbably won't be documented by MS.
And, if MS does make Windows even slower, then I hope like hell someone comes out with an OS to replace Windows.
Jeremy Falcon
|
|
|
|
|
BadKarma wrote:
This will continue to happen until M$ decides to create a new OS with .Net as it base technology
That's what Longhorn is. A managed replacement for Win32. Going forward it will be the preferred interface to code to. Win32 will appear to Longhorn similarly to how Win16 and DOS appear to Win32.
BadKarma wrote:
The .Net library structure still needs to convert its methods to a win32 call.
That's what WinFX does. I'm currently solving a problem at work to do with proxy servers. Current .NET API only implements a bit of this and does it incorrectly, so I have to wrap the native Windows HTTP Services. But I saw some preliminary documentation of the WinFX documentation where you can see that the .NET API has been expanded to incorporate the Windows HTTP Services functionality.
Kevin
|
|
|
|
|
MFC .NET?? Huh??
VS already includes VC++ .NET! I really wonder how many people really develop in VC++ .NET when they have C#  , something terribly easy, at their disposal. So I am really doubtful if anyone would really move to MFC.NET. Besides i certainly develop most desktop apps in C# while, as someone already pointed out, ATL/WTL/STL is a really good alternative for really high performance, small memory footprint apps. So just let MFC die peacefully and let the world move on...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
I never really saw the point in C# - a single platform language as opposed to JAVA which is much the same thing and cross platform.
I think you're right tho - C++ isn't appealing with .NET as the syntax is so horrible at the moment (hence MS is fixing it for version 2).
Tim Stubbs
|
|
|
|
|
Tim Stubbs wrote:
a single platform language as opposed to JAVA which is much the same thing and cross platform.
I wont say that especially after successful release of mono. However C# certainly does ape JAVA but that's what it was meant for!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
also, C# could be multi-platform if Microsoft or someone else would take the time to write a .net platform based on the windows .net framerwork on an OS like Mac or Linux!!! it should work then!
IM PROUD TO BE A GMAIL;
|
|
|
|
|
|
If we speak of MFC as an interface, then yes, it should be ported.
How much bigger has Microsoft gotten since it originally published MFC ?
A big company like this should come up with decent interfaces that can pass the test of time.
Now, the implementation is mostly a bunch of thin wrappers on top of a WIN32 api. I can still remember the transition from Borland 4.5 to MSVC 5.0. (Borland had a much better library, as far as I was concerned).
So, CString should be portable, so should CWnd and CDialog and CWaitCursor and (...) the list goes on, even if its just to proove that Microsoft can not only come up with libraries, but also come up with libraries worth using.
Otherwise, who is to say that 5-10 years from now we will not have to change again from "dot net" to "whatever other buzzword they come up with" ?
Yes, we need another library: dot net.
Yes, we need some effort from Microsoft to port their own mess to the new generation.
Or at least make a decent attempt, documenting difficulties, leaving to the comunity such as this very web side the task of complementing their effort.
That's my own opinion, anyway.
|
|
|
|
|
Instead of porting it, why not just make *IT* the interface then if it's that great?
Also, just because something is made by so and so doesn't make it right, wrong or the best to use. Companies have dead lines and interfaces are again made by people. It doesn't mean that these interfaces are greatest thing since sliced bread and it doesn't mean that they aren't. Don't take anything at face value and question everything. "Could this be done better?" "What do I like and dislike about this?" You also have to remember the audience. To make a single interface usable in the most flexible of environments to suit EVERYONE'S NEEDS is very broad. Some people need more flexibility and others (the stupider people who work on basically simple projects) need less and want to do less, they are usually just IT guys anyway.
The hard core programmers though skip all this crap and use the direct interfaces
|
|
|
|
|
is the App Wizard. With a couple of clicks, you can get a fully formed Windows skeleton application with a nice doc/view architecture. Menus, toolbars and status bars ready to be customised.
A few decent "app wizards" ported to .NET and C# would be nice.
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
True, that. It's a little harder to get those one-off proggies looking professional with the .NET wizards.
I'm actually a bit suprised by that, having intially figured that custom wizards would have flooded CP by now... guess it's more of a personal thing.
Medication for us all
You think you know me, well you're wrong
|
|
|
|
|
Yeah, I haven't load VS 2005 yet, does anybody now if there are any cool wizard for C# apps?
My Blog ^
|
|
|
|
|
Shog9 wrote:
I'm actually a bit suprised by that, having intially figured that custom wizards would have flooded CP by now... guess it's more of a personal thing.
I think we'd see more, if wizard building for Visual Studio wasn't such a black-art
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
Heh... there's probably a joke to be had here, something about replacing wizards with sorcerers... but yeah. It should be easier.
Medication for us all
You think you know me, well you're wrong
|
|
|
|
|
Shog9 wrote:
Heh... there's probably a joke to be had here, something about replacing wizards with sorcerers... but yeah. It should be easier.
Back in the dark ages. A couple of us built a wizard to generate some code (DB wrappers I think - can't remember). Anyway the other engineer was a big Terry Pratchett / Discworld[^] fan. So he named the wizard 'Rincewind[^]' after the inept wizard of the Discworld stories. 
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
Excellent.
Loading DB Wrapper Wizzard...
File is read-only! ohshitohshitohshitohshitohshitohshitohshitohshit
Medication for us all
You think you know me, well you're wrong
|
|
|
|
|
|
Ummm...I can do the same in about 30 seconds in c# if it made any sense to do so.
I wouldn't want to inflict Doc/View on anyone though, how many times, in how many apps does it truly fit the task at hand? Sure if you're editing documents in an app, but really, how often is that in the big scheme of things?
I always thought it was a bit of a silly design that was parroted by too many developers not really taking the time to consider the task at hand when they developed their app. So many apps were shoe-horned into that style of thinking when it really didn't apply to them at all.
I much prefer the blank slate approach that you can turn into anything you want, although all our business apps are starting to look a lot like Outlook.
"In our civilization, and under our republican form of government, intelligence is so highly honored that it is rewarded by exemption from the cares of office."
- Ambrose Bierce
|
|
|
|
|
Yeah doc/view was mostly useless - but i don't think most developers stuck to it in any great sense (certainly true for myself for the past 10 years or so).
However, he does have a point, the wizards (and the rest of IDE) needs a lot of work yet...
Tim Stubbs
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)