Is the time slice (quantum) that the Windows Kernel Dispatcher allocates to threads the same length for every thread, or does it base the size of quantum on the priority of the thread like Linux does?
Since the days of Windows NT, higher priorities applications have a larger quantum, for example for foreground threads.
32 priority levels are defined, 0 through to 31, with priorities 0 through 15 being "normal" priorities and priorities 16 through 31 being soft real-time priorities, requiring privileges to assign. 0 is reserved for the Operating System. Users can select 5 of these priorities to assign to a running application from the Task Manager application, or through thread management APIs. The kernel may change the priority level of a thread depending on its I/O and CPU usage and whether it is interactive (i.e. accepts and responds to input from humans), raising the priority of interactive and I/O bounded processes and lowering that of CPU bound processes, to increase the responsiveness of interactive applications
In Vista, the scheduler makes use of cycle counter registers in modern processors, and is able to estimate how many cycles a thread uses per clock tick. This way, the scheduler can divvy up CPU time much more fairly. A thread is allowed to run for another time slice after being interrupted, while before Vista the scheduler assumed that an interrupted thread ran for its entire time slice. (This indirectly increases the priority of a much-interrupted thread.) Vista also uses a priority scheduler for the I/O queue so that disk defragmenters and other such programs don't interfere with foreground operations.