Now it appears that that MS C++ compiler & linker could (very) occasionally benefit from a 64bit implementation... but Microsoft aren't making a 64bit version of VS so it must be really rare as they're pushing hard for 64bit only.
DevEnv is 32-bit only for now, but there's both 32bit and 64bit toolchains... the 64bit toolchain can't target 32bit executables, though.
As for assembly, it was quite a while ago now that C/C++ compliers became better assembly code generators than people. For a modern heavily optimising complier hand written assembler will usually perform worse than the code emitted by the compiler.
Depends on who is writing the assembly code, really. The benefit of a compiler is that, especially with PGO and LTCG, it can apply a lot of brute force that a human simply wouldn't have the time to do - netting some nice performance benefits. There's really no point in trying to beat the compiler for business apps, but if you're dealing with algorithm-heavy stuff, especially if you can utilize the fancy new CPU instructions, there's speed to be won.
and no matter how much you optimize, any system that actually requires 32 bit windows is probably old enough that the users are going to gripe about it being slow no matter what you do.
On the other hand, people with dog-old slow systems are the ones who benefit most from aggressive optimizations. And yes, if you don't install a gazillion leaky plugins, I do find that the recent firefox versions run pretty well.
Because the address space on 64-bit Windows is much larger than 4GB, something I’ll describe shortly, Windows can give 32-bit processes the maximum 4GB that they can address and use the rest for the operating system’s virtual memory.
Not sure that would work, but Visual Studio ships with the CRT source code... so you can just rebuild a CRT that doesn't depend on the imports not available on previous Windows versions.
It's a 32bit IDE, with a 32bit toolchain for producing 32bit executables, and a 64bit toolchain for 64bit executables:)
There's two parts to OS compatibility: 1) the CRT using some fancy new imports for security reasons, 2) setting OS version image fields, and refusing to set lower version numbers. Both can be overcome.
IMHO there's no reason that the browser itself needs to be compiled for x64 - I don't care about the silly purist arguments. Theoretically you can get some speedups for x64, but in the case of a browser you aren't going to take advantage of added x64 stuff... sure, you get more registers, but you also suffer from pointers doubling in size... and there's a lot of pointers involved in DOM and JavaScript.
Also, I don't see much point in the larger address space for browsers - "4GB should be enough", especially on a browser that uses process isolation for tabs.
VS2010 has fine intellisense for C++, it just doesn't have for C++/CLI. And while there aren't a 64bit DEVENV, the x64 compiler is a 64bit image. It cannot generate 32bit code, though, only x64.
You can do it with relatively few modifications to the CRT source (stuff like leaving out Encode/DecodePointer), there's some hints at stack overflow.
For Windows 2000 support, you'll need to manually hack ImageVersion flags in the PE, since for some fscktarded reason LINK.EXE refuses to set low enough versions.
No, it doesn't, it speaks about the amount of memory required when you try doing code optimization across an entire program image, instead sticking to optimizations inside translation unit boundaries.
Not translation units - when doing PGO, you also generally do LTCG across the entire program image, not within translation units. To overcome this, they'd have to split into a bunch of DLLs.
Not just licensing, but also driver compatibility issues - a lot of fscktards apparently have this idea that "hey, we're running a 32bit OS, so let's ignore the upper 32 bits of the PHYSICAL_ADDRESS structures"... which is plain old stupid. The first version of XP supported "4GB of physical ram" (and it's indeed licensing that caused it to not support more) - with SP1, it was reduced to "the lower 4GB of physical RAM" because of aforementioned fscktarded 3rd-party driver developers.
On top of that, it's not particularly funny to program for PAE modes, as you still only have a 4GB address space, so you have to shift a 'window' around to point at physical memory. It's extra code, and shifting the 'window' is a costly operation, so it's a fair amount of work to get right. It's really mostly useful for stuff like database buffer memory, not generic data structures.
It's true that only server editions of Windows supports PAE(*), but it wouldn't really be that much of a help for general-purpose apps... the code required to utilize it is simply way too much bother to write for most classes of applications, and programmers have been lazy since leaving the horrible 16bit days:)
(*): they've been running PAE since XP in order to use hardware no-execute, but not supporting MOAR MEMORYZ for licensing as well as driver compatibility reasons.
If we take him at his word that one failed and one didn't, then the one thing we know for 100% certain is that he did not use the same binaries, since one clearly would have to patched and the other unpatched.
Or the bug was triggered by hardware rather than software. Or the bug was in 3rd party drivers or application software, rather than the core OS install.
Both Windows 2000 and WinMe were released in 2000 (iirc Win2k a bit before WinMe). I made the switch from Win98SE (which was pretty stable, as long as you didn't run malicious/buggy 3rd party code... the most crashes I had were from pointer bugs in my own programs), and it ran everything just perfectly. MS should have dumped Win9x after Win98SE, and spent the effort used on the big WinME failure to help with polishing Win2k instead.
Yes, it did require more horsepower from your computer, it didn't have just as hardcore support for DOS programs and crappily written win9x programs, but it was stable and fast and ran newer games just fine (heck, even a lot of DOS stuff ran just fine).
Hell, every single web page generator, including Dirt, er, Word, and OpenOffice, when you export as HTML, *suck*. Old WP had F3, reveal *all* codes (unlike Word, which only shows what it thinks you have a need to know), and one look at that format, and you'd see they could have exported as *perfect* HTML.
I take it you never had formatting go awry in WP, usually happening after doing a bit of copy/paste here and there?:)
As much as I loved the DOS versions of WP for beeing bloody fast and efficient to work in, they weren't perfect, and the attempt at making Windows versions blowed hard.
I remember many guys that would stubbornly hold on to DOS, and one huge reason was the lack of stability in Windows 95.
For quite a while, I used a personal stripped-down version of Win95 (that was the time when you had a chance of knowing the purpose of every single file on your harddrive) with "shell=4dos.com". It was faster and more stable than vanilla DOS and DESQview, and with the additional benefit of being able to run the few win32 programs I used. Pretty darn solid, as long as I didn't memcpy to nullptrs.
Floppy copying and formatting was a pathological case, OS/2 and Amiga users (including myself) laughed at it, and it sucked - but it doesn't mean the OS wasn't preemptive.
I'm curious to know why was Windows 95 so unstable, then?
It's difficult to explain, and unless you have at least an MS in CS and several years hands on experience in OS internals it'll probably go right over your head. But anyway, here goes: it was pile of utter cunting shite.
I'd like to see you come up with a better solution that A) worked on the same class of hardware and B) had the same level of DOS and Win3.x support. Good luck.
95 didn't run on DOS. It kind of used DOS as a bootloader, but used its own drivers and kernel once loaded.
And it thunked down to DOS/BIOS for various routines. It tried it's best to detect "OK, this is a system that only has safe and wellknown drivers" and use almost exclusively 32bit drivers in that situation - but there were still some odd bits here and there.
Slashdot Mirror
Now it appears that that MS C++ compiler & linker could (very) occasionally benefit from a 64bit implementation ... but Microsoft aren't making a 64bit version of VS so it must be really rare as they're pushing hard for 64bit only.
DevEnv is 32-bit only for now, but there's both 32bit and 64bit toolchains... the 64bit toolchain can't target 32bit executables, though.
As for assembly, it was quite a while ago now that C/C++ compliers became better assembly code generators than people. For a modern heavily optimising complier hand written assembler will usually perform worse than the code emitted by the compiler.
Depends on who is writing the assembly code, really. The benefit of a compiler is that, especially with PGO and LTCG, it can apply a lot of brute force that a human simply wouldn't have the time to do - netting some nice performance benefits. There's really no point in trying to beat the compiler for business apps, but if you're dealing with algorithm-heavy stuff, especially if you can utilize the fancy new CPU instructions, there's speed to be won.
and no matter how much you optimize, any system that actually requires 32 bit windows is probably old enough that the users are going to gripe about it being slow no matter what you do.
On the other hand, people with dog-old slow systems are the ones who benefit most from aggressive optimizations. And yes, if you don't install a gazillion leaky plugins, I do find that the recent firefox versions run pretty well.
Not just Chen, but also Russinovich :)
You might want to read up on that :)
Because the address space on 64-bit Windows is much larger than 4GB, something I’ll describe shortly, Windows can give 32-bit processes the maximum 4GB that they can address and use the rest for the operating system’s virtual memory.
Not sure that would work, but Visual Studio ships with the CRT source code... so you can just rebuild a CRT that doesn't depend on the imports not available on previous Windows versions.
It's a 32bit IDE, with a 32bit toolchain for producing 32bit executables, and a 64bit toolchain for 64bit executables :)
There's two parts to OS compatibility: 1) the CRT using some fancy new imports for security reasons, 2) setting OS version image fields, and refusing to set lower version numbers. Both can be overcome.
Also, you don't understand what COM is.
In fairness, VC++ does have some baked-in COM magic - that's probably what DrYak was referring to.
Binary patch the CRT? Why don't you just recompile it from source?
Apart from not solving the problem :), doesn't it require having both VS2010 as well as the older VS installed?
IMHO there's no reason that the browser itself needs to be compiled for x64 - I don't care about the silly purist arguments. Theoretically you can get some speedups for x64, but in the case of a browser you aren't going to take advantage of added x64 stuff... sure, you get more registers, but you also suffer from pointers doubling in size... and there's a lot of pointers involved in DOM and JavaScript.
Also, I don't see much point in the larger address space for browsers - "4GB should be enough", especially on a browser that uses process isolation for tabs.
VS2010 has fine intellisense for C++, it just doesn't have for C++/CLI. And while there aren't a 64bit DEVENV, the x64 compiler is a 64bit image. It cannot generate 32bit code, though, only x64.
You can do it with relatively few modifications to the CRT source (stuff like leaving out Encode/DecodePointer), there's some hints at stack overflow.
For Windows 2000 support, you'll need to manually hack ImageVersion flags in the PE, since for some fscktarded reason LINK.EXE refuses to set low enough versions.
No, it doesn't, it speaks about the amount of memory required when you try doing code optimization across an entire program image, instead sticking to optimizations inside translation unit boundaries.
Not translation units - when doing PGO, you also generally do LTCG across the entire program image, not within translation units. To overcome this, they'd have to split into a bunch of DLLs.
Not just licensing, but also driver compatibility issues - a lot of fscktards apparently have this idea that "hey, we're running a 32bit OS, so let's ignore the upper 32 bits of the PHYSICAL_ADDRESS structures"... which is plain old stupid. The first version of XP supported "4GB of physical ram" (and it's indeed licensing that caused it to not support more) - with SP1, it was reduced to "the lower 4GB of physical RAM" because of aforementioned fscktarded 3rd-party driver developers.
On top of that, it's not particularly funny to program for PAE modes, as you still only have a 4GB address space, so you have to shift a 'window' around to point at physical memory. It's extra code, and shifting the 'window' is a costly operation, so it's a fair amount of work to get right. It's really mostly useful for stuff like database buffer memory, not generic data structures.
It's true that only server editions of Windows supports PAE(*), but it wouldn't really be that much of a help for general-purpose apps... the code required to utilize it is simply way too much bother to write for most classes of applications, and programmers have been lazy since leaving the horrible 16bit days :)
(*): they've been running PAE since XP in order to use hardware no-execute, but not supporting MOAR MEMORYZ for licensing as well as driver compatibility reasons.
You included your dog in the survey? You sick, sick person!
Does OS X run on anything that's not a PC?
Yes, this is a tongue-in-cheek question, but it's meant as a serious question and not merely a troll.
If we take him at his word that one failed and one didn't, then the one thing we know for 100% certain is that he did not use the same binaries, since one clearly would have to patched and the other unpatched.
Or the bug was triggered by hardware rather than software. Or the bug was in 3rd party drivers or application software, rather than the core OS install.
Nice attempt at a comeback, though.
Both Windows 2000 and WinMe were released in 2000 (iirc Win2k a bit before WinMe). I made the switch from Win98SE (which was pretty stable, as long as you didn't run malicious/buggy 3rd party code... the most crashes I had were from pointer bugs in my own programs), and it ran everything just perfectly. MS should have dumped Win9x after Win98SE, and spent the effort used on the big WinME failure to help with polishing Win2k instead.
Yes, it did require more horsepower from your computer, it didn't have just as hardcore support for DOS programs and crappily written win9x programs, but it was stable and fast and ran newer games just fine (heck, even a lot of DOS stuff ran just fine).
Hell, every single web page generator, including Dirt, er, Word, and OpenOffice, when you export as HTML, *suck*. Old WP had F3, reveal *all* codes (unlike Word, which only shows what it thinks you have a need to know), and one look at that format, and you'd see they could have exported as *perfect* HTML.
I take it you never had formatting go awry in WP, usually happening after doing a bit of copy/paste here and there? :)
As much as I loved the DOS versions of WP for beeing bloody fast and efficient to work in, they weren't perfect, and the attempt at making Windows versions blowed hard.
I remember many guys that would stubbornly hold on to DOS, and one huge reason was the lack of stability in Windows 95.
For quite a while, I used a personal stripped-down version of Win95 (that was the time when you had a chance of knowing the purpose of every single file on your harddrive) with "shell=4dos.com". It was faster and more stable than vanilla DOS and DESQview, and with the additional benefit of being able to run the few win32 programs I used. Pretty darn solid, as long as I didn't memcpy to nullptrs.
It wasn't even preemptive multitasking.
Wrong. (See above).
Floppy copying and formatting was a pathological case, OS/2 and Amiga users (including myself) laughed at it, and it sucked - but it doesn't mean the OS wasn't preemptive.
It's difficult to explain, and unless you have at least an MS in CS and several years hands on experience in OS internals it'll probably go right over your head. But anyway, here goes: it was pile of utter cunting shite.
I'd like to see you come up with a better solution that A) worked on the same class of hardware and B) had the same level of DOS and Win3.x support. Good luck.
95 didn't run on DOS. It kind of used DOS as a bootloader, but used its own drivers and kernel once loaded.
And it thunked down to DOS/BIOS for various routines. It tried it's best to detect "OK, this is a system that only has safe and wellknown drivers" and use almost exclusively 32bit drivers in that situation - but there were still some odd bits here and there.