|
Windows 8 is fueling the changes to visual studio as windows 8 is the .net framework as an operating system, the code for visual studio and windows 8 are the exact same.
|
|
|
|
|
Windows 8 is NOT "the .net framework as an operating system". I don't know where you get your information. Windows 8 RT requires you write user applications in .NET, but .NET is not the operating system.
Having a Visual Studio 2012, 2013 and 2014 are about marketing, not engineering.
It seems you never had a question, but are simply arguing for the sake of hearing yourself. (And it seems to have not occurred to you that many of us are well read on the history and inner workings of Windows and know people, including the actual engineers, who work on it at Microsoft.)
|
|
|
|
|
Windows 8 is the .net framework, nothing you say is going to change that.
|
|
|
|
|
I don't think Windows 8 was a paradigm shift. Metro didn't replace the desktop, rather metro was added as a way to create fullscreen touch-centric store apps. The desktop isn't going anywhere according to MS. I think the error in Win8 was pushing the metro environment too hard when it doesn't really have the ability to replace the desktop. Perhaps great for certain devices but not something for all use cases.
|
|
|
|
|
I don't care what you think.
The dot net framework is a paradigm shift which happened in 2003, and metro is the dot net framework as an operating system and the desktop is nothing but the old code.
Get over it.
|
|
|
|
|
Your enthusiasm for metro is great, but I think you're just missing the fact that metro targets a fairly narrow set of devices/apps. There are many scenarios where a touch-centric fullscreen store app is a great thing. But this environment doesn't have what it takes to replace everything. This is why metro isn't a paradigm shift, its simply a new avenue for creating apps which do work well in that limited context.
Also, MS has confirmed the desktop is and will continue to be a key piece of the puzzle moving forward. So, no, the desktop isn't going anywhere and isn't for "old code", its for code which doesn't fit in the rather narrow definition of fullscreen touch-centric store apps
Additionally it sounds like they'll be bringing the start menu back and allow running store apps in a window on the desktop. So the desktop is actually getting new focus and emphasis moving forward.
|
|
|
|
|
|
Colborne_Greg wrote: It will be a key piece in windows 8.
Yes, the desktop is a key piece in Windows 8. The metro start screen with its store apps is sort of a parallel environment. They're both there and they fill unique roles. But to say that metro replaces desktop or that there's a shift from desktop TO metro misses the fact that metro doesn't do everything needed by desktop apps and provides a much more narrow focus.
If rumors are true, the desktop will be getting increased emphasis in Windows 9.
Colborne_Greg wrote: Your opinion on the paradigm that did happen means nothing.
You sound very defensive regarding your position. Why did you post in the lounge if you thought any other opinion had no meaning? I'm beginning to think I've been feeding the troll
|
|
|
|
|
The desktop is code based on 1960s technology, the only reason people love it is the fact is has history, its a dinosaur and we only have to wait for the world to catch up - it will be gone because it can not advance.
|
|
|
|
|
I've been using Windows since 3.1 and the desktop has advanced significantly since then. So I believe its incorrect to say that the desktop environment can not advance, since it has done just that. I get that you're enthusiastic for a new metro environment, the problem is just that the new environment doesn't do everything needed. Maybe someday something will be able to replace the desktop, but I think metro isn't it at least not in its current state. That doesn't mean it can't do a great job for what its designed for -- full screen touch-centric store apps. But its not really a replacement for the desktop.
|
|
|
|
|
Research the 16 bit offset.
The desktop has it.
Metro does not.
This is the paradigm shift.
People can believe in god - but that doesn't make it true.
|
|
|
|
|
I'm not following you. Perhaps something more concrete to explain the point you're trying to make would help.
|
|
|
|
|
The 16-bit segment selector in the segment register is interpreted as the most significant 16 bits of a linear 20-bit address, called a segment address.
This is in every 32 bit application, including the desktop, 64 bit models use a flat memory model, as long as the operating system has the desktop and compatibility for 32 bit apps it will have this offset problem.
The .net framework removed the problem in 2003 and is the paradigm shift I am referring to.
Windows 8 is the only modern OS without this problem, apple has it and so does android.
|
|
|
|
|
Colborne_Greg wrote: as long as the operating system has the desktop and compatibility for 32 bit apps it will have this offset problem.
Colborne_Greg wrote: Windows 8 is the only modern OS without this problem
Windows 8 has the desktop and compatibility for 32 bit code. Backwards compatibility with 32-bit code is a big part of the amd64 design and supported by 64-bit Windows including Windows 8.
Having said that, 64- vs. 32-bit and backwards compatibility for 32-bit is a very different discussion than what you started with, namely to indicate that metro somehow replaces desktop and desktop is only for "old code". Seems like two completely different topics
|
|
|
|
|
Do we live in a 64 bit world?
We don't live in a world where apps are made correctly to use 64 bits, and this compatibility which metro does not have is why the desktop is there and is the only reason.
AMD is hardware as is Intel, otherwise operating systems like metro would not have a base line to advance from.
The desktop can not utilize 64 bits ever as the segment problem is in the heart of every programming language for the desktop.
|
|
|
|
|
No, the desktop is not there solely for 32-bit support. The desktop will remain because the metro full-screen app store environment isn't sufficient to handle everything. Metro addresses a particular need but doesn't replace what the desktop environment provides.
Win8 pushed metro a bit too hard and I think MS realized that which is why in 8.1 you can choose to boot directly to the desktop (and skip the start screen). It also appears with Windows 9 certain profiles (like desktop/laptop machine) will be very desktop-centric.
And yes, you can create a 64-bit desktop application. 64-bit is not restricted to Metro apps
Colborne_Greg wrote: The desktop can not utilize 64 bits ever as the segment problem is in the heart of every programming language for the desktop.
I think you're confused wrt programming languages and 32- vs 64- bit. Which programming languages "for the desktop" are you referring to? You can write in C++, for example, and compile that to either 32- or 64-bit code. The language itself doesn't restrict you to one or the other. Additionally, you can use C++ to create desktop applications and metro store apps. So "programming language for the desktop" doesn't really make any sense.
modified 3-Jul-14 11:52am.
|
|
|
|
|
I did not say the desktop could not have 64 bit apps.
I said that the desktop apps could not utilize the 64 bits, windows xp x64 edition, the best it could use was 54 bits.
32 bits can barely utilize 3.2 GB of RAM.
64 bits can handle billions of terabytes.
We have yet to have a machine that can handle over 200 GB of ram, and there isn't a desktop app in history that has been able to utilize even those 200 GB.
Just to keep the math simple.
if 3.2 GB is 32 bit then 6.4 GB is 33 bit, and
12.8 is 34 bit,
25.6 is 35 bit,
51.2 is 36 bit,
102.4 is 37 bit,
204.8 is 38 bit. <---- no desktop app has even gotten here.
n
The only benefit that the desktop has had from being 64 bit is being able to manage more then 3.2 GB of ram.
|
|
|
|
|
Yes, I recall reading this[^] article which discussed the limit in Win64 being 44 bits. So in 64-bit Windows you're not actually getting the full 64-bit address space. You are getting a LOT more than with 32-bits though
However, none of this has anything to do with desktop vs. metro which was the original discussion. For a given machine running 64-bit Windows 8, 64-bit code running as a desktop app or a metro windows store app will both be subject to the same limitations. The hardware/OS limitations apply equally to both.
|
|
|
|
|
Yeah it does
This whole problem is due to the 16 bit offset, the fact that 32 bit was built on top of it and so is 64 bit.
Only metro with the .net framework as the substructure which is a paradigm shift from the 16 bit offset; will software advance - therefore the desktop is a piece of sh*t.
|
|
|
|
|
1) You can build metro apps using native C++ code without going through the .net framework
2) You can use the .net framework to create either metro apps or desktop apps
3) Code using the .net framework is subject to the same Win64 address space limitations as any other process running on the machine
Whether you like it or not, the desktop isn't going anywhere
|
|
|
|
|
1) applications use metro and have to use these libraries, use whatever language you want
2) metro is the .net framework as an operating system (not limited by OS), .net framework is an add on to the desktop (limited by OS)
3) in windows 8 the desktop is an application of the metro memory address space.
The desktop is a piece of sh*t.
|
|
|
|
|
|
I program Microsoft technologies.
|
|
|
|
|
I think your obvious enthusiasm for metro is great, but I'm not sure you fully get how the pieces go together. I guess we'll have to just agree to disagree
|
|
|
|
|
I am telling you how it works.
|
|
|
|