Linked by Thom Holwerda on Thu 27th Dec 2012 19:50 UTC
Windows The HTC HD2 is probably one of the most enduring mobile phones out there. While it originally shipped with Windows Mobile way back in 2009, it has become one of the most hacker-friendly devices out there, and hackers have managed to port virtually everything to the device - various versions of Android, MeeGo, Ubuntu, and Windows Phone have found their way to the HD2. Russian hacker Cotulla, responsible for many of these ports, has just announced the next big port: Windows RT is now running on the HD2.
Thread beginning with comment 546543
To view parent comment, click here.
To read all comments associated with this story, please click here.
saso
Member since:
2007-04-18

That's true, but again, it's still not the whole story.
There's an MSO.DLL and an MSORES.DLL that collectively take up 210 MB of RAM.


It's nice to focus on DLLs, but I also said "and a host of other resources". What I mean specifically under that heading is, for instance, garbage collector cruft, i.e. uncollected objects. Even a small GC program can easily accumulate hundreds of megabytes of RSS before the garbage collectors bothers doing something about it.

But these are loaded once -- even if you load all the Office programs simultaneously.


I know, that's why I was talking about shared libraries.

And even then, it doesn't actually take up 210 MB of physical memory. Remember that Windows NT has a demand-paged virtual memory system. Those files are demand-paged into memory, 4 KB at a time. Until one of the Office programs actually calls a function located on a certain page, then that page is not actually taking up any RAM.

I'm fairly certain they are paged at larger increments than that, otherwise the initial execution would be so exceedingly slow that even startup would take minutes to complete. What most likely happens (and I'm simply talking from *nix kernel experience, so feel free to correct me) is that the I/O subsystem pulls the files in in much larger chunks into the I/O buffer cache. Subsequent mapping of pages happens much faster (via process page table manipulation), but the blocks holding the DLL contents still take up space in the page cache, although much less than pulling it in completely in one go and also in an evictable manner subject to other kinds of memory pressure.

The Excel icon now takes 173 KB of disk space. One icon. (At 256x256, 32-bit color, as a high-quality PNG.) Now think about how many other icons there are in Office.

And that is a positive point how exactly? Also, most UI icons, I would hope, are not 256x256x32bpp.

Fonts.

A good-sized compressed TTF font is a few MB in size, at most. Unless there is a couple thousand fonts hidden in office somewhere, this contributes a few dozen MBs at most.

The new equation editor.

Depends. If it's a GUI with controls and some live code behind it, I would give it 10MB of extra. Given some icons and help pages, perhaps 30-40MB.

A new ligatures-aware layout engine.

New code: 3-4 MB (if the layout engine is really, really big, like 500KLOCs+).

New PivotTables.

How much space do their definitions/code take on disk?

More accurate statistics functions (the old ones are still there, to get bug-for-bug backward compatibility).

I'm sorry, but now you're into the silly things. This is just a bunch of interpreted code. Perhaps, and now I'm being very generous here, 10MB of new code, 30MB tops. I mean it's not like they re-implemented the entire office suite in it, they just added some utility functions.

So in summary, you're still only 1/10th the way. I know where the 9/10ths went - it's the animated sequences, the uncompressed BMPs on disk, the tons of various pre-made media, like music and video stuff for shit business presentations that nobody likes anyway. If you took it away, I doubt anybody would really complain, but then you wouldn't have the latest and greatest incremental update to sell to your locked-in business customers. There's money to be made!

Reply Parent Score: 2

tanzam75 Member since:
2011-05-19

So in summary, you're still only 1/10th the way. I know where the 9/10ths went - it's the animated sequences, the uncompressed BMPs on disk, the tons of various pre-made media, like music and video stuff for shit business presentations that nobody likes anyway. If you took it away, I doubt anybody would really complain, but then you wouldn't have the latest and greatest incremental update to sell to your locked-in business customers. There's money to be made!


Obviously, I wasn't giving an exhaustive list of where every single MB went on an Office install. I was just pointing out some of the features that I use that weren't present in Office 2003. In other words, I'm not getting nothing for my gigabytes, as you seem to think.

