I have previously posted about fun adventures running insider preview builds of Windows 10, with Delphi. Now, I no longer run insider preview builds because the problems are just not worth it.
However, as Microsoft believes your computer belongs to them once you put Windows 10 on it, you now have to deal with your "windows 10" (pronounced "Windows is like a box of chocolates, you never know what you're gonna get") system will daily, or weekly, break stuff and die randomly on you.
In the midst of a global panic over a real virus, I would like to add that I feel that Windows 10 is a virus.
I can't rely on Windows 10 not to :
1. Ship new stuff I don't want.
2. Turn back on options that I turn off, like windows defender realtime protection.
3. Break production binary applications, for which I have no source code, most importantly Delphi itself, which I need to do my job.
4. Work the same way on all the hardware I own. One build of windows will be a disaster and crash repeatedly, but work fine on other hardware I own. Build 1903 worked on one of my PCs but not the other, and now build 1909 works on one of my PCs and not the other.
Most recently, I can no longer operate Delphi 10 seattle which is the version my employer's production codebases are relying on. (When you work in a team, by the way, one person can't just move versions, so if you suggest that I should move to a new delphi version, I'll just ignore you as we're going to do that when we all do that, as I belong to a team.)
Here are three of the fun problems that I'm seeing:
1. If ever you had to set up a new PC on a new windows build and get it going with Seattle, and Windows build 1909, good luck. To get a preview of the fun you'll have, you could rename (god forbid you should ever ever delete) the registry BDS\17 registry key, Delphi can not create a valid new setup and start up without crashing. You get an access violation in coreide230.bpl. If you have a valid backup of a working BDS\17 registry key, you can recover it. Anyone using Seattle on Windows 10, please keep backups of your BDS\17 key under your Current User registry settings.
2. (UPDATE:Fixed in recent Win10 quality update) Delphi is unable to build our projects without dying during the write DCU phase randomly. This was always bad on some peoples computers, but usually not on mine, and now I can no longer operate the IDE and compile or build the main projects I need to compile for my day job.
3. (UPDATE: Happens less in build 1909 than build 1903, but still a problem.) Delphi's debugger when reset, is hanging the Windows 10 1903 and 1909 kernel hard, on some systems, for some applications, mostly ones that seem to have certain DLLs loading and unloading in them.
I'll post solutions if I find them, but if I don't, I'm going to move into a Win7 VM for all development, because Windows 10 is not something you can trust. What's most odd is I have a Win10 VM running build 1909 and this issue is NOT happening in the VM.
UPDATE: On the latest quality update of Windows 10 build 1909, on the main machine that was having these issues, the problems with the bds.exe executing delphi compiler within the IDE (point 2) is resolved.
UPDATE2: Still no workaround known for Point 1 other than to keep your working backups of registry in current user.
UPDATE3: A new issue that is less grievous but still annoying has appeared. The USB User Mode Driver Framework has started hanging. The main symptom is that all USB attached peripherals including external mouse and keyboard stop working for about 30 seconds while some core Windows user mode driver framework bits restart themselves. I can trigger it by resetting the delphi debugger. Something about terminating the process being debugged, which may be holding onto a handle for some device driver related object somehow, seems to trigger a crash in a usb driver, which somehow then crashes the host process.
UPDATE4: Although my main work machine is unaffected, build 1903 and build 1909 are "bricking themselves" (failing to boot) after something in the windows update process corrupts the boot time data storage area (BCD) of the Windows boot volume (Drive C). This happens repeatably on certain Lenovo Thinkpad hardware. I suspect a kernel-mode panic during boot due to a driver bug in the chipset drivers.
However, as Microsoft believes your computer belongs to them once you put Windows 10 on it, you now have to deal with your "windows 10" (pronounced "Windows is like a box of chocolates, you never know what you're gonna get") system will daily, or weekly, break stuff and die randomly on you.
In the midst of a global panic over a real virus, I would like to add that I feel that Windows 10 is a virus.
I can't rely on Windows 10 not to :
1. Ship new stuff I don't want.
2. Turn back on options that I turn off, like windows defender realtime protection.
3. Break production binary applications, for which I have no source code, most importantly Delphi itself, which I need to do my job.
4. Work the same way on all the hardware I own. One build of windows will be a disaster and crash repeatedly, but work fine on other hardware I own. Build 1903 worked on one of my PCs but not the other, and now build 1909 works on one of my PCs and not the other.
Most recently, I can no longer operate Delphi 10 seattle which is the version my employer's production codebases are relying on. (When you work in a team, by the way, one person can't just move versions, so if you suggest that I should move to a new delphi version, I'll just ignore you as we're going to do that when we all do that, as I belong to a team.)
Here are three of the fun problems that I'm seeing:
1. If ever you had to set up a new PC on a new windows build and get it going with Seattle, and Windows build 1909, good luck. To get a preview of the fun you'll have, you could rename (god forbid you should ever ever delete) the registry BDS\17 registry key, Delphi can not create a valid new setup and start up without crashing. You get an access violation in coreide230.bpl. If you have a valid backup of a working BDS\17 registry key, you can recover it. Anyone using Seattle on Windows 10, please keep backups of your BDS\17 key under your Current User registry settings.
2. (UPDATE:Fixed in recent Win10 quality update) Delphi is unable to build our projects without dying during the write DCU phase randomly. This was always bad on some peoples computers, but usually not on mine, and now I can no longer operate the IDE and compile or build the main projects I need to compile for my day job.
3. (UPDATE: Happens less in build 1909 than build 1903, but still a problem.) Delphi's debugger when reset, is hanging the Windows 10 1903 and 1909 kernel hard, on some systems, for some applications, mostly ones that seem to have certain DLLs loading and unloading in them.
I'll post solutions if I find them, but if I don't, I'm going to move into a Win7 VM for all development, because Windows 10 is not something you can trust. What's most odd is I have a Win10 VM running build 1909 and this issue is NOT happening in the VM.
UPDATE: On the latest quality update of Windows 10 build 1909, on the main machine that was having these issues, the problems with the bds.exe executing delphi compiler within the IDE (point 2) is resolved.
UPDATE2: Still no workaround known for Point 1 other than to keep your working backups of registry in current user.
UPDATE3: A new issue that is less grievous but still annoying has appeared. The USB User Mode Driver Framework has started hanging. The main symptom is that all USB attached peripherals including external mouse and keyboard stop working for about 30 seconds while some core Windows user mode driver framework bits restart themselves. I can trigger it by resetting the delphi debugger. Something about terminating the process being debugged, which may be holding onto a handle for some device driver related object somehow, seems to trigger a crash in a usb driver, which somehow then crashes the host process.
UPDATE4: Although my main work machine is unaffected, build 1903 and build 1909 are "bricking themselves" (failing to boot) after something in the windows update process corrupts the boot time data storage area (BCD) of the Windows boot volume (Drive C). This happens repeatably on certain Lenovo Thinkpad hardware. I suspect a kernel-mode panic during boot due to a driver bug in the chipset drivers.
Good idea, but even better if you can just convince your Project Manager to upgrade the product subscription license to the latest version. Justify through financial projections about the cost savings, and the benefits of better performing and improved software could have on productivity and efficiency of business operations, giving you an edge over your competitors. Bring the case to the attention of your General Manager so that Finance can loosen its purse strings for you once again this time around.
ReplyDeleteDoing development inside VMs is the way to go... All my IDEs are set up in separated VMs, even without installation of office or antivirus (except the builtin Windows Defender).
ReplyDeleteOh boy. Half of our development is on Seattle. Please do keep us updated if you can find some fixes. Thank you for all that you do for the Delphi community.
ReplyDeleteUnless you are developing using APIs not supported in a virtual machine (ie: RAW Input API), VMs are definitely the way to go these days! You can more easily backup your environment, and experiment with different versions of your software and Windows with minimal effort.
ReplyDeleteI am using both Windows 10 and Windows 7 in VirtualBox VMs on Linux Ubuntu. Been working well for me since I switched to Linux about 1.5 years ago. While not an OS for the average user yet, I am pleased with Linux thus far as Windows 10 Updates were driving me nuts! Win7 IMHO is one of the best versions ever.
I have completely switched to Lazarus for 4 years. The points of contact between Lazarus and the Win32 api are minimal here. My programs run perfectly on all versions of Windows.
ReplyDeleteI made the switch to Linux and Lazarus last year. I still do a VM for some projects with Delphi, but it's all in Linux now.
ReplyDeleteMove your delphi to a VM based on Win 7. Been working like that for the past 10 years. Best move I made with no regrets. I'm definately not going to move to a Win 10 VM for a long time. Will just use Win 10 VM for testing the apps before they go into production.
ReplyDeleteBTW ... I'm using VMWare Workstation/Player (currently using v15.1) for this. Excellent tool. Snapshot feature is also helpful to rollback VM environment to a previous state, especially when you are trying out a new thirdy party component update etc
DeletePublished a small update.
ReplyDelete