It can if you initially wrote your code to use WinHTTP

Posted Jan 9, 2009 20:29 UTC (Fri) by khim (subscriber, #9252)
In reply to: Chrome 2.0 Preview Means Mac, Linux Versions Coming Soon (Wired blog) by pr1268
Parent article: Chrome 2.0 Preview Means Mac, Linux Versions Coming Soon (Wired blog)

The problem is: Netscape, Mozilla/Firefox, and Opera don't WinHTTP even on Windows. And if by some reason (compatibility, whatever) you absolutely want to use WinHTTP on Windows you are stuck. You need to either
1. Implement WinHTTP API (or some very similar API) for Linux and Mac, or
2. Implement abstraction layer to reuse WinHTTP on Windows and some other library on Linux/Mac

Apparently Google decided to go with choice #1...

to post comments

It can if you initially wrote your code to use WinHTTP

Posted Jan 10, 2009 0:10 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link] (15 responses)

Apparently Google decided to go with choice #1...

You forgot option 3: make your app Windows only. That's what Google chose to do with Chrome 1.0. Now they've decided that none of those options is good enough, so they're following the other multi-platform browsers and rolling their own.

It can if you initially wrote your code to use WinHTTP

Posted Jan 10, 2009 0:20 UTC (Sat) by cpeterso (guest, #305) [Link] (14 responses)

I was surprised by how much Windows-only code is in Chrome. You would think Google would at least organize their code to ease porting to Mac and Linux in the future, even if they didn't develop for those platforms for Chrome 1.0.

It can if you initially wrote your code to use WinHTTP

Posted Jan 10, 2009 2:12 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (13 responses)

In my experience it matters greatly who writes the quite early code for a project. The Windows development environment* in particular really encourages people to write code that's completely non-portable. So one "Windows" guy writing the core of a project can build into it a great many non-portable assumptions, without a hint of malice on their part. It's just natural to them to assume that strings are UTF-16, and a long is 32-bit, and you should write certain things with a leading underscore or in all capitals when that only actually works if you have Windows header files...

Lots of crazy decisions happen when there's only one or two people working on a project, perhaps before it formally exists at all. And it's tough to come onto someone else's project and start ripping out reliance on perfectly good APIs whose only fault is that they don't exist outside Windows. It can give people who do spend all or most of their development effort on Windows the impression that you're just jealous - that Windows has these features, and other platforms don't (when in reality often they do, but with a different API) and so really you ought to just give up on those also-ran platforms instead of insisting on portability.

* Everything from Visual Studio tools, through magazine articles, live training courses, KB articles, almost all of it is written with the unspoken assumption that portability outside Windows is irrelevant.

It can if you initially wrote your code to use WinHTTP

Posted Jan 10, 2009 14:24 UTC (Sat) by rvfh (guest, #31018) [Link] (12 responses)

Wow! You just put in words what I've been feeling for months, working with Windows-brain-washed people and porting their code to 'Linux' (really, just to standard C/C++).

And they were genuinely convinced that Windows has it and others don't. There was indeed no malice, and they were also extremely clever people.

I need to keep that comment for future use, and it did help me find some arguments for my future Windows vs Linux debates, which one of my colleagues likes to spawn...

Thanks a lot.

Actually Chrome (and MS IE 8) are showing lack of features in Windows, not in Linux

Posted Jan 10, 2009 23:24 UTC (Sat) by khim (subscriber, #9252) [Link] (11 responses)

And they were genuinely convinced that Windows has it and others don't.

But there are things *nix does have and Windows does not. And Chrome/MSIE8 show this beautifully. They both incorporate "one process per tab" approach to security. And they both struggle mightily with lack of fork(2) (with COW) in Windows! For example they can not initialize V8 engine once - it's done every time you are opening new URL! Google (and I have no doubt Microsoft too) spent a lot of resources doing this totaly unneeded work - and I sure hope Chrome for Linux will have huge difference in this place. It's so much easier to implement Chrome/MSIE8 security model under *nix it's not even funny! The irony of course is that browser with architecture practically designed for *nix and quite unsuitable for Windows was released for Windows first. It shows how technical choices take a back-seet when marketing pressure is exerted.

Actually Chrome (and MS IE 8) are showing lack of features in Windows, not in Linux

Posted Jan 11, 2009 8:43 UTC (Sun) by jamesh (guest, #1159) [Link]

Note that "just using fork()" is not as simple as it might first seem.

As an example, if the parent and child processes both want to use Xlib (not unreasonable for a web browser), then the parent should not initialise Xlib until after forking. If the parent does it beforehand, then both processes will be sharing a single X connection and you get unpredictable behaviour.

Depending on the architecture, it may be that fork+exec is the best option for Linux, in which case the work they've put into supporting the equivalent on Windows has not been wasted.

Actually Chrome (and MS IE 8) are showing lack of features in Windows, not in Linux

Posted Jan 12, 2009 10:55 UTC (Mon) by ibukanov (subscriber, #3942) [Link] (7 responses)

> For example they can not initialize V8 engine once

The benefits of fork(2) to speedup initialization are overrated. One can archive the same with dumping initialized image to a file and then using mmap with MAP_PRIVATE to map the image to the same fixed address. This is available on Windows and also benefits the very first process that use the image.

You can achieve the same speed, but certainly not the same simplicity

Posted Jan 12, 2009 11:39 UTC (Mon) by khim (subscriber, #9252) [Link] (6 responses)

If you'll take a look on Chrome you'll find that they are doing something similar. And it works. More or less. But this replaces SIMPLE AND EFFICIENT system with A LOT OF code and infrastructure! And that's the point.

Another Windows shortcoming (not relevant to Chrome) is inability to remove opened file. This problem was overcome with A LOT OF subsystems: Windows itself has one (there functions to "replace system files on the next reboot"), .NET have another, Google Chrome have yet another version, etc. And again: it works but it required many manyears to implement!

You can achieve the same speed, but certainly not the same simplicity

Posted Jan 12, 2009 13:00 UTC (Mon) by ibukanov (subscriber, #3942) [Link] (5 responses)

> But this replaces SIMPLE AND EFFICIENT system

While I agree with the simplicity part of fork-based solution, they are less efficient than mmap-based initialization. With fork one need to keep an extra process around to clone children. That takes resources including extra memory that is not relevant to the initialization image.

Cost in neglible

Posted Jan 12, 2009 13:12 UTC (Mon) by khim (subscriber, #9252) [Link] (4 responses)

You need 12K or so (8K in kernelspace, 4K in userspace) - not a big deal even for phones, let alone desktops...

Cost in neglible

Posted Jan 12, 2009 17:37 UTC (Mon) by ibukanov (subscriber, #3942) [Link] (3 responses)

> You need 12K or so

With the fork it is hard to control all the memory in the to-be-forked process that is used by shared libraries upon initialization. This memory will be most likely changed in the child process (otherwise there would be no pint to link the library). This wasted memory can easily eat hundreds times more than those 12K.

Also note that with a fork-based solution one need to setup communication between 3 processes (the main control process, to-be-forked prototype and the child processes) complicating the code compared with that dump/mmap case when one deals with just main-child relations.

So as I wrote fork-based solutions are simpler, but for a complex applications such as a browser the fork may not be the most efficient way to handle things.

Hard to control, but usually not a liability

Posted Jan 12, 2009 20:44 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

With the fork it is hard to control all the memory in the to- be-forked process that is used by shared libraries upon initialization. This memory will be most likely changed in the child process (otherwise there would be no pint to link the library).

Actually a lot of libraries share memory after fork and don't change it. They load translation tables, conversion tables, etc - and more often then not they just read it after initialization and don't change. YMMV (it depnds of what is actually linked in your program), but to say initialization data for different libraries is a liability of fork is to oversimlify the problem.

When I look on the new process with empty page in Chrome and see that it eats over 5MB (RSS, not virtual or shared) it becomes quite hard to convince me that fork will do worse.

Hard to control, but usually not a liability

Posted Jan 12, 2009 21:38 UTC (Mon) by ibukanov (subscriber, #3942) [Link] (1 responses)

> new process with empty page in Chrome and see that it eats over 5MB

But that does not invalidate my claim that with enough efforts one can archive better memory utilization with dump/mmap sharing rather than in a fork-based version with the added benefits that the latter can be straightforwardly ported to Windows. This comes from the facts that with a dump one can precisely control what to share and rarely used parts of the shared image do not require loading until they are accessed.

Of cause, in most cases those efforts to implement dump/mmap are not justifiable, but a browser is a special case where the complexity of the rest of code allows to spend some efforts to optimize sharing.

As regarding those 5MB of private data in Chrome they may indicate that Chrome's developers has not bothered to optimize sharing. Or that Chrome really needs that amount of memory for various caches and JIT. That would not be surprising given that on my system a new xterm eats roughly 3MB of unshared memory while gnome-terminal consumes 6MB just to show plain text.

Hard to control, but usually not a liability

Posted Jan 24, 2009 1:01 UTC (Sat) by gdamjan (subscriber, #33634) [Link]

The difference beeing, that fork thing has been field tested for milions of years (internet years), used very-very often, and probably as perfect as it gets in software.

Unlike you own very special and complex code.

Actually Chrome (and MS IE 8) are showing lack of features in Windows, not in Linux

Posted Jan 13, 2009 9:26 UTC (Tue) by muwlgr (guest, #35359) [Link] (1 responses)

fork semantics is implementable under Windows, as Cygwin does it in some way.

Cygwin implements fork(2) without COW

Posted Jan 13, 2009 9:57 UTC (Tue) by khim (subscriber, #9252) [Link]

Big difference. fork(2) with COW saves memory, fork(2) without COW wastes it...