Longhorn and Win32
-
With all the hubub over Longhorn, Avalon and WinFX can anyone answer this: Will applications that use the Win32 API still work in Longhorn? And if it is all .Net what happens to regular C++? Will people be forced to use managed C++ code to write apps? ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
-
With all the hubub over Longhorn, Avalon and WinFX can anyone answer this: Will applications that use the Win32 API still work in Longhorn? And if it is all .Net what happens to regular C++? Will people be forced to use managed C++ code to write apps? ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
They'll still work, but will not be able to take direct advantage of any of the new features.
**"I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use." -- Galileo Galilei
-
They'll still work, but will not be able to take direct advantage of any of the new features.
**"I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use." -- Galileo Galilei
By "take direct advantage" you mean??? Will window, controls, edit boxs, drag-drop, clipboard, etc still behave the way they do in Win32? Or will "basic" services simply be missing if you don't use Avalon (or whatever it's called)? ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
-
They'll still work, but will not be able to take direct advantage of any of the new features.
**"I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use." -- Galileo Galilei
As an example of what I mean consider this: I create a window with the snazzy new wiz-bang API's and I get all cute fluttering 3d nonsense (or whatever it becomes) when the window opens or is minimized or whatever. I create a window with the old Win32 API's and all of that is missing. So that it becomes fundametally obvious to the end user that teh applications is "old" or "out of date". In OSX all the whiz bang 3d effects are handled by the WindowServer, and NOT by the core developer API's ('m sure you could simulate them or make your own by dealing with the openGL engines, but you have to put the extra effort into doing somethign like that). So the end user experience is identical whether the app is written in the older C/C++ Carbon API's, Java, or the ObjectiveC API's (which is what Apple prefers you to use). My concern is that Microsoft's "migration path" will be to simply make any apps that use the older API's look like crap, and only the Avalon/.Net based stuff look nice. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
-
As an example of what I mean consider this: I create a window with the snazzy new wiz-bang API's and I get all cute fluttering 3d nonsense (or whatever it becomes) when the window opens or is minimized or whatever. I create a window with the old Win32 API's and all of that is missing. So that it becomes fundametally obvious to the end user that teh applications is "old" or "out of date". In OSX all the whiz bang 3d effects are handled by the WindowServer, and NOT by the core developer API's ('m sure you could simulate them or make your own by dealing with the openGL engines, but you have to put the extra effort into doing somethign like that). So the end user experience is identical whether the app is written in the older C/C++ Carbon API's, Java, or the ObjectiveC API's (which is what Apple prefers you to use). My concern is that Microsoft's "migration path" will be to simply make any apps that use the older API's look like crap, and only the Avalon/.Net based stuff look nice. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
I think their path will be to make whatever can be done without calling additional APIs be automatically done for legacy apps, but not have any additional non-managed APIs.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
As an example of what I mean consider this: I create a window with the snazzy new wiz-bang API's and I get all cute fluttering 3d nonsense (or whatever it becomes) when the window opens or is minimized or whatever. I create a window with the old Win32 API's and all of that is missing. So that it becomes fundametally obvious to the end user that teh applications is "old" or "out of date". In OSX all the whiz bang 3d effects are handled by the WindowServer, and NOT by the core developer API's ('m sure you could simulate them or make your own by dealing with the openGL engines, but you have to put the extra effort into doing somethign like that). So the end user experience is identical whether the app is written in the older C/C++ Carbon API's, Java, or the ObjectiveC API's (which is what Apple prefers you to use). My concern is that Microsoft's "migration path" will be to simply make any apps that use the older API's look like crap, and only the Avalon/.Net based stuff look nice. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
Jim Crafton wrote: My concern is that Microsoft's "migration path" will be to simply make any apps that use the older API's look like crap, and only the Avalon/.Net based stuff look nice. That would be a concern and I wouldn't put it past MS. But, then again, this would require a major re-write of Office in order to make it look nice and I am not sure MS would want to do this. John Carson
-
They'll still work, but will not be able to take direct advantage of any of the new features.
**"I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use." -- Galileo Galilei
If they're managed interfaces you should just be able to call them as COM objects Jared jparsons@jparsons.org www.prism.gatech.edu/~gte477n
-
As an example of what I mean consider this: I create a window with the snazzy new wiz-bang API's and I get all cute fluttering 3d nonsense (or whatever it becomes) when the window opens or is minimized or whatever. I create a window with the old Win32 API's and all of that is missing. So that it becomes fundametally obvious to the end user that teh applications is "old" or "out of date". In OSX all the whiz bang 3d effects are handled by the WindowServer, and NOT by the core developer API's ('m sure you could simulate them or make your own by dealing with the openGL engines, but you have to put the extra effort into doing somethign like that). So the end user experience is identical whether the app is written in the older C/C++ Carbon API's, Java, or the ObjectiveC API's (which is what Apple prefers you to use). My concern is that Microsoft's "migration path" will be to simply make any apps that use the older API's look like crap, and only the Avalon/.Net based stuff look nice. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
Seems like Mirosoft is slowly following the lines of Linux. Hey? Where do yall acquire all of this information from, or is this in house only type stuff?
-
Seems like Mirosoft is slowly following the lines of Linux. Hey? Where do yall acquire all of this information from, or is this in house only type stuff?
BladeRunner wrote: Where do yall acquire all of this information from The Longhorn Developer Section[^] on MSDN[^]. :)
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
If they're managed interfaces you should just be able to call them as COM objects Jared jparsons@jparsons.org www.prism.gatech.edu/~gte477n
-
With all the hubub over Longhorn, Avalon and WinFX can anyone answer this: Will applications that use the Win32 API still work in Longhorn? And if it is all .Net what happens to regular C++? Will people be forced to use managed C++ code to write apps? ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
According to one of our lead engineers who went to PDC, Microsoft went out of their way to assure developers that Windows would continue the tradition of backward compatiblity. They also said that many UI elements would get the new look automatically. Other elements would probably require the manifest be changed or added as it does in XP. As someone else pointed out, some things, like WinFS, will be available as COM objects. I gather, however, that Avalon and Aero will only be available through .NET. Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
With all the hubub over Longhorn, Avalon and WinFX can anyone answer this: Will applications that use the Win32 API still work in Longhorn? And if it is all .Net what happens to regular C++? Will people be forced to use managed C++ code to write apps? ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
Microsoft has an agenda on their mind : - kill Html as we know it - kill Flash, SVG, and whatever multimedia stuff - kill (their own) winforms, even if you started building projects on it :-( Unfortunately, and as you point out, their code stack is at the application level, and thus rewards developers with a total lack of older platform compatibility. What relieves me is that vector graphics don't cut in the corporate world, so this will require 4 more years at least to start being adopted when it's out. I also don't buy their gratuitous claim that "CPU/GPU do nothing and could be used" : used for what? Photoshop guys that compile their stuff need CPU horsepower, so do C++ guys, etc. I can't see a single reason why the CPU/GPU would be doing intensive graphics just because Microsoft has decided they would do this upfront in the operating system. The question that remains is whether anything of that can be disabled.
-
As an example of what I mean consider this: I create a window with the snazzy new wiz-bang API's and I get all cute fluttering 3d nonsense (or whatever it becomes) when the window opens or is minimized or whatever. I create a window with the old Win32 API's and all of that is missing. So that it becomes fundametally obvious to the end user that teh applications is "old" or "out of date". In OSX all the whiz bang 3d effects are handled by the WindowServer, and NOT by the core developer API's ('m sure you could simulate them or make your own by dealing with the openGL engines, but you have to put the extra effort into doing somethign like that). So the end user experience is identical whether the app is written in the older C/C++ Carbon API's, Java, or the ObjectiveC API's (which is what Apple prefers you to use). My concern is that Microsoft's "migration path" will be to simply make any apps that use the older API's look like crap, and only the Avalon/.Net based stuff look nice. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
There was this session at the pdc. Exploiting Windows "Longhorn" Features from within Win32/MFC Applications Track: Client Code: CLI390 Room: Room 403AB Time Slot: Wed, October 29 10:00 AM-11:15 AM Speakers: Anson Tsao, Tarek Madkour However there don't appear to be any slides :( Maybe someone who attended could fill us in.
-
As an example of what I mean consider this: I create a window with the snazzy new wiz-bang API's and I get all cute fluttering 3d nonsense (or whatever it becomes) when the window opens or is minimized or whatever. I create a window with the old Win32 API's and all of that is missing. So that it becomes fundametally obvious to the end user that teh applications is "old" or "out of date". In OSX all the whiz bang 3d effects are handled by the WindowServer, and NOT by the core developer API's ('m sure you could simulate them or make your own by dealing with the openGL engines, but you have to put the extra effort into doing somethign like that). So the end user experience is identical whether the app is written in the older C/C++ Carbon API's, Java, or the ObjectiveC API's (which is what Apple prefers you to use). My concern is that Microsoft's "migration path" will be to simply make any apps that use the older API's look like crap, and only the Avalon/.Net based stuff look nice. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
-
Microsoft has an agenda on their mind : - kill Html as we know it - kill Flash, SVG, and whatever multimedia stuff - kill (their own) winforms, even if you started building projects on it :-( Unfortunately, and as you point out, their code stack is at the application level, and thus rewards developers with a total lack of older platform compatibility. What relieves me is that vector graphics don't cut in the corporate world, so this will require 4 more years at least to start being adopted when it's out. I also don't buy their gratuitous claim that "CPU/GPU do nothing and could be used" : used for what? Photoshop guys that compile their stuff need CPU horsepower, so do C++ guys, etc. I can't see a single reason why the CPU/GPU would be doing intensive graphics just because Microsoft has decided they would do this upfront in the operating system. The question that remains is whether anything of that can be disabled.
Stephane Can you give me links give to you're so called facts? I keen to see if Winforms are gonna be killed off as I'm working on my .net control library hopefully for commercial use, it would be a crying shame to put all that work into creating such a lbrary only to find Micrsoft (yet again) have steered people on to a new technology only to drop it a year later :confused:
-
Stephane Can you give me links give to you're so called facts? I keen to see if Winforms are gonna be killed off as I'm working on my .net control library hopefully for commercial use, it would be a crying shame to put all that work into creating such a lbrary only to find Micrsoft (yet again) have steered people on to a new technology only to drop it a year later :confused:
Normski wrote: I keen to see if Winforms are gonna be killed off Officially they don't. Here is the official agenda[^] (PPT doc from the .NET BCL architects). The problem is anything that is being done for Longhorn has nothing to do with winforms anymore. A clear example : all xaml-based UIs are rooted with the xml <window> tag, which in short is only an equivalent to the Window class. And that window class is the new root of the visual framework (think of it like the MFC CWnd class). The root of winforms is the Control class, and it has nothing to do with it. In fact, it cannot work since the creation/initialisation/running of a winform control relies on a classical (although buried) WIN32 msg pump (winforms is only a win32 wrapper). With xaml-based code, it's totally different. More on it? Check out the weblog of one the xaml horses : ChrisAn[^]. You'll see that even the early samples are clearly a 180 steer from the winforms-way of doing things.