This question isn't appropriate for Stack Overflow, but I really like answering people's questions, so I will anyway, even though the answer will be necessarily incomplete.
What Visual Basic was doing was providing you with a special environment in which things appeared to be running simultaneously. All those timers were just entries in a data structure that told Visual Basic when it had to go act like that timer had just expired. It used the current time to decide when it should run them.
In general, Visual Basic is what controlled the flow of your program. In between all the statements you wrote, the Visual Basic runtime was doing all kinds of things behind the scenes for you. Things like checking up on the data structures it was keeping of which timer to fire when and so on.
There are two main ways of controlling the flow of your program in such a way as to make it seem like several things are happening at the same time. What Visual Basic was doing is called an 'event loop'. That's a main loop in your program that keeps track of all the things that need doing and goes and runs the code that does them at the right times. When someone clicks on a window, your program gets an event, the event loop sees that event and runs the 'clicked on a window' code when it gets control. It sort of seems like your program just responds instantly to the click, but that's not what's really happening.
The other way is called 'multi-threading'. In that way your program may really do several things at the same time. The operating system itself decides how to allocate CPU resources to running 'threads'. If there is a lot of competition for CPU resources, the operating system may start running one program (or thread) for a little while (a thousandth of a second or so) and then switch to running a different program (aka process (threads and processes are strongly related, but definitely distinct concepts)). The switching happens so fast, and can happen at any instant, so it seems like several things are happening at once. But, if there are enough CPU resources available (multiple cores) the computer can actually just run several things at the same time.
There are advantages and disadvantages to each approach. Actually dealing with two things modifying the same data at the exact same time and making sure everything stays consistent can be very hard, and is usually accomplished by having sections of your program in only one thread is allowed to be running at a time so that those modifications can't actually happen in the same instant and they are 'serialized' so that one thread's modification happens before another. These are usually called 'critical sections' and access to these critical sections is typically controlled by something called a 'mutex' (aka mutual exclusion) lock.
Event driven code doesn't have that problem since typically one event must be fully processed before the code to process the next event can start. But this can lead to under-utilization of CPU resources, and it can also sometimes introduce noticeable delays in handling events as one event can't be processed until the code to process the preceding event is finished.
In short, Visual Basic was making event driven programming really easy and clean to use, and providing you with the illusion that several things were running at the same time.
These, in general, are fairly deep computer science topics, and people get their PhDs studying some of this stuff. But a working understanding of exactly how event driven code and how multi-threading code works isn't that hard.
There are also other models of concurrency out there, and hybrid models like 'co-routines' that look like threads but are really events.
I put all the most useful concept handles in quotes to emphasize them.
