I have no idea what type of solution you're looking for, but if you want a chat server which allows "simultaneous" access for all users, possibly the best thing to research is a socket-based HTTP server application with a web interface.
To achieve the "simultaneous" feeling this server should use one thread or process for each request it handles. When a program creates a new thread or process, it can go on receiving more requests while the thread is busy reading the request (such as a new message sent to the chat room) and generating a response (such as a command to display this message on everyone's screen).
The server would probably maintain a list of users and a list of chat rooms and each chat room has a list of subscribers. As messages are received to a chat room, the commands to display those messages are relayed to everyone connected to the chat room. The commands sent back and forth between the server and the browser will include commands to say "so-and-so joined," "so-and-so said: message," etc.
The actual format of the commands would probably be a Javascript command which causes the information to be displayed on the screen. When I created my chat server and front-end, browsers maintained a persistent connection with the server (called COMET) which would allow the server to send commands to the users at any time without a delay. For browser that do not support the persistent connection, a polling system was used where every half second or so the browser would ask the server if any new commands had come in.
For a lower quality project, it would probably be acceptable to maintain a queue of commands to be sent to each user and then force the chat page to refresh every couple seconds. That's much less desirable but much easier.
If you actually want to go into implementing the chat room in a browser it can get hairy due to browser security, but I won't go into that unless you are interested.
You do not have to use any particular language to achieve this, it can be done in C++ as well as Java, Perl, and many other languages. I prefer Java for anything threaded because its thread handling is more convenient than some other languages (although right now I am writing a threaded socket-based server in Perl because I don't really like Java all that much).
This can also be done with an existing server like Apache. It would be easier to do the "polling" method described above with Apache but your application would be a lot more intensive. For example, instead of just storing commands in the program's memory you would need to save and reload from a database every time someone polled the server.
Depending on your application, if it isn't exactly a chat program, just think "Could this be a web site?" and if the answer is yes then the easiest route may be to wrap your mind around how to make it into a web site and just run it on Apache. Apache will do all of the "simultaneous" stuff for you, the application then could be a CGI language like PHP, Perl or really any other language with a bit more effort.
Sorry if this is all too technical!
---- UPDATE ----
Okay now I see what you mean. It would be very difficult to reinvent the wheel here inside a web browser. I actually thought of a very similar thing for a tech support type of application - so customers could easily show the agent the problem. It gets really complicated though, you would need to be very very familiar with web programming to pull that off. There's a huge can of worms around browser security and actually capturing events over someone else's web site and if you downloaded and served the HTML from their site from your server then their Javascript may not work because the domain would be whatever you use for your app. The attraction is not having to download a program and open a port on your firewall and router, but I think it's a monumental task.
If it's not essential that you make it in a browser (or make it at all), you could research the technology behind Remote Desktop, RealVNC, GoToMyPC, or any other remote computing app. Doing this inside a browser would actually be more complicated than making a general desktop program like those due to all the browser restrictions and compatibility issues.