Windows Xp Obsolete
Leroy Turcios
Looks like that Obsolete Software Key 'ChangeTracker' notification is probably going to be one of those ongoing registry detections in CCleaner like the 'ToastNotifier' one which has now been there for months & months.
I'm having the same problem, and as for the idea that I shouldn't clean my registry because Microsoft changes the registry a lot, I'd prefer NOT to have Microsoft or anyone else messing with my computer unless I specifically want them to, and I don't see why I should let my registry pile up a bunch of garbage entries, slowing down my computer, just because some intrusive mega-corporation wants to control it. And when my computer is running slower than usual, that IS something that's already broken.
Dude, you're the one telling us not to use CCleaner to remove files CCleaner thinks are unnecessary, but which you're assuring us are actually necessary. So - by your own admission, this IS a CCleaner problem. If the file is necessary, then maybe the CCleaner software should be amended so it knows not to delete that registry entry.
When MS add new registry entries that the current CCleaner reg cleaner doesn't recognise then it takes time for CCleaner to be changed to ignore them - if it is decided to ignore them.
The developers may decide that clearing the new entry is required anyway, even though Windows will create it again.
Have a read of the link in my signature;
There's an explanation of why CCleaner will remove certain files even though it's known that Windows will put new ones straight back to replace them.
That isn't an error, CCleaner does it deliberately to 'refresh' the files.
(Whilst not quite the same thing for a registry entry as a file, doing that can still be relevant to reset some entries that may have been modified).
I 100% agree with Ian Cooper and his April 10 comment. If this is a CCleaner issue - then CCleaner needs to fix it. As a licensed and paid user of these tools, Moderators, like nukecad, need to understand the customer's perspective and use their Moderator position to drive the company we pay to be better and not slide down the slope of "it is ok" - recognize a problem and drive a fix. This goes back to April - 6 months later the registry item is still showing as an issue. Drive the solution versus perpetuating the problem. I don't need to read an excuse, the software needs to work after 1/2 a year.
...When MS add new registry entries that the current CCleaner reg cleaner doesn't recognise then it takes time for CCleaner to be changed to ignore them - if it is decided to ignore them.
The developers may decide that clearing the new entry is required anyway, even though Windows will create it again.
...There's an explanation of why CCleaner will remove certain files even though it's known that Windows will put new ones straight back to replace them.
That isn't an error, CCleaner does it deliberately to 'refresh' the files.
I get that sometimes it takes time to update the program, but so what? It's been months, and you're still saying "may decide". If the program thinks the files should be deleted, then when people complain, simply tell them that this is the case, instead of waffling on about it being a Windows problem and telling them not to use ccleaner's registry cleaner (let's not forget, you said " it's unwise to use a Registry Cleaner unless you are trying to fix a specific problem." - I view any junk in my registry to be "a specific problem" because ccleaner TELLS ME IT IS!). The fact that you haven't given us any definitive answer on this issue, and you're still using words like "may" indicates that this issue STILL hasn't been addressed either way, and you're just making excuses.
Whilst we might get a few extra insights into what is happening at the company we can only know what we are told by the company.
We have no influence over what the company is doing, other than complaining if we think what they are doing is wrong (and believe me, we do).
Just like you are complaining here.
Of course we could keep silent, just delete all the posted daily spam content so that you don't see it, and not share any of what little extra we do find out if/when it is relevent to a topic
But that wouldn't be of help to anyone.
Hello All & especially Mart89, Nice to meet you. Sorry my reply is a year late I suffer from ADHD which also explains why i only just upgraded to W11 after being MacAFied , not verified but thought MacOSX was better than windows..Regret that decision now i need computing on the cheap mate. Another ADHD trait ...I talk too much ...So to cut a long story short dear friend , obsolete is exact in that its used for core Microsoft code and you will never get rid of it , its probably a windows logging option enabled for developers. Empty is good as no sub folders or relevant value hence obsolete.
Talking of ADHD I completley understand your question, its almost genius ..Like you I like to see a clean registry and that each entry is not going to slow me down in the future ...So I exclude a lot of things of no value hence the lovely photo below that you configure / customize this wonderful software. Hope this helps buddy , All the best NOVA
I already found out with another question that Windows/MingW doesn't provide the nanosleep() and setitimer() alternatives to the obsolete usleep().But my goal is to fix all warnings that cppcheck gives me, including the usleep() style warnings.
Note that SetWaitableTimer() uses "100 nanosecond intervals ... Positive values indicate absolute time. ... Negative values indicate relative time." and that "The actual timer accuracy depends on the capability of your hardware."
The millisecond regime of the Sleep() function is well described and well understood. It does not do anything unpredictable. Sometimes the function is blamed to perform unpredictable, i.e. returning before the delay has expired. I need to say that this is wrong. Careful investigation will confirm that its behaviour is absolutely predictable. The only problem isthat there is plenty to read about it and most of it is kiddish. It is also often said thatwindows it not a real-time OS. But such comments don't contribute anything, moreover such comments are used to hide the lack of knowledge. It makes me sort of angry, that not evenmicrosoft notices this and provides better documentation.
However, without exaggerating this little answer: The sleep() function is precise, when used in a proper way and when knowing its characteristics. Particular attention has to be given to sleep(0). This is a very powerfull tool, particulary when used together with process priority class, thread priority, multimedia timer settings, and processor affinity mask.
So generally a true sleep can be performed easely and safe down to the systems interrupt period. When it comes to sleeps shorter than the interrupt period spinning is required.A higher resolution time source has to be used in oder to spin for shorter periods in time.The most common source for this is the performance counter. QueryPerformanceCounter(*arg) delivers an incrementing *arg. QueryPerformanceFrequency(*arg) delivers the frequency at which the performance counter increments. This is typically in the MHz regime and varies, depending on the underlying hardware. A frequency in the MHz range provides microsecond resolution. This way something of high resolution can be used to wait for a desired time span to expire. However, the accuracy of this has to be looked at carefully: The OS returns the performance counter frequency as a constant. This is wrong! Since the frequency is generated be a physical device, there is always an offset and it also not a constant. It has thermal drift. More modern systems do have less drift. But if the thermal drift is just 1ppm, the error will be 1us/s. The offset can easely be several 100. An offset of 100 in 1MHz corresponds to 100us/s.
If a thread shall wait for any time at high resolution, it shall establish a service thread. Both thread shall share a named event. The service thread shall sleep until 1 interrupt period ahead of the desired sleep delay and then spin on the performance counter for the remaining microsecond. When the service thread reaches the final time, it set the named event and ends. The calling thread will wake up, because it was waiting for the named event by means of a wait function.
It depends what granularity you need. If you are talking milliseconds, then the Win32 Sleep function will do the job - see -us/library/ms686298%28v=vs.85%29.aspx. If you are talking microseconds, then there is no easy way to do it, and you would be lucky to get that sort of timer resolution on Windows (which is not an RTOS), or on Linux, come to that.
I'm quite late to the party but I want just to add something to this question. If you want to achieve portability using microseconds resolution than use select() system call using empty file descriptor set. It will work both on linux and on windows, i.e. it can be called using an uniform interface (the behavior can be still different especially on Windows where you can ask for 1 microsecond but you get 1ms sleep). If you want to use a third-party library use Boost, but a recent version. The time related std api are just a mess and I provide a summary here:
Microsoft has made everyone mad. Well, almost everyone. Its stiff set of system requirements for Windows 11 has led to many articles wailing that Microsoft is about to make millions upon millions of PCs obsolete.
Take a deep breath, people. Your PC or laptop is not about to be instantly consigned to the scrapheap, even if Microsoft insisted that every PC must have a nuclear reactor and be made of solid gold to run Windows 11.
Re: (Obsolete) WAV format issue.
Microsoft change the RIFF Wave specification to add the WAVE_FORMAT_EXTENSIBLE format tag. All PCM formats with greater than 16 bit quality are now covered by that tag. Any files using the old WAVE_FORMAT_PCM format tag for high quality are considered obsolete.