recycle.bin

Members
  • Content count

    199
  • Joined

  • Last visited

  • Days Won

    12

recycle.bin last won the day on September 17 2016

recycle.bin had the most liked content!

2 Followers

About recycle.bin

  • Rank
    Advanced Member
  • Birthday 07/29/01

Profile Information

  • Gender
    Male
  • Location
    The Room
  • Interests
    MST3K and Ace Attorney
  1. Here's something different. I found it as an update to Mac OS 7.6.0 in the .sit file format. To use it, just extract it using Stuffit in a Mac OS 7.6.0 machine and install it. Despite it's alpha status, 'About This Computer' reports simply '7.6.1' as its version number, for some reason. Download: https://mega.nz/#!XV5RDAjQ!oaJONaq02tCNNUm_zfURoNKTOXhCt8IwuVvMGFUXADA On another related note, I also managed to get the final version of Mac OS/System 7.5.4. It was recalled hours before it was to be seeded to developers worldwide (due to some problems affecting the Power Macintosh 5400/6400 models), but it still managed to get out to some places. 7.5.5 is a copy of 7.5.4 that has these bugs fixed and nothing else changed, so don't expect 7.5.4 to be different from 7.5.5. It's not too common, so I thought that I would link to it here. Download: https://mega.nz/#!6YRkgYrR!rxRM0rPS-9GBCXtqAfXKfZNTkVk5gJf4Kvd-7_VTpRE Just extract it to a machine running 7.5.3 using StuffIt, and update.
  2. Now these are some leaks I'm genuinely interested in. Thanks a lot, AirportsFan!
  3. Here's a good one: I already mentioned Ubuntu 7.04 as my first Linux distro, but I forgot that I actually used it on an IBM Thinkpad before using it on VMware 6.5. What I also didn't mention that this was not my first OS I used other than Windows. For a couple of months in mid-2008, my family's computer ran on Opensolaris 2008.05 thanks to the RTM version of Vista borking up one too many times.(Hell, Beta 2 was more stable than the RTM on that computer!) The OS itself worked fine, except for the hardware detection. We ended up quickly going back to Vista SP1, which worked like a charm.
  4. Nothing much, really. It's like 10586, but from the main th2 lab with timebombs and legal messages added.
  5. After an unfortunate fiasco with build 10240 on my main, I have tested every build (which have only been Server builds lately) that can go onto my main in a VM to test if the basic, non-driver related stuff works. So far, this has worked like a charm. However. with the most recent builds, I hit a brick wall. Basically, I always use the Datacenter SKU with the Desktop Experience option. I have tested both the leaked 14291.1000, the officially released 14300.1000, and 14300.1010 with the highly recommended update KB3157663 installed at first boot. I can verify that this bug exists on all three builds. After the main installation is done, I installed the Wireless LAN Service through the Server Manager. (For those who don't know, this feature enables Wi-Fi.) After installing this, one would typically find the 'WLAN Autoconfig' service running in services.msc and the system's wireless adapter working correctly (or in the worst case, needing its drivers). One may expect the same scenario with these builds. However, after the installation of this feature, the 'WLAN Autoconfig' feature is nowhere to be found in services.msc. Worse still, if you try to install the network adapter's driver manually, you get a cryptic error about an invalid section in the driver's INF. I've searched online, and it seems this is not because of a corrupted download, but because these builds do not have the files required for the Wireless LAN Service. I just have a few questions: 1) Is this diagnosis (that these builds don't have the files needed by the Wireless LAN Service) correct? 2) If 1) is correct, will this issue be fixable with an update, or does MS need to release a new build? 3) How did this problem start in the first place?
  6. Build: 10.0.14300.1000.rs1_release_svc.160324-1723 Platform(s): Windows Server 2016 (released as the official Technical Preview 5 build) Ring: NA I could question why this build was released a bit late, but that doesn't mean that I'm complaining. https://technet.microsoft.com/en-us/library/dn765472(v=ws.12).aspx https://www.microsoft.com/en-in/evalcenter/evaluate-windows-server-technical-preview
  7. You would have the best chance of answering your question with builds between: 1. 3544 and 3562 2. 3663 and 3681 3. 3742 and 3757 As they were the one compiled when Server 2003 was changing it's branding. Other than those, the >200 Server 2003 builds between 3590 and 3790 are some of the most boring in terms of UI changes, so I'd assume they used another lab (before the second split), some kind of sub-branch (after the split), or maybe even just integrated those directly into the dnsrv lab.
  8. Looking by buildstrings alone, this may be a plausible theory, as I did not see any M3 Longhorn builds/buildstrings from any other lab but Lab06_N. The earliest buildstring from another lab I found had a build number of 4005 and it came from Lab01_N. (Thank Buildfeed for this.) The earliest hard evidence we have is 4028, compiled on 1st July 2003 in in an Enterprise Server SKU. (It also came from Lab01_N, BTW.) However, the sword cuts both ways: I did not see any Server 2003 builds/buildstrings from any lab0x after its 3663 (compiled 15 days earlier than the one with the white flag). All of them were either compiled by the main (I did not see this lab after the 368x range, either), the dnsrv (also used in SP1/2 betas), srvr2 (also used in the earliest SP1 betas like 3790.1023) or the RTM labs. This leaves a gap between July 2002 and January 2003 where no lab0x build (except lab06_n) was ever documented. Therefore, I propose this sequence of events: * Around the 354x-356x range (that is, Aug/Sep 2001 as you said), lab06 moves to Longhorn while the other labs remain on the .NET Server/2002 Server/Whistler Server branch (which resolved its identity crisis by 3562). * Around the 368x-369x range (that is, late Sep/early Oct 2002), the rest of the main labs jump ship to Longhorn. * The development of .NET Server 2003 (as it was named then) continues in dedicated labs like dnsrv, srvr2, etc. which were also later used for the SP betas.
  9. I managed to get the x64 US English ESD and verify that all was fine, and then I converted it into an ISO using the decrypter by gus33000. However, when I try to start Setup from Windows, I get this: Is anyone else affected by this? UPDATE: Ostensibly, 14291's setup cannot handle being started from a path which has a space in it. (For context, I store the setup files in " C:\Users\John Doe\Documents\* " where 'John Doe' is my username and * is the build number.) I've been upgrading to many builds since 10056, and this is the first build where I've had this problem.
  10. Thanks for the leak! A few things to note when installing this: * The BIOS date is November 17 1998. * You will need two separate keys, one for BackOffice itself (111-1111111 as shown in the picture above), and another for Office 2000. However, I got stuck on the second point, as this beta does not accept RTM or SR1 keys. If anyone can provide me with a working key, it would be appreciated.
  11. You only need the "Hidden Files and Folders" option. It's a regression from the XP builds in which the link to show hidden files and folders in not there. It's present in 3706-4001, AFAIK.
  12. Should I (manually) upgrade to this build, or stay with 14271? Most of the remarks I've heard about this build are good, but there are several installation problems mentioned by other people that make me wary.
  13. Judging from the length of the 'Known Issues' list and the stability of the previous build, I'd say this build probably has a chance of going out to the Slow ring.
  14. Has anyone noticed that the text on the 'Upgrading Windows' screen has been changed to 'Updating Windows'? I didn't notice it until I started upgrading to 14257.
  15. This is how any attempt will eventually end on NT OSes: As you can see, there's nothing much to learn from this one.