<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx</link><description>Instead of doing it en masse, Windows 95 did it incrementally.</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323580</link><pubDate>Fri, 17 Dec 2004 15:42:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323580</guid><dc:creator>Brad Shannon</dc:creator><description>Definitely interesting, thanks</description></item><item><title>Preventative hacks</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323583</link><pubDate>Fri, 17 Dec 2004 15:50:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323583</guid><dc:creator>Cooney</dc:creator><description>I know this isn't a general solution, but why not pad dll code so that instructions never cross page boundaries? This could be done at build time and costs, at most, a couple of bytes.</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323587</link><pubDate>Fri, 17 Dec 2004 16:07:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323587</guid><dc:creator>Adrian</dc:creator><description>People like Joel (of Joel on Software) have argued that code bloat isn't that bad because the OS only loads the pages it needs as it needs them.  Indeed, it sounds like Windows 95 did this.  But, from your description, it sounds like Windows NT fixes up an entire DLL at once--if necessary.  So, for modern versions of Windows, Joel's argument is only true when all of your DLLs are properly based.&lt;br&gt;&lt;br&gt;As projects grow more complex, and we reuse more and more components from third parties, ensuring none of the DLLs overlap becomes a more and more difficult task.  Given that, shouldn't MS reconsider a fix-up on the fly solution more like what Windows 95 has (but perhaps saving fixed-up pages in the page file to avoid redoing fix-ups)?&lt;br&gt;&lt;br&gt;From my VMS days, I remember tricks like putting all your entry points in a jump table in one or two pages, so that fix-ups wouldn't have to be applied throughout your library.  (The jump table used relative addresses.) Since the tables themselves were hit repeatedly, they tended to stay in your working set, so cost of the extra indirection tiny.</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323610</link><pubDate>Fri, 17 Dec 2004 16:37:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323610</guid><dc:creator>Fat Agnus and Denise</dc:creator><description>Cooney: you can't &amp;quot;pad dll code&amp;quot;, beacuse rebasing applies to *all* .dll's - not only those shipping with Windows.</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323624</link><pubDate>Fri, 17 Dec 2004 17:00:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323624</guid><dc:creator>Denny</dc:creator><description>This is a thing I used to Love with the AmigA OS and system:&lt;br&gt;&lt;br&gt;On the Amiga a Dll was called a .library&lt;br&gt;and all code in a well formed library was &amp;quot;Address Relative&amp;quot; so you had calls to other libraries via LoadLibrary() which amounted to getting the address of a jump table of pointers and all code inside the libaray did branches as IP + offset or IP - Offset or LibraryBaseAddress + Offset&lt;br&gt;&lt;br&gt;so here is the 64 Giga Dollar question?&lt;br&gt;can current intel / amd cpus generate this kind of code?&lt;br&gt;if so then Microsoft and other compiler vendors should be making dll's that use that form of addressing.&lt;br&gt;then the load address of a dll is just an address and no relocs or fixups are needed.&lt;br&gt;&lt;br&gt;can this be done?&lt;br&gt;</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323671</link><pubDate>Fri, 17 Dec 2004 18:26:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323671</guid><dc:creator>Cooney</dc:creator><description>Fat angus:&lt;br&gt;That's why I said it wasn't a general solution. For it to be a general solution, windows would have to refuse to load a dll that has an instruction that crosses a page. The intent of this padding is to reduce the incidence of the edge case that raymond described.</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323674</link><pubDate>Fri, 17 Dec 2004 18:36:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323674</guid><dc:creator>Raymond Chen</dc:creator><description>The x86 does not have an address-relative addressing mode, but the x64 does. You still need fixups for things like initialized data containing pointers or jump tables. (The latter because I don't think it has a &amp;quot;jump to IP + offset encoded in a register&amp;quot; instruction.)&lt;br&gt;&lt;br&gt;Cooney: This would require bi-directional communication between what are traditionally separate steps (compiling and linking). The linker would have to feed back to the compiler, &amp;quot;I'm about to put this function here, could you insert some NOPs for me and fix relative jumps to account for the extra NOPs?&amp;quot; And then the compiler would say &amp;quot;Okay, here's the new function&amp;quot;, and the linker would say &amp;quot;Oh, oops, that shifted this other function, could you move those NOPs you inserted backwards five bytes?&amp;quot; and the compiler would say &amp;quot;Okay, but I needed an extra NOP because that would have put me in the middle of a larger instruction.&amp;quot; and so on.&lt;br&gt;&lt;br&gt;</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323686</link><pubDate>Fri, 17 Dec 2004 19:03:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323686</guid><dc:creator>Ben Hutchings</dc:creator><description>Raymond: In retrospect, do you think that the attempt to make Windows 95 run in 4 MB RAM was actually successful? I didn't use it that much but friends who did seemed to find it somewhat painful to run in 8 MB. Obviously it would boot and run the included applets in 4 MB, but could it run &amp;quot;real&amp;quot; applications without swapping so much as to be impractical?</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323698</link><pubDate>Fri, 17 Dec 2004 19:22:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323698</guid><dc:creator>Raymond Chen</dc:creator><description>Heck the machine that I used to *develop* Windows 95 was a 50MHz 486 with 8MB. In my opinion, I was running &amp;quot;real&amp;quot; application in a practical way.&lt;br&gt;&lt;br&gt;You have to remember that your average computer in 1995 didn't have that much memory or hard disk space. Personal computers at most large corporations were only 4MB, so that was an important target to hit. If you bumped the minimum memory requirement of Windows 95 to 16MB, adoption would have been pitiful.</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323791</link><pubDate>Fri, 17 Dec 2004 22:37:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323791</guid><dc:creator>ch</dc:creator><description>You can run into a similar hassle on less &amp;quot;wierdo&amp;quot; processors, even on seemingly normal RISC processors.&lt;br&gt;&lt;br&gt;Back when I was at CMU, we ran into a terribly hard to find bug in Mach on the IBM ROMP that happened only when a branch and the branch's delay slot straddled a page boundary and a fault hapened on the second page. &lt;br&gt;</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323809</link><pubDate>Fri, 17 Dec 2004 23:15:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323809</guid><dc:creator>Larry Osterman</dc:creator><description>TOPS-20 (the os used on the decsystem20) used to have a bug that occurred when you set the &amp;quot;indirect&amp;quot; bit on the first byte of each page, then executed a &amp;quot;fetch memory&amp;quot; instruction referencing the first bit - it would attempt to fault the entire 18 bit address space into memory, which exceeded the 2M physical memory on those machines.&lt;br&gt;</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#323920</link><pubDate>Sat, 18 Dec 2004 05:43:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:323920</guid><dc:creator>Phaeron</dc:creator><description>It seems to me that some of the benefits of on-the-fly rebasing would be offset by the need to keep the relocations resident, whereas they could be dumped by NT after load. You'd take the massive hit on load but then swapping would be more efficient.&lt;br&gt;&lt;br&gt;On a side note, I once saw a multimedia filter DLL that was linked at 00400000....&lt;br&gt;</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#324040</link><pubDate>Sat, 18 Dec 2004 16:46:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:324040</guid><dc:creator>James Schend</dc:creator><description>Heh.  What's funny to me is that despite knowing C and C++ inside and out, I've never in my life really dealt with shared libraries, so I've never learned stuff like this.&lt;br&gt;&lt;br&gt;Of course, I've never really done any Windows coding, either.  I wrote a lot of code for MacOS Classic, which to my knowledge didn't even have shared libraries until version 8.0.  Classic had its disadvantages, but it sure was a simple API to code.</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#324041</link><pubDate>Sat, 18 Dec 2004 16:52:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:324041</guid><dc:creator>Mike Hearn</dc:creator><description>Has an ELF style global offset table ever been considered as a PE DLL extension? That way you could avoid text relocs.</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#327202</link><pubDate>Mon, 20 Dec 2004 05:20:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:327202</guid><dc:creator>Norman Diamond</dc:creator><description>&amp;gt; It was just a historical tidbit that I hoped&lt;br&gt;&amp;gt; somebody might find interesting.&lt;br&gt;&lt;br&gt;Yes, the history channel is fine, and is interesting, even though Windows 95 (apparently not your parts thereof) are indefensible.&lt;br&gt;&lt;br&gt;&amp;gt; If you bumped the minimum memory requirement&lt;br&gt;&amp;gt; of Windows 95 to 16MB, adoption would have&lt;br&gt;&amp;gt; been pitiful.&lt;br&gt;&lt;br&gt;Yeah, corporations that had Windows 3.1 working would keep it working until they moved to Windows NT4 Workstation and then that would work too (before SP4).  But retail customers would still be getting PCs with Windows 95 preinstalled and that would still be as pitiful as it was.  I've retrieved an old PC running W95 (A but can do B), bought a used Adaptec 1460 whose driver is built into W95 (and have a few other SCSI cards), still have my 3 gigabyte SCSI hard drive (and others), and hope we can meet someday.&lt;br&gt;&lt;br&gt;Nonetheless the history channel is interesting, and you'd have a right to post it even if it weren't, no problem there.&lt;br&gt;&lt;br&gt;12/17/2004 11:03 AM Ben Hutchings &lt;br&gt;&lt;br&gt;&amp;gt; Obviously it would boot and run the included&lt;br&gt;&amp;gt; applets in 4 MB, but could it run &amp;quot;real&amp;quot;&lt;br&gt;&amp;gt; applications without swapping so much as to&lt;br&gt;&amp;gt; be impractical? &lt;br&gt;&lt;br&gt;A few years ago I retrieved an older PC and got W95 running on it in 10MB, more than twice the minimum.  Solitaire and Minesweeper and Notepad were really snappy, none of the delay that is noticed when invoking them under Windows 2000 or XP.  I vaguely recall putting Word 95 on it but that was slow, and I didn't try adding Internet Explorer to it.</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#327290</link><pubDate>Mon, 20 Dec 2004 11:02:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:327290</guid><dc:creator>Ben Hutchings</dc:creator><description>Raymond: I do remember 1995, thankyou - I was mostly using an Amiga then, and it also had 4 MB RAM. I wasn't questioning whether 4 MB was a commercially important target spec, but whether that target was achieved in a meaningful way. I seem to recall people saying that Windows 95 was driving up demand for RAM as people decided it practically needed 8 MB.</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#328469</link><pubDate>Tue, 21 Dec 2004 11:22:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:328469</guid><dc:creator>cola</dc:creator><description>Why would they fix up the instruction when only half of it is present in memory?  When it runs, the other page has to be faulted in and they can fix it then.&lt;br&gt;&lt;br&gt;Although that method would have the interesting side effect that *copying* functions out of a DLL would fail, since the first part would already be finished at the time of the fault.  And double fixups would have to be avoided with a bit or something.</description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#328977</link><pubDate>Tue, 21 Dec 2004 17:33:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:328977</guid><dc:creator>Raymond Chen</dc:creator><description>You can also have fixups in the data segment, and you must admit that having data change depending on what order you read from it is pretty strange. (And what if the loader decides &amp;quot;I need to increment this value due to a carry&amp;quot; and the value had already been changed by the program? Now what do to you?) </description></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#329649</link><pubDate>Wed, 22 Dec 2004 07:52:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:329649</guid><dc:creator>Thomas Heller</dc:creator><description>Why are dlls always rebased on 64-k boundaries?</description></item><item><title>Scooblog on Corporate Transparency - Part 1: What Comprises Transparency?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#341037</link><pubDate>Wed, 29 Dec 2004 07:44:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:341037</guid><dc:creator>scooblog by josh ledgard</dc:creator><description /></item><item><title>Scooblog on Corporate Transparency - Part 1: What Comprises Transparency?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#341050</link><pubDate>Wed, 29 Dec 2004 07:46:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:341050</guid><dc:creator>scooblog by josh ledgard</dc:creator><description /></item><item><title>re: How did Windows 95 rebase DLLs?</title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#343574</link><pubDate>Wed, 29 Dec 2004 09:06:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:343574</guid><dc:creator>Phill</dc:creator><description>I believe Windows 95 was successful at running in 4mb. It was faster with 16mb, but my car doesn't go as fast as a ferrari either.&lt;br&gt;&lt;br&gt;While there are many companies that went from Win 3.1/3.11 to WinNT, there are other companies that went from Windows 95 to Windows 2000. The rollout policy of a large company is rarely based on any logical conclusions. Normally it's down to when they last spent money &amp;amp; the resources they have available now. They might throw popular misconceptions around as the reason for what they do, but that just makes their lives easier.&lt;br&gt;&lt;br&gt;Coming from an Amiga background, I actually thought Windows 95 was the first version worth running, but I switched to WinNT4 when I had a machine capable of running it ( mainly because I had problems running windows 95 &amp;amp; windows 98 beta on the machine ).&lt;br&gt;&lt;br&gt;Phill&lt;br&gt;</description></item><item><title>BaseAddress </title><link>http://blogs.msdn.com/oldnewthing/archive/2004/12/17/323556.aspx#800703</link><pubDate>Sat, 07 Oct 2006 18:39:04 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:800703</guid><dc:creator>Rene Schrieken</dc:creator><description>&lt;p&gt;It is time again for something completly off-topic. In februari I read this msdn article regarding startup&lt;/p&gt;
</description></item></channel></rss>