Linked by Thom Holwerda on Thu 27th Dec 2012 19:50 UTC
Permalink for comment 546548
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
More News »
Sponsored Links



Member since:
2007-04-18
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.
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.
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).
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.).
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.
Actually, given the above DLL+EXE size measurement, you confirm that it is much, much worse.