That having been said, you seem to be unaware that the templates and clip art have been mostly moved online in Office 2013. Only the most commonly-used templates have been left in the default install. (And it's the non-core Office applications -- Publisher and Access -- that are the biggest offenders. Word, Excel, and PowerPoint have really been slimmed down.)

My Office folder is 1.7 GB. 1.0 GB is DLLs, 192 MB is EXEs, 112 MB is fonts. A whopping 2.5 MB consists of those "uncompressed BMPs" that you're so worried about. Animations and music and videos? I can't find them. Maybe you can.

As for memory consumption, I don't know why you're going on about garbage collectors for. The Office programs are unmanaged, and written in a combination of C++, C, and (a little bit of) assembly.

--

You seem to be intent on being upset about something, for whatever reason.

Instead of throwing random stuff against the wall to see what will stick, perhaps it's better to first look into it. Maybe you'll discover that the situation is not as bad in reality as you seem to think it is.

Edited 2012-12-28 21:56 UTC

Reply Parent Score: 3

saso Member since:
2007-04-18

Obviously, I wasn't giving an exhaustive list of where every single MB went on an Office install. I was just pointing out some of the features that I use that weren't present in Office 2003. In other words, I'm not getting nothing for my gigabytes, as you seem to think.

I have written my fair share of application software and that is the split I was usually seeing. 1/10th code, 9/10ths resources. There's one issue though, it's easy to inflate the resources - simply save your app icon at higher res and you're done. It's much harder to inflate the code part.

That having been said, you seem to be unaware that the templates and clip art have been mostly moved online in Office 2013. Only the most commonly-used templates have been left in the default install. (And it's the non-core Office applications -- Publisher and Access -- that are the biggest offenders. Word, Excel, and PowerPoint have really been slimmed down.)

How much space do these core 3 apps take up? I'm not an Office user, I've only got Microsoft's own claims online about the sysreq's to go on about.

My Office folder is 1.7 GB. 1.0 GB is DLLs, 192 MB is EXEs, 112 MB is fonts. A whopping 2.5 MB consists of those "uncompressed BMPs" that you're so worried about. Animations and music and videos? I can't find them. Maybe you can.

What. The. Fuck. 1.2GB of executable code? In Office alone? What the hell is Microsoft bundling in that thing? Just for reference, all of the executable code, including the kernel, device drivers and application software on my desktop Ubuntu system clocks in at around 1.2GB. Just for comparison, the 3.2 Linux kernel contains around 15 million lines of code (not all of it compiled, but a good deal) and compiled on x86 comes to around 120MB, so unless Office contains 5-10x that much code, there's something else at work here. It is just my suspicion that these EXEs and DLLs are packed full of auxiliary resources that you didn't estimate, or there's tons of static linking going on (or both).

As for memory consumption, I don't know why you're going on about garbage collectors for. The Office programs are unmanaged, and written in a combination of C++, C, and (a little bit of) assembly.

Do you have access to the source code? If not, how can you say that? Also, merely being written in C/C++ does not mean you don't utilize garbage collectors. A GC can be an implict part of the language (Java, C#, etc.), or one can use it explicitly (Boehm GC, OpenStep's refcount GC, GObject, etc.).

You seem to be intent on being upset about something, for whatever reason.


As I seem to have to endlessly elaborate, I was talking about in my original post about the "meh just get more powerful hardware" mentality. I don't care two shits about how exactly Office is implemented, what I'm talking about is the fact that a program of such a type shouldn't have the system requirements it does (I already agreed with galvanash earlier that Office's sysreq's are most likely like that just to reflect the sysreq's of the OS around it). We've had sophisticated desktop software 20 years ago which ran on 1/100th of the resource footprint. I used to run an OPENSTEP 4.2 for Mach on a 200MHz CPU with 64MB of RAM - a full Unix-like OS with a Microkernel (Mach), device drivers written in "managed" Objective-C and application software talking to the display server using an interpreted language (Display PostScript), rendering TrueType fonts and all that jazz. Nothing has changed fundamentally.

Instead of throwing random stuff against the wall to see what will stick, perhaps it's better to first look into it. Maybe you'll discover that the situation is not as bad in reality as you seem to think it is.

Actually, given the above DLL+EXE size measurement, you confirm that it is much, much worse.

Reply Parent Score: 3

zima Member since:
2005-07-06

Even a small GC program can easily accumulate hundreds of megabytes of RSS before the garbage collectors bothers doing something about it.

Googling garbage collection RSS gave... inconclusive results :p - as a mostly layman, I wonder what you meant there?

Reply Parent Score: 2