Pc Faster Windows 7
Arleen Jerdee
That reminded me of something. When I was young, if I remember correctly, Windows 95 (if not 98) had this weird behavior that when installing programs, wiggling the mouse cursor make the progress faster. What caused this? I searched for it, I couldn't find anything related.
Windows 95 applications often use asynchronous I/O, that is they ask for some file operation like a copy to be performed and then tell the OS that they can be put to sleep until that operation finishes. By sleeping they allow other applications to run, rather than wasting CPU time endlessly asking if the file operation has completed yet.
For reasons that are not entirely clear, but probably due to performance problems on low end machines, Windows 95 tends to bundle up the messages about I/O completion and doesn't immediately wake up the application to service them. However, it does wake the application for user input, presumably to keep it feeling responsive, and when the application is awake it will handle any pending I/O messages too.
Thus wiggling the mouse causes the application to process I/O messages faster, and install quicker. The effect was quite pronounced; large applications that could take an hour to install could be reduced to 15 minutes with suitable mouse input.
Try opening a large file with Notepad on a contemporary machine. The window must not be full screen. When loaded, mark all text using the mouse (the keyboard works as well, it just needs more manual skill). While still holding the button down (and marking) move the mouse down, so the text gets marked and scrolled. Now compare the scroll speed while holding the mouse still versus wiggling it. Depending on your machine the speed up can be several times faster.
It can be viewed in many other programs as well, Notepad is just an easy to reproduce example. It's related to the way multitasking worked in early versions of Windows. Here everything revolved around the message queue. Wiggling the mouse resulted in a flood of mouse-move messages, which in turn made programs wake up more often and (depending on their structure) updating their states each time, going into the message loop again, giving time to screen updates, resulting in an over all faster reaction. It shows a glimpse of the ways MS used to make Windows rather responsive despite its cooperative threaded nature.
What really happens is that, on both OS, you need to process the message loop, but if you want to update something in the background, like a task, a display update, etc, you'd set a timer and the timer would put a message in the queue at a regular interval.
Since the main mechanism was to rely only on the message loop and background operations were done through timer messages, moving the mouse would trigger a lot of messages, move the app up in priority, wake the app up, and get the app to process the background tasks messages. Without moving the mouse, the timer messages would be read up only at a rather slow interval.
The reason is because of how WM_TIMER is limited to 15.6ms intervals by default. If you call SetTimer() with a 1ms interval it will still be called in 15.6ms intervals. WM_TIMER drives a lot of stuff in Win32 applications like network packet processing and such.
The 15.6ms value was set for various reasons: Not clogging up the event queue so that stuff like WM_PAINT would still dispatch often enough and more recently and importantly to save power. There are tons of articles talking about this:
One danger of the MsgWaitForMultipleObjects function is calling it when there are already messages waiting to be processed, because MsgWaitForMultipleObjects returns only when there is a new event in the queue.
Arguably, this is a common bug in early software based on an event-processing loop rather than a Windows bug: if some DD-paths of the loop only process a single event, then every time when two events are generated simultaneously, only one is processed and the other gets stuck. Moving the mouse generates more incoming events and restarts the loop. "Mouse move" events are typically processed by a GUI library, which handles them correctly (that is, processing all such events in the queue), so those events help get the loop going, and then disappear harmlessly.
Quick answer, by moving the cursor you were telling windows that you are the most important event running. When you stop interacting windows gives priority to other events. So installing programs even when in foreground would give priority to less important events. This bug is no longer present in current Windows versions.
On Windows 95, the keyboard and mouse generated interrupts, moving the mouse caused the interrupt to fire and the OS to service it's event queue. A form of preemptive multitasking, instead of a fixed timer interrupt, you were doing it.
EDIT - 1/2 right ...Cannot pre-emptively multitask Win16 applications because it uses the same System Virtual Machine (VM) model as in Windows 3.1 to run Win16 applications. Thus, Windows 95 will revert to a cooperative multitasking environment when running Win16 applications and give them exclusive control of the CPU for as long as the applications are executing. As a result, true pre-emptive operation is impossible when multitasking a mixture of Win16 and Win32 applications.
I want to delete a folder that contains thousands of files and folders. If I use Windows Explorer to delete the folder it can take 10-15 minutes (not always, but often). Is there a faster way in Windows to delete folders?
The worst way is to send to Recycle Bin: you still need to delete them. Next worst is shift+delete with Windows Explorer: it wastes loads of time checking the contents before starting deleting anything.
The best I've found is a two line batch file with a first pass to delete files and outputs to nul to avoid the overhead of writing to screen for every singe file. A second pass then cleans up the remaining directory structure:
This is a regular task for me, so I usually move the stuff I need to delete to C:\stufftodelete and have those del+rmdir commands in a deletestuff.bat batch file. This is scheduled to run at night, but sometimes I need to run it during the day so the quicker the better.
use the command prompt, as suggested. I figured out why explorer is so slow a while ago, it gives you an estimate of how long it will take to delete the files/folders. To do this, it has to scan the number of items and the size. This takes ages, hence the ridiculous wait with large folders.
Is Ubuntu faster than Windows is a broad topic that depends on many topics including your computer's hardware. Try running the Ubuntu live USB (which can also be used to install Ubuntu) from a live session without installing it to your computer's hard drive. Then you can compare Ubuntu's performance with Windows 10's performance overall and on a per application basis.
Ubuntu runs faster than Windows on every computer that I have ever tested. LibreOffice (Ubuntu's default office suite) runs much faster than Microsoft Office on every computer that I have ever tested. Many Windows games can also being installed on Ubuntu using Wine, and they usually run faster (and better) in Windows than they do in Wine.
There are several different flavors of Ubuntu ranging from vanilla Ubuntu to the faster lightweight flavors like Lubuntu and Xubuntu, which allows the user to select the Ubuntu flavor that is most compatible with the computer's hardware.
First of all, I would like to clarify some things to you to help you make up you mind on which OS to pick. Nowadays, you'll need to take into account the fact that there are several Linux distributions (distros) for different purposes.
If you have a SSD you may will not get a shorter booting time (Ubuntu vs. Win10) out of the box. Also the battery time (if using notebook) will decrease with Ubuntu / Linux compared to Win10 (for standard installation).
With Ubuntu / Linux the update cycles will be shorter and you do not waste hours of waiting to install updates from Microsoft, but for some hardware it can be difficult to get drivers or sometimes just strange screen flickering, etc. can happen. There you must be able to dig the internet / forum to find a possible solution.
I am using both Win10 and Ubuntu 18.04 LTS (and derivates like elementary OS) and happy with it. Daily usage normally Ubuntu, but if I need special software then I use Win10 (not every software is existing for Linux and Wine is a lot of time not perfect to run Windows-Software on Linux).
Overall I like and use Ubuntu a lot, espacially for my older laptops (just update HDD to SDD). Therefore it is realy great. I can use my old laptop from 2006 with 2 GB RAM and old CPU in a way, which would never be possible with Windows anymore.
The simple answer to why is "it's easy, user friendly and is the hub for one of the biggest if not biggest collection of intercompatible libraries of all the linux distributions, which in layman's terms means : despite these two first positive points they don't act as a deterrent to more positive points, such as also having the full potential of linux"
So I'd personally recomend ubuntu, perhaps I'm biased but I really find there quite little that compares in terms of easing in a new user who might be entering a realm he feels foreign to. (Zorin comes to mind but they have less library intercompatibility and quite a few bugs, the UI is clearly better for someone who uses windows though, I recomend it also but not as strongly as I do ubuntu)
The major benefit here will not be speed but relative performance for the cost.Open source projects are usually designed and tested on *nix (linux/unix/bsd) first, and then 'ported' to Windows. Features usually creep into windows 2nd, not first.
If you have a 6 core Linux server it doesn't cost any money to use all 6 cores, and with the money you save on licensing you can buy more memory, or faster disks - this will be the biggest performance increase, not one OS vs Another.
There is also the case to make about Operating System features, although many programs don't yet take advantage of them...In the case of epoll vs select() or poll() - windows does not have an equivelant, nor does it have sendfile, or a threads implementation similar to pthreads in 2.6+ Kernels.
ff7609af8f