All you have to trust are the compilers. The rest is mostly irrelevant. And since the 32-bit version runs just fine on a 64-bit AMD64 chip, what is the value of porting it? I'd personally rather have more work done on ironing out issues on the 32-bit version than on working on making a 64-bit version work.
Everything takes time. Adding 64-bit versions means cutting other work. It just isn't worth it at this point.
For programs where the 64-bit version has extra capabilities (speed, scalability) that the 32-bit version doesn't, the port to 32-bit native makes sense. Otherwise, why does it matter?
Not sure how you would do that in a way that stops buffer overflows. What would you expect to have happen with strcat? How can strcpy detect a buffer overflow? It might detect a really wild buffer overflow that wanders into read-only or unmapped address space, in which case you get an Access Violation (SegFault). In that case, all it could safely do is abort the program -- and that's what happens today. The dangerous buffer overflows are the ones that only overflow by a few hundred bytes. No Access Violation, since the memory is still valid. Without additional information, there is nothing msvcrt can do to detect that there was a problem.
I suppose it could check the address range of every parameter that got passed into it, and if it is about to write over the current function's stack frame it would abort, but what if you actually wanted to overwrite your stack frame? Anything they do would be breaking the C specifications.
The "Safe" versions are mostly versions that have an additional parameter with the buffer size. There are a very few versions with the same parameters but slightly different behavior in the edge cases, but mostly it is just the version you are familiar with plus an extra "max buffer size" parameter.
Nothing got "broken". But if you were abusing the CRT, you might now have to pay the price. As far as the deprecated functions -- if you #include certain headers (generally, if you directly or indirectly #include "strsafe.h"), you'll find that some APIs will cause compiler warnings or errors. Things like strcat and strcpy, which take no buffer lengths, are quite dangerous. Yes, the programmer can verify things before calling them, but if you screw up once, you have a problem. The replacements all require the buffer length to be specified.
This usually is from Link-Time-Code-Generation. This is a nifty optimization that can make a big difference in some cases, but it makes linking take a lot longer.
Remove the/GL flag from the compile, and remove the/LTCG flag from link. Your build times should go down significantly.
1. Resources. It might slow down the system while scanning for the nul. 2. SegFault is still not a good idea. 3. Most important: The result from strlen gets used elsewhere. If the string is unterminated, you've just put a large random number into your code. Somebody else might assume that the result from strlen is a reasonable size (10-20 bytes), when it really is more like 10k, and you weren't prepared for a 10k string.
Actually, you can do whatever you want with the warnings.
Every warning has a default level, either "error", "1", "2", "3", "4", or disabled. You can change the level of any warning. You do this via #pragma warning. Typically, you will create a customized "warning.h" file that has all of your warning settings, and you will include it into your compile with the/FI(file) command line option.
Like a warning? Promote it to level "1" or make it an error. Don't like a warning? Make it level "4" or disable it.
FYI, here's how we have it set up for our builds:
We normally build with/W3 (warnings at level 3 or less are enabled)/WX (any warning is treated as an error). When we upgrade compilers, we remove/WX until we've cleaned up all new warnings, then put it back. In a few cases where we have generated code (such as code created by MIDL or LEX/YACC) that doesn't compile at/W3, we compile at/W2 instead.
Most warnings are fine at the default Visual C++ level. A few are adjusted up or down in our warning.h file.
All warnings that should never ever ship are set as errors. This way, even during the short times when/WX is not applied to our build, we still won't let any serious issues into the code.
Warning level 1 is for "transitional" warnings -- warnings that I want to upgrade to "error" ASAP, but can't yet because we still have a few of them in the codebase. (Currently: None in this category. Yay!)
Most warnings go in level 2.
Warning level 3 is reserved for warnings that appear in generated code. MIDL, LEX, and YACC are allowed to trigger these warnings, but nobody else is.
Warning level 4 is for "lint" type warnings -- things that the developer might want to see, but aren't always bad. We provide a build option that allows a developer to rebuild their code at/W4 and with "warning-as-error" disabled as a kind of "lint" check.
Warnings that are simply stupid are disabled. (Currently: None in this category that weren't disabled by default by VC. Yay!)
Another thing to keep in mind that when you do this, your program's "Entry Point" is NOT "int main(char**, int)" or "int WinMain(HINSTANCE, HINSTANCE, LPSTR, int)". The raw entry point is simply "int MyEntryPoint()" with NO parameters (name doesn't matter since you just pass the name of the entry point to the linker). You can call it main or WinMain, and you can specify whatever parameters you want, but the parameters won't be initialized.
Normally, the CRT provides the raw entry point, initializes itself (initializes all globals). It calls kernel32.dll to get the command line, parses it, and calls either WinMain() or main() depending on various factors. So if you want the command line, you'll have to get it via GetCommandLine() and parse it yourself.
The nice thing is that by doing all of this, you can actually write a useful C++ program that is only 1024 bytes. (It is probably possible to get a Win32 program into 512 bytes, but I don't think it is possible with the C++ compiler and linker -- you'd have to hex-edit the binary by hand.)
VC 6 was released in 98. Do you develop apps for the latest version of Linux with GCC 2.8 (VC 6's contemporary) and GLibC 2.0.7? If you're targeting older platforms (Windows 98), I could see why you might want to stick with VC 6. But otherwise, use the best tool for the job.
Since VC was released, there have been 7 years of bug fixes and improvements to the compiler. Lots of new optimizations, warnings, and security features. Not all of them are trivial. And the runtime has had a lot of work -- much closer to the C++ spec.
Finally, VC 6.0 is no longer supported by Microsoft. No bug fixes, patches, security checks, etc. The 6.0 CRT might still get updated, but the compiler won't.
The longer you wait before upgrading, the harder it is to upgrade. It may actually take less time total to do it less often, but the process is much smoother and causes fewer problems if you keep up to date.
I work at MS, and we generally stay on top with compilers. In fact, our new security policies require all shipping code to be compiled with the 7.1 compilers, and pretty soon all code will be required to use 8.0.
I'm the one who upgraded our 2-million line product from 6.0 to 7.1 and from 7.1 to 8.0. In the process, we had about 20,000 compile errors or warnings to fix. I think I was able to fix about 5,000 per week. It was a lot of work, but we actually found bugs and issues in the code. It was certainly worth the effort. Note that we don't actually use the VS IDE to build -- we use the compiler directly from the command line with makefiles.
In general, I would update to the new compiler and turn off all of the new warnings and errors until I got everything building. Then I would re-enable all of the new warnings and work on fixing them. Use the/Zc:forscope- and/Zc:wchar_t- flags at first. One thing to be aware of is that some "errors" are actually warnings that are turned up to "error" status (see the/we flag). These can be changed with the/w flag or with a #pragma warning.
Advantages to the new compiler:
* Better C++ Standards compliance. * Much better code generation (your program runs faster). * Many fixed "Internal Compiler Error" issues. * A few fixed code generation (invalid optimization) issues. * Many new warnings about things that deserve them. * Much better debug information. * Much better handling of templates.
Disadvantages to the new compiler:
* Somewhat slower compile time in some cases. * Larger PDB (debug symbol) files.
Advantages to new C library:
* Much better C++ compliance. * Many bugs fixed. * Better performance. * Many security fixes.
Disadvantages to new C library:
* Cannot expect runtime to be present on the user's system. (msvcrt.dll and mfc42.dll are already installed on most computers, but msvcr71.dll and mfc71.dll are not). * Some porting incompatibilities.
Advantages to the new Visual Studio IDE:
* Better Intellisense. * Support for excellent code coverage, profiling, unit test, and static analysis tools. * Better debugging. * Supported (VS 6.0 is 7 years old now -- all support for it is over).
Disadvantages to the new IDE:
* Uses more memory and system resources. * Beta version has several performance issues. The final version should fix them (cross fingers).
General issues:
* You'll need to recreate your project (*.dsp) and workspace (*.dsw) files. * Some porting will be required for MFC and ATL apps. * You may hit one or two CRT changes. * You may have several thousand warnings or errors. Nearly all of these can be eliminated via compiler flags or #pragmas, but you should really fix them if possible. * Some CRT functions have been deprecated. You can add a #define to ignore this, but if you care about buffer overflows in your code, you should really take a look at using the "safe" versions.
Umm, no, not specifically for extending games
on
Extending Games With Lua
·
· Score: 5, Informative
Lua was definitely not designed specifically for extending games. It is a general purpose scripting language designed to be easy to embed and easy to use. It has been embedded into a number of games because it is hightly suited for this kind of embedding, but it was not originally intended for games.
I've been working with Lua off and on for a while. I have to say that it is pretty darn cool. It is really easy to embed, really easy to extend, and really lightweight (about 90k or so). The language is very simple, but still supports a lot of advanced programming concepts like closures.
Sorry about the troll business. As far as Slashdot "these days" -- it has never been particularly high on the "average IQ" or "institution for insight and even-handedness" scales. But it isn't all bad. People need to realize that there are two (or three) sides to every story.
No, no, no. Well, actually, Yes, no, no..NET does wait until an allocation request fails before running the GC, but the allocation request is done against a pre-allocated pool much smaller than "available memory and swap". Once the pre-allocated pool is full, GC is performed. Only when the GC doesn't free up enough memory (as determined by some heuristic, not necessarily "enough to fulfill the current allocation request") does the system allocate additional memory from the OS.
I've got plenty of long-running.NET apps that behave just fine and stabilize long before running Windows out of swap space. I don't work with SharpDevelop, but it sounds like it either has leaks, excessive memory requirements, or poor memory usage patterns, as the behavior you indicate is not an inevitable consequence of.NET or Java's design. It is a bug in the application, not a problem with.NET.
Um, yeah, this is professional experience. I've been working for Microsoft for many years now.
Compilers: Microsoft has to rewrite the compilers to handle AMD64. Not a trivial task (easy to get working, harder to get working right, and much harder to get working right and fast). The guy in the office next to mine is responsible for much of the non-X86 compiler work here, and sometimes over lunch I get to hear about the latest and greatest headaches from the AMD64 (actually, "X64" is now the "politically correct" term) compiler port. X64 is a much more complex architecture than Alpha. Getting the compiler done well is a lot more work.
Drivers: Yes, Microsoft provides lots of drivers on the Windows CD. Why does that mean everything is easy? Microsoft still has to get each one of those drivers working correctly on the AMD64 architecture. The port is quite often non-trivial. And a lot of the drivers actually are maintained by the manufacturer, even if the driver is on the Windows CD, since the manufacturer doesn't want to reveal their precious IP (and Microsoft doesn't want to have to write their drivers for them either). That means that Microsoft has to wait for the individual companies to rewrite the drivers for AMD64, test them, and put them on the Windows CD. That isn't an easy or quick task. Supported hardware for Alpha was much more limited.
Applications: You're talking about emulation (Windows on Windows, etc.). I'm talking about making all of those apps perform well as native 64-bit apps. The apps that ship with 64-bit Windows generally aren't just the 32-bit versions -- they're full 64-bit ports. A lot of these apps were never available on the Alpha version.
Backwards compatibility for 32-bit apps: Yep. So Microsoft had to write WoW and make it work correctly. Took a LOT of work. That's one of the reasons why it took so long to get it out the door. There was an emulation layer for Alpha, but it was a much simpler system, and near-perfect backwards compatibility wasn't a requirement.
Thunking: Now I'm confused. The link you mentioned discussed how 32-bit apps get thunked up to 64-bits for kernel calls, and the return value from the kernel gets thunked back down. I don't see anything about thunking 64-bit apps down to 32 bits for anything. I suppose that in the case where you are communicating between a 64-bit app and a 32-bit app, you would do thunking down to 32-bits, but that really can't be avoided.
Huh? Is this a troll? If not, you really don't know what you're talking about.
You're right that porting the Windows NT kernel to another architecture is actually pretty simple -- rewrite the HAL, recompile everything for 64 bits, you're done. The hard part is getting everything else verified as 64-bit clean.
-- Compilers -- Drivers -- Applications (Shell, Notepad, Media Player, Explorer) -- Backwards compatibility for 32-bit apps
And you're not thunking down to 32 bits. You're thunking your 32 bit apps up to 64 bits...
Voltage is per-cell. AA, AAA, C, and D cells have one cell. 9v alkaline batteries have 6 cells. 6 x 1.5 = 9. Your 12v alkaline batteries have 8 cells.
The chemistry of the battery leads to an inherent specific single-cell voltage. How that voltage varies with load can be affected by design changes (ion concentrations, etc.), but the no-load voltage of the cell is an inherent characteristic of the battery's chemistry.
Any kind of document is searchable. You just have to get the right "filter". Adobe has one for PDFs. Install it, wait a while, and search. All of your PDFs are now searchable!
I have a C++ and a C# filter installed on my system. While you can treat C++ and C# as straight text, the filters handle distinguishing "definition" from "use", so you can find where Widget() is defined without checking each of the 5000 places it is used. It makes searching through huge codebases really easy.
Not quality. It's effort. How much effort do you spend looking for additional ways to squeeze out a few more bytes.
ZIP has the same thing. ZIP -9 usually gets 1%-5% better compression, depending on what you're compressing. IIRC, it uses a larger window to do this. In other words, if you repeat yourself every, say, 32k, ZIP -9 would notice the repetition and be able to compress it out, but ZIP -5 would not.
Slashdot Mirror
All you have to trust are the compilers. The rest is mostly irrelevant. And since the 32-bit version runs just fine on a 64-bit AMD64 chip, what is the value of porting it? I'd personally rather have more work done on ironing out issues on the 32-bit version than on working on making a 64-bit version work.
Everything takes time. Adding 64-bit versions means cutting other work. It just isn't worth it at this point.
For programs where the 64-bit version has extra capabilities (speed, scalability) that the 32-bit version doesn't, the port to 32-bit native makes sense. Otherwise, why does it matter?
Not sure how you would do that in a way that stops buffer overflows. What would you expect to have happen with strcat? How can strcpy detect a buffer overflow? It might detect a really wild buffer overflow that wanders into read-only or unmapped address space, in which case you get an Access Violation (SegFault). In that case, all it could safely do is abort the program -- and that's what happens today. The dangerous buffer overflows are the ones that only overflow by a few hundred bytes. No Access Violation, since the memory is still valid. Without additional information, there is nothing msvcrt can do to detect that there was a problem.
I suppose it could check the address range of every parameter that got passed into it, and if it is about to write over the current function's stack frame it would abort, but what if you actually wanted to overwrite your stack frame? Anything they do would be breaking the C specifications.
The "Safe" versions are mostly versions that have an additional parameter with the buffer size. There are a very few versions with the same parameters but slightly different behavior in the edge cases, but mostly it is just the version you are familiar with plus an extra "max buffer size" parameter.
Breaking Changes in the Standard C++ Library Since Visual C++ 6.0
If you are upgrading a program that uses Standard C++ Library code that compiled in Visual C++ 6.0, you should be aware of the following issues:
Nothing got "broken". But if you were abusing the CRT, you might now have to pay the price. As far as the deprecated functions -- if you #include certain headers (generally, if you directly or indirectly #include "strsafe.h"), you'll find that some APIs will cause compiler warnings or errors. Things like strcat and strcpy, which take no buffer lengths, are quite dangerous. Yes, the programmer can verify things before calling them, but if you screw up once, you have a problem. The replacements all require the buffer length to be specified.
Yes. I was happy to see it come back. Great profiler with code coverage and everything.
People seem to forget that you can create scopes at will.
// Scope for the "i" variable.
...
// Scope for the "i" variable.
...
void myfunc()
{
{
for (int i = 0; i < 10; i++)
{
}
}
{
for (int i = 0; i < 10; i++)
{
}
}
}
You might be able to avoid even that. Try adding /Oi to the command line.
This usually is from Link-Time-Code-Generation. This is a nifty optimization that can make a big difference in some cases, but it makes linking take a lot longer.
/GL flag from the compile, and remove the /LTCG flag from link. Your build times should go down significantly.
Remove the
Three issues:
1. Resources. It might slow down the system while scanning for the nul.
2. SegFault is still not a good idea.
3. Most important: The result from strlen gets used elsewhere. If the string is unterminated, you've just put a large random number into your code. Somebody else might assume that the result from strlen is a reasonable size (10-20 bytes), when it really is more like 10k, and you weren't prepared for a 10k string.
Actually, you can do whatever you want with the warnings.
/FI(file) command line option.
/W3 (warnings at level 3 or less are enabled) /WX (any warning is treated as an error). When we upgrade compilers, we remove /WX until we've cleaned up all new warnings, then put it back. In a few cases where we have generated code (such as code created by MIDL or LEX/YACC) that doesn't compile at /W3, we compile at /W2 instead.
/WX is not applied to our build, we still won't let any serious issues into the code.
/W4 and with "warning-as-error" disabled as a kind of "lint" check.
Every warning has a default level, either "error", "1", "2", "3", "4", or disabled. You can change the level of any warning. You do this via #pragma warning. Typically, you will create a customized "warning.h" file that has all of your warning settings, and you will include it into your compile with the
Like a warning? Promote it to level "1" or make it an error. Don't like a warning? Make it level "4" or disable it.
FYI, here's how we have it set up for our builds:
We normally build with
Most warnings are fine at the default Visual C++ level. A few are adjusted up or down in our warning.h file.
All warnings that should never ever ship are set as errors. This way, even during the short times when
Warning level 1 is for "transitional" warnings -- warnings that I want to upgrade to "error" ASAP, but can't yet because we still have a few of them in the codebase. (Currently: None in this category. Yay!)
Most warnings go in level 2.
Warning level 3 is reserved for warnings that appear in generated code. MIDL, LEX, and YACC are allowed to trigger these warnings, but nobody else is.
Warning level 4 is for "lint" type warnings -- things that the developer might want to see, but aren't always bad. We provide a build option that allows a developer to rebuild their code at
Warnings that are simply stupid are disabled. (Currently: None in this category that weren't disabled by default by VC. Yay!)
Another thing to keep in mind that when you do this, your program's "Entry Point" is NOT "int main(char**, int)" or "int WinMain(HINSTANCE, HINSTANCE, LPSTR, int)". The raw entry point is simply "int MyEntryPoint()" with NO parameters (name doesn't matter since you just pass the name of the entry point to the linker). You can call it main or WinMain, and you can specify whatever parameters you want, but the parameters won't be initialized.
Normally, the CRT provides the raw entry point, initializes itself (initializes all globals). It calls kernel32.dll to get the command line, parses it, and calls either WinMain() or main() depending on various factors. So if you want the command line, you'll have to get it via GetCommandLine() and parse it yourself.
The nice thing is that by doing all of this, you can actually write a useful C++ program that is only 1024 bytes. (It is probably possible to get a Win32 program into 512 bytes, but I don't think it is possible with the C++ compiler and linker -- you'd have to hex-edit the binary by hand.)
Yes, you can. You just have to disable the compiler features that correspond to the function calls you don't want.
/GZ or /RTCs compiler switches. Turn off the "Runtime Checks" options.
/GX or /EH??. Turn off the "Exception Handling" options.
_RTC_CheckEsp comes from the
___CxxFrameHandler comes from
With more recent versions, you might see something about "security_cookie". For that, turn off the buffer overflow detection (/GS).
Good luck!
VC 6 was released in 98. Do you develop apps for the latest version of Linux with GCC 2.8 (VC 6's contemporary) and GLibC 2.0.7? If you're targeting older platforms (Windows 98), I could see why you might want to stick with VC 6. But otherwise, use the best tool for the job.
Since VC was released, there have been 7 years of bug fixes and improvements to the compiler. Lots of new optimizations, warnings, and security features. Not all of them are trivial. And the runtime has had a lot of work -- much closer to the C++ spec.
Finally, VC 6.0 is no longer supported by Microsoft. No bug fixes, patches, security checks, etc. The 6.0 CRT might still get updated, but the compiler won't.
The longer you wait before upgrading, the harder it is to upgrade. It may actually take less time total to do it less often, but the process is much smoother and causes fewer problems if you keep up to date.
I work at MS, and we generally stay on top with compilers. In fact, our new security policies require all shipping code to be compiled with the 7.1 compilers, and pretty soon all code will be required to use 8.0.
/Zc:forscope- and /Zc:wchar_t- flags at first. One thing to be aware of is that some "errors" are actually warnings that are turned up to "error" status (see the /we flag). These can be changed with the /w flag or with a #pragma warning.
I'm the one who upgraded our 2-million line product from 6.0 to 7.1 and from 7.1 to 8.0. In the process, we had about 20,000 compile errors or warnings to fix. I think I was able to fix about 5,000 per week. It was a lot of work, but we actually found bugs and issues in the code. It was certainly worth the effort. Note that we don't actually use the VS IDE to build -- we use the compiler directly from the command line with makefiles.
In general, I would update to the new compiler and turn off all of the new warnings and errors until I got everything building. Then I would re-enable all of the new warnings and work on fixing them. Use the
Advantages to the new compiler:
* Better C++ Standards compliance.
* Much better code generation (your program runs faster).
* Many fixed "Internal Compiler Error" issues.
* A few fixed code generation (invalid optimization) issues.
* Many new warnings about things that deserve them.
* Much better debug information.
* Much better handling of templates.
Disadvantages to the new compiler:
* Somewhat slower compile time in some cases.
* Larger PDB (debug symbol) files.
Advantages to new C library:
* Much better C++ compliance.
* Many bugs fixed.
* Better performance.
* Many security fixes.
Disadvantages to new C library:
* Cannot expect runtime to be present on the user's system. (msvcrt.dll and mfc42.dll are already installed on most computers, but msvcr71.dll and mfc71.dll are not).
* Some porting incompatibilities.
Advantages to the new Visual Studio IDE:
* Better Intellisense.
* Support for excellent code coverage, profiling, unit test, and static analysis tools.
* Better debugging.
* Supported (VS 6.0 is 7 years old now -- all support for it is over).
Disadvantages to the new IDE:
* Uses more memory and system resources.
* Beta version has several performance issues. The final version should fix them (cross fingers).
General issues:
* You'll need to recreate your project (*.dsp) and workspace (*.dsw) files.
* Some porting will be required for MFC and ATL apps.
* You may hit one or two CRT changes.
* You may have several thousand warnings or errors. Nearly all of these can be eliminated via compiler flags or #pragmas, but you should really fix them if possible.
* Some CRT functions have been deprecated. You can add a #define to ignore this, but if you care about buffer overflows in your code, you should really take a look at using the "safe" versions.
Lua was definitely not designed specifically for extending games. It is a general purpose scripting language designed to be easy to embed and easy to use. It has been embedded into a number of games because it is hightly suited for this kind of embedding, but it was not originally intended for games.
I've been working with Lua off and on for a while. I have to say that it is pretty darn cool. It is really easy to embed, really easy to extend, and really lightweight (about 90k or so). The language is very simple, but still supports a lot of advanced programming concepts like closures.
Sorry about the troll business. As far as Slashdot "these days" -- it has never been particularly high on the "average IQ" or "institution for insight and even-handedness" scales. But it isn't all bad. People need to realize that there are two (or three) sides to every story.
You have to enable QuickEdit for your console (properties menu). With QuickEdit off, you have to use the menu in the top left corner.
No, no, no. Well, actually, Yes, no, no. .NET does wait until an allocation request fails before running the GC, but the allocation request is done against a pre-allocated pool much smaller than "available memory and swap". Once the pre-allocated pool is full, GC is performed. Only when the GC doesn't free up enough memory (as determined by some heuristic, not necessarily "enough to fulfill the current allocation request") does the system allocate additional memory from the OS.
.NET apps that behave just fine and stabilize long before running Windows out of swap space. I don't work with SharpDevelop, but it sounds like it either has leaks, excessive memory requirements, or poor memory usage patterns, as the behavior you indicate is not an inevitable consequence of .NET or Java's design. It is a bug in the application, not a problem with .NET.
I've got plenty of long-running
Actually, it runs in 32 MB RAM and takes a 200 MHz ARM processor.
Though that would still kill your blackberry...
Um, yeah, this is professional experience. I've been working for Microsoft for many years now.
Compilers: Microsoft has to rewrite the compilers to handle AMD64. Not a trivial task (easy to get working, harder to get working right, and much harder to get working right and fast). The guy in the office next to mine is responsible for much of the non-X86 compiler work here, and sometimes over lunch I get to hear about the latest and greatest headaches from the AMD64 (actually, "X64" is now the "politically correct" term) compiler port. X64 is a much more complex architecture than Alpha. Getting the compiler done well is a lot more work.
Drivers: Yes, Microsoft provides lots of drivers on the Windows CD. Why does that mean everything is easy? Microsoft still has to get each one of those drivers working correctly on the AMD64 architecture. The port is quite often non-trivial. And a lot of the drivers actually are maintained by the manufacturer, even if the driver is on the Windows CD, since the manufacturer doesn't want to reveal their precious IP (and Microsoft doesn't want to have to write their drivers for them either). That means that Microsoft has to wait for the individual companies to rewrite the drivers for AMD64, test them, and put them on the Windows CD. That isn't an easy or quick task. Supported hardware for Alpha was much more limited.
Applications: You're talking about emulation (Windows on Windows, etc.). I'm talking about making all of those apps perform well as native 64-bit apps. The apps that ship with 64-bit Windows generally aren't just the 32-bit versions -- they're full 64-bit ports. A lot of these apps were never available on the Alpha version.
Backwards compatibility for 32-bit apps: Yep. So Microsoft had to write WoW and make it work correctly. Took a LOT of work. That's one of the reasons why it took so long to get it out the door. There was an emulation layer for Alpha, but it was a much simpler system, and near-perfect backwards compatibility wasn't a requirement.
Thunking: Now I'm confused. The link you mentioned discussed how 32-bit apps get thunked up to 64-bits for kernel calls, and the return value from the kernel gets thunked back down. I don't see anything about thunking 64-bit apps down to 32 bits for anything. I suppose that in the case where you are communicating between a 64-bit app and a 32-bit app, you would do thunking down to 32-bits, but that really can't be avoided.
Huh? Is this a troll? If not, you really don't know what you're talking about.
You're right that porting the Windows NT kernel to another architecture is actually pretty simple -- rewrite the HAL, recompile everything for 64 bits, you're done. The hard part is getting everything else verified as 64-bit clean.
-- Compilers
-- Drivers
-- Applications (Shell, Notepad, Media Player, Explorer)
-- Backwards compatibility for 32-bit apps
And you're not thunking down to 32 bits. You're thunking your 32 bit apps up to 64 bits...
SQL Server 2000 is available in a 64 bit edition.
Voltage is per-cell. AA, AAA, C, and D cells have one cell. 9v alkaline batteries have 6 cells. 6 x 1.5 = 9. Your 12v alkaline batteries have 8 cells.
The chemistry of the battery leads to an inherent specific single-cell voltage. How that voltage varies with load can be affected by design changes (ion concentrations, etc.), but the no-load voltage of the cell is an inherent characteristic of the battery's chemistry.
Any kind of document is searchable. You just have to get the right "filter". Adobe has one for PDFs. Install it, wait a while, and search. All of your PDFs are now searchable!
I have a C++ and a C# filter installed on my system. While you can treat C++ and C# as straight text, the filters handle distinguishing "definition" from "use", so you can find where Widget() is defined without checking each of the 5000 places it is used. It makes searching through huge codebases really easy.
Not quality. It's effort. How much effort do you spend looking for additional ways to squeeze out a few more bytes.
ZIP has the same thing. ZIP -9 usually gets 1%-5% better compression, depending on what you're compressing. IIRC, it uses a larger window to do this. In other words, if you repeat yourself every, say, 32k, ZIP -9 would notice the repetition and be able to compress it out, but ZIP -5 would not.
Thanks! I knew I could find one if I went trolling.
And they say you're not supposed to feed the trolls...