While several windows for one application is perfectly possible in Windows (see GIMP implementation), it is not commonly used. One of the reason may be related to technical background.

Windows first decent release was windows 3.0. As its Win32 API was rather complex, Microsoft has pushed its MFC library since the beginning (1992), to make application development easier. This did promote a document-based interface that came in two flavors: SDI (single docucment interface) and MDI (multiple document interface). As Microsoft shipped its own applications using this kind of interface, many developers liked it to take the same approach.

Then comes the cultural aspect. User got accustomed to the logic 1 app = 1 window. Related items were visually grouped into the same windows (with the exception of the modal dialog boxes). On smaller screens which were usual on earlier PCs, switching tasks consisted of reducing one app (in one click) and maximizing the other (again with one click). New applications using a different approach had to cope with user's resistance as they were perceived less native. Thus developer tend to adopt to the expectations of their user base. And so on...

On unix/linux, in the 80's, people using a GUI were usually working on workstations with much bigger screens and higher resolution. So there was not the same problem of "screen estate". Windowing was based on X11, and there was no library that encouraged using the pardigm 1 app = 1 windows. Later Motif developped to be the standard widget toolkit, and offered no facility to implement MDI interfaces. So the broad user base was accustomed to several windows for one app (1 window = 1 document or 1 task). New users learned it that way and found it natural, so that the expectations are not the same than on a windows base.

Background

While several windows for one application is perfectly possible in Windows (see GIMP implementation), it is not commonly used. One of the reason may be related to technical background.

Windows first decent release was windows 3.0. As its Win32 API was rather complex, Microsoft has pushed its MFC library since the beginning (1992), to make application development easier. This did promote a document-based interface that came in two flavors: SDI (single docucment interface) and MDI (multiple document interface). As Microsoft shipped its own applications using this kind of interface, many developers liked it to take the same approach.

Then comes the cultural aspect. User got accustomed to the logic 1 app = 1 window. Related items were visually grouped into the same windows (with the exception of the modal dialog boxes). On smaller screens which were usual on earlier PCs, switching tasks consisted of reducing one app (in one click) and maximizing the other (again with one click). New applications using a different approach had to cope with user's resistance as they were perceived less native. Thus developer tend to adopt to the expectations of their user base. And so on...

On unix/linux, in the 80's, people using a GUI were usually working on workstations with much bigger screens and higher resolution. So there was not the same problem of "screen estate". Windowing was based on X11, and there was no library that encouraged using the pardigm 1 app = 1 windows. Later Motif developped to be the standard widget toolkit, and offered no facility to implement MDI interfaces. So the broad user base was accustomed to several windows for one app (1 window = 1 document or 1 task). New users learned it that way and found it natural, so that the expectations are not the same than on a windows base.

Addvantages/inconvenience

Let's be honest: the comparison will always be subjective. It's rather a question of philosophy:

• Keeping everything in one windows is an application centric approach.

• Having multiple windows on the screen is a document/task centric approach.

• Popular browsers which are used by a large user base accross OS, tend to shift to a tabbed approach with one window. But they also provide shortcuts to create additional windows (can be configured)

• Occasional users tend to be lost with too many windows.

• The broad user base wants an application which fits with the look & feel they are used to.

So if possible, I'd suggest to support both approaches and let the user choose in a configuration dialog (it seems also to be the approach of latest GIMP version )

It is difficult to come with objective arguments.

While several windows for one application is perfectly possible in Windows (see GIMP implementation), it is not commonly used. One of the reason may be related to technical background.

As Win32 API is rather complex, Microsoft has pushed its MFC library since the beginning, to make application development easier. This did promote a document-based interface that came in two flavors: SDI (single docucment interface) and MDI (multiple document interface). As Microsoft shipped its own applications using this kind of interface, many developers liked it to take the same approach.

Then comes the cultural aspect. User got accustomed to the logic 1 app = 1 window. Related items were visually grouped into the same windows (with the exception of the modal dialog boxes). On smaller screens, switching tasks consisted of reducing one app (in one click) and maximizing the other (again with one click). New applications using a different approach were then perceived less native and got less success, thus encouraging developer to adopt this mainstream approach. And so on...

On unix/linux, people using a GUI were usually working on workstations with much bigger screens and higher resolution. So there was not the same problem of "screen estate". And there was no library that encouraged using one windows only. SO the broad user base was accustomed to several windows for one app. New users learn it that way and found it natural, so that the expectations are not the same than on a windows base.

While several windows for one application is perfectly possible in Windows (see GIMP implementation), it is not commonly used. One of the reason may be related to technical background.

Windows first decent release was windows 3.0. As its Win32 API was rather complex, Microsoft has pushed its MFC library since the beginning (1992), to make application development easier. This did promote a document-based interface that came in two flavors: SDI (single docucment interface) and MDI (multiple document interface). As Microsoft shipped its own applications using this kind of interface, many developers liked it to take the same approach.

Then comes the cultural aspect. User got accustomed to the logic 1 app = 1 window. Related items were visually grouped into the same windows (with the exception of the modal dialog boxes). On smaller screens which were usual on earlier PCs, switching tasks consisted of reducing one app (in one click) and maximizing the other (again with one click). New applications using a different approach had to cope with user's resistance as they were perceived less native. Thus developer tend to adopt to the expectations of their user base. And so on...

On unix/linux, in the 80's, people using a GUI were usually working on workstations with much bigger screens and higher resolution. So there was not the same problem of "screen estate". Windowing was based on X11, and there was no library that encouraged using the pardigm 1 app = 1 windows. Later Motif developped to be the standard widget toolkit, and offered no facility to implement MDI interfaces. So the broad user base was accustomed to several windows for one app (1 window = 1 document or 1 task). New users learned it that way and found it natural, so that the expectations are not the same than on a windows base.