4 ms·
Exactly. That small number of 32-bit Windows-running Backblaze customers might very well have legacy 16-bit applications that they need to continue to support.
by brianpgordon 9y ago
Exactly. That small number of 32-bit Windows-running Backblaze customers might very well have legacy 16-bit applications that they need to continue to support. It's remarkable that the author of this post completely missed that point, and in fact goes on and on about how you lose nothing by running 64-bit Windows.
- Joeri 9y agoThose customers can use emulation to cover their needs. The point of the article is that whatever benefits exist of the 32 bit skew, they are outweighed by its costs.
- tssva 9y agoFrom his perspective but not from the perspective of those who still need to maintain the systems using 16-bit apps. The costs of emulation and virtualization outweigh the cost of deploying a 32-bit version of Windows for them. Emulation and virtualization aren't always an option. For instance if the application is used to support a piece of hardware that needs to be physically connected. Also some methods of copy protection or license validation used then will not work with emulation or virtualization.
- tssva 9y agoTo be fair I think the number of 16-bit applications still in use would surprise a lot of people. The author responded to a comment I left on the blog about 16-bit applications and he seemed confused about when development of 16-bit applications would have ended. He seemed to think around 1988; however, the Win32 API wasn't rolled out to the desktop until 1995 with Windows 95. Internet Explorer was available in a 16-bit version until IE5 which was released in 1999. Most of the 16-bit applications I see still in production had last releases in the early 2000s.