
- #Error updating vmware tools for windows 2000 or later how to
- #Error updating vmware tools for windows 2000 or later install
- #Error updating vmware tools for windows 2000 or later upgrade
- #Error updating vmware tools for windows 2000 or later iso
In the case of a small app of my own, XE produced a 3MB executable, while 10.2 was over 70MB. Even without generics, the difference in an application built in Delphi XE and Delphi 10.2 is huge. Unfortunately, the prevailing assumption in the development world is that a) memory is cheap, and b) it is measured in GB. You appear to assume that this environment will continue to be viable as new versions of Delphi roll out.
#Error updating vmware tools for windows 2000 or later upgrade
Considering built-in devices (robotic arms, controllers, etc.) where you can not upgrade the hardware and/or the software, I like to experiment with the absolute minimum.Īt the moment my 1 GB Win2K is actively using ~104 MB, while the 128 MB Win2k is using only 11 MB of RAM:
#Error updating vmware tools for windows 2000 or later how to
P.s.: I don't want anyone to find the issue for me I'm looking for directions on how to find these by myself. In the mean time, I set up a basic VM with 128 MB of RAM and no vmWare tools. The average alive time of a work queue item is a couple of seconds, and as I'm using TObjectList.Create(True) as the queue, I can be sure that work items are disposed upon removal.įurthermore, as I mentioned the problem only appears on a Windows 2000 machine with (currently) 1 GB of memory (previous solution ran fine on 64 MB) a Windows 2003 R2 with 128 MB and a 2008 with 512 MB is running the tool fine for weeks now (since the latest patch). End FastMM and MadExcept both says there are no leaks at all. I not just went back to ensure all blocks are surrounded by a Try. It's one thing returning memory when the program closes, another returning it in a timely fashion during execution. Just because fastmm4 says you don't doesn't mean you don't. It's very plausible that you have a memory leak. I will attempt to create a new Windows 2000 machine without vmWare tools to see if it makes any difference, however I believe that TList will be the root cause here which got reinforced after seeingĭid anyone met this symptom before? How can I be sure the root cause is my application and not the prehistoric OS? Maybe the combination of both? Is there a (even a hacky) way to force a Delphi application to release any currently not used memory? Only a Windows 2000 system is affected, Windows 2003 and above accepted the change well The obvious, Array to TList and String to Class conversion The ESX host the test VM is running on was patched a couple of times (and because of that vmWare tools got updated on the guests) Unfortunately there are a lot of factors to consider here: Everything works like a charm, there are no memory leaks reported whatsoever even after a stress-test of the work item part.Īfter about a week of uptime my Windows 2000 test system reaches 0% of free memory and becomes unstable, requiring a reboot. Now, the work queue is a TObjectList, and work queue items are classes, created upon adding, freed after successful processing. Each thread has a work queue, which used to be a Array Of String, storing the properties separated with tabs. You must perform a custom installation and include that component.After switching from D7 to D10.2 I re-wrote one of my multithreaded apps with proper OOP, using the "new" language features.

For operating systems later than these, you must log in as an administrator.

#Error updating vmware tools for windows 2000 or later install
Any user can install VMware Tools in a Windows 95, Windows 98, or Windows ME guest operating system.

#Error updating vmware tools for windows 2000 or later iso
This ISO file is detected as a physical CD by your guest operating system. The autodetect setting enables the virtual machine's first virtual CD/DVD drive to detect and connect to the VMware Tools ISO file for a VMware Tools installation.
