Posted on 04/23/2009 12:25:37 PM PDT by aft_lizard
New build hasn't been leaked to torrents -- yet
Microsoft's Windows 7 is perhaps one of the most hotly anticipated tech products of the year. Its beta builds have thus far showcased both polish and Microsoft's willingness to improve and take constructive criticism. Microsoft has over 2,000 planned bug fixes for the Release Candidate phase, and recent builds have given users just a taste of the promising new OS's potential.
Hot on the heels of the leak of RC build 7077 to the torrent world earlier this month, Microsoft has delivered a major milestone build to OEM partners and TAP gold customers. Microsoft reportedly compiled the new build, 7100.0.winmain_win7rc.090421-1700 (build 7100, for short), on Tuesday, and has already began distribution.
While some are likely eagerly awaiting the build to hit torrents, for home testing, Microsoft may actually beat leakers to the punch. Microsoft announced via its Partners page plans to launch a semi-public distribution of the release candidate by May 5th to MSDN/TechNet customers. The official release will invariably also be shared by these customers over torrent. The 7100 build seems a likely target for the release.
There's potential, though, that the posting could be a mistake, as a Microsoft Online Chat Concierge spokesperson commented, "Currently the Windows 7 RC has not been available through the TechNet subscription yet, only the Microsoft OEM partners such as Dell, Siemens are taking part in the RC's this period of test."
Regardless, whenever DailyTech get its hands on release candidate 7100, a features update piece can be expected. Until then, like the rest of community, we have to wait and see.
cmd is a 32/64 bit windows console app not a dos app.
*Why you still have environment variables for Path and Temp?*
You mean just like Unix/linux?
I was so sure that you would bring up drive letters.
To quote an article "Windows Vista is a bloated pig of an operating system. In fact, compared to Windows XP with Service Pack 2 or 3, Vista requires roughly twice the hardware resources to deliver comparable performance."
You apparently like Vista, I don't. I belive the marketplace tends to agree with me, as Vista was bluntly refused by the marketplace. IMHO, MSFT is in a very tenuous place. They came out with WinME, which was a colossal mess. Shortly thereafter, MSFT came out with WinXP. People who dropped money to upgrade from Win2K and bought that POS, WinME, felt that they had been cheated. And rightly so, WinME should never have seen the light of day. Much the same can (and has been) said for Vista. Win7 apparetnly is, what Vista was supposed to be. This goes right back to 'Quality'.
Where WinXP would allow applications to run in 'emulation mode', Vista does not. What do we gain, by dropping something that allowed legacy hardware and software run on our machiens? Basically, we traded legitimate needs for some fluff (Aero) while we lost something commonly used in most offices, Instant Messenger. (You do know that Instant Messanger is missing essential APIs so it crashes under Vista, without regard to SP releases, don't you?)
Superprefetch is really a misnomer. The South Bridge chip usually maintains a pre-fetch register that is capable of holding 2-8 quadwords. This 'should' be handled in hardware, not software. The entire point of 'pre-fetch' is to prevent unnecessary latency while the hardware negotiates to talk to memory, or HDD. Still, WinXP has pre-fetching turned on - and I have yet to see a benchmark comparing WinXP to Vista's pre-fetch routine.
The last point is that your 4/8 Gig statement. Go ahead and load 8 Gig in your 32 bit machine if that makes you feel good. The fact is that depending upon your BIOS, you will only see about 3-3.5 Gig. 32 Bits only allows you access to 4 Gig. For the 64 bit machines, you can go a bit larger, but what percentage of users have more than 2 Gig in their PC?
CMD is the remains of DOS. Those path and temp variables come straight from DOS. I notice you carefully ignored the majority of what I said. Reality is DOS is the heart of Windows. You look at any Windows Architecture diagram (like this one http://www.activewin.com/winvista/images/LonghornArch.PDC2003.png ) and you’re going to see FAT, File System Cache and IO Manager, those are the main areas where Windows feet of DOS clay (and CP/M even) live. Deny it if you want, throw insults if you must, but the truth is the truth, and the truth is Windows still sits on DOS.
“Unlike COMMAND.COM, which is a DOS program, cmd.exe is a native program for the platform. This allows it to take advantage of features available to native programs on the platform and not available to DOS programs. For example, since cmd.exe is a native text-mode application on OS/2, it can use real pipes in command pipelines, allowing both sides of the pipeline to run concurrently. As a result, it is possible to redirect the standard error in cmd.exe, unlike COMMAND.COM. (COMMAND.COM uses temporary files, and runs the two sides serially, one after the other.)
Technically, cmd.exe is a Windows program that acts as a DOS-like command line interpreter. It is generally compatible, but provides extensions which address the limitations of COMMAND.COM:”
You are also incorrect on the kernel see the following:
http://blog.chinaunix.net/u2/67414/showart_1898747.html
http://en.wikipedia.org/wiki/Windows_NT
or the following book http://www.amazon.com/exec/obidos/ASIN/0735625301/gustduar-20
*When MSFT releases a new OS, vendors are given over a year to come up with a driver, which is generally included in the OEM and retail OS disk. MSFT did not include these drivers in their disk (ie. missing ICD for OpenGL). This lead to workstations that could for all intensive purposes, no longer run AutoCAD, OrCAD, and a host of other OpenGL applications.*
Funny - when I install Vista the included nVidia driver and ATI driver support OGL out of the box.
*Where WinXP would allow applications to run in ‘emulation mode’, Vista does not.*
Yes it does.
*Superprefetch is really a misnomer. The South Bridge chip usually maintains a pre-fetch register that is capable of holding 2-8 quadwords. This ‘should’ be handled in hardware, not software. The entire point of ‘pre-fetch’ is to prevent unnecessary latency while the hardware negotiates to talk to memory, or HDD. Still, WinXP has pre-fetching turned on - and I have yet to see a benchmark comparing WinXP to Vista’s pre-fetch routine.*
Now that shows you have no idea what you are talking about.
“SuperFetch is a technology that pre-loads commonly used applications into memory to reduce their load times. It’s based on the “prefetcher” function in Windows XP.[8]
The intent is to improve performance in situations where running an anti-virus scan or back-up utility would result in otherwise recently-used information being paged out to disk, or disposed from in-memory caches, resulting in lengthy delays when a user comes back to their computer after a period of non-use.
SuperFetch also keeps track of what times of day that applications are used, which allows it to intelligently pre-load information that is expected to be used in the near future.”
Windows (MS-DOS Based)
Windows 1.0
Windows 2.0
Windows/286 and Windows/386 (Windows 2.1)
Windows 3.0
Windows 3.1, Windows 3.1 for Workgroups, Windows 3.11, and Windows 3.11 for Workgroups (WfW)
Windows 95 (Windows 4.0)
Windows 98 (Windows 4.1)
Windows Millennium Edition (Windows 4.9)
Windows NT
Windows NT 3.1
Windows NT 3.5
Windows NT 3.51
Windows NT 4.0 including up to Service Pack 6a
Windows 2000 (Windows NT 5.0) including up to Service Pack 4
Windows XP (Windows NT 5.1) including up to Service Pack 3
Windows Server 2003 (Windows NT 5.2) including up to Service Pack 2
Windows XP Professional x64 Edition (Windows NT 5.2) including up to Service Pack 2
Windows Fundamentals for Legacy PCs (Windows NT 5.1) including up to Service Pack 3
Windows Home Server (Windows NT 5.2) Windows Vista (Windows NT 6.0) including up to Service Pack 1
Windows Server 2008 (Windows NT 6.0) including up to Service Pack 1
Windows 7 (Windows NT 6.1)
Windows Server 2008 R2 (Windows NT 6.1)
Everthing since WinME is based on the WinNT kernal. DOS is ran in emulation mode. You are not running on the lower OS, like you used to; MSFT saw fit to continue to support DOS and DOS commands via an eumlator (Do a search for a C:\DOS\ directory. I'd love to hear if you find it).
Let;’s see your first link is about Linux, your second link doesn’t say anything that contradicts me and your third link is to a book that won’t be out for 2 months.
That’s your proof? Meanwhile the Environment Variables on the system you’re sitting in front of RIGHT NOW has a bunch of DOS stuff we used to set in the autoexec.bat.
The NT Kernel is still wrapped around DOS. They’ve never gotten away from DOS, they buried it, they hid it, but it’s still there. You don’t need to stick things in c:\dos\ to have a bunch of DOS code in the core kernel files.
You didn’t scroll down - if you had you would have seen this - *The process for Windows is similar in many ways, given the common architecture. Many of the same problems are faced and similar initializations must be done. When it comes to boot one of the biggest differences is that Windows packs all of the real-mode kernel code, and some of the initial protected mode code, into the boot loader itself (C:\NTLDR). So instead of having two regions in the same kernel image, Windows uses different binary images. Plus Linux completely separates boot loader and kernel; in a way this automatically falls out of the open source process. The diagram below shows the main bits for the Windows kernel:
Windows Kernel Initialization*
The second link contains the following - *It was originally designed to be a powerful high-level-language-based, processor-independent, multiprocessing, multiuser operating system with features comparable to Unix. It was intended to complement consumer versions of Windows that were based on MS-DOS. NT was the first fully 32-bit version of Windows, whereas its consumer-oriented counterparts, Windows 3.1x and Windows 9x, were 16-bit/32-bit hybrids. Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Home Server, and Windows Server 2008 are based upon the Windows NT system, although they are not branded as Windows NT.*
http://www.amazon.com/Microsoft-Windows-Internals-4th-Server/dp/0735619174/ref=sr_1_2?ie=UTF8&s=books&qid=1240598991&sr=1-2 - linked to the wrong edition.
Examples of the DOS *stuff* in the env variables if you please.
Then how can it boot on non x86 chips?
And none of those quotes contradict anything I’ve said.
I already gave you examples of the DOS stuff in the environment variables.
Takes a different version of the kernel, one that buries the DOS a little deeper and works around it.
I have seen the source code - their is no dos any place except for the dos emulator subsystem.
And are you going to address getting superfetch completely and totally wrong?
Admitting you made a mistake will not kill you.
You’ve read ALL of the source code and compared it to ALL of the DOS code and found none of the later in the former? Not one single line? Why do I not believe that.
I never said anything about superfetch, so no I won’t be addressing anything you think I got wrong on that.
Sorry I confused you with another user.
You are obsessed with NT being built on DOS - when it isn’t. I can’t convince you otherwise because you refuse to accept anything that goes against what you know to be true.
I mean you do know that win32/win64 apps don’t have to be graphical - that they can be console (text) based - don’t you?
I’m not obsessed with anything. It’s a simple fact, you’re the one that can’t accept it.
Win32 apps being able to be console based has no bearing on the discussion. this is part of why we both know you’re wrong, everything you put forth is a red herring, or an insult.
You used cmd.exe as *proof* that the NT kernel is dos based despite it being a 32 bit console app.
You also seam to think that entries kept for backwards compatibily reasons means the entire system is running on DOS.
If it is that is some trick - I mean a 16 bit single core OS managing 8 GB of RAM and 4 cores.
If full emulation mode is supported, why can't I load my Dell P1000 Laser Printer driver on my Vista machine? It works on WinNT through WinXP. The laser printer is only about 4 year old. It's not like it's a recycling refugee that's been hiding in my closet for 10 yrs. If Vista supports compatibiltiy modes, this should not be the case - I should expect to maintain base functionality, just lower performance. Much like not having a 'proper' driver for your graphics card will result in a generic, non-optimized driver loading. You still get basic performance. High Speed SCSI tape backup drivers are non-functional in Vista, scanners of all sorts and shapes. Why can WinXP (both 32 and 64 bit) handle legacy drivers, but Vista doesn't? We could move on to the area of factory automation and DAQ cards, or any other number of very expensive, very customized PC hardware. This is a basic software Quality issue.
All MSFT has to do, is inform the customer that there is limited legacy support. Forcing the consumer, as MSFT attempted to do, to abandon perfectly good equipment, so they can have a new OS, is negligent.
If you updated your Linux distro, and suddenly found your entire RAID array corrupted and unmountable, your tape backups and your network going down and not coming back up - I doubt you'd have very nice things to say. Now imagine not having the ability to retreive or obtain the previous Linus Distro that had worked fine for 10 years. That's my point.
Be careful on how you interpret 'prefetch'. Basic question, what runs the PC? Software, or the hardware? The hardware does the pre-fetching, the software sits at a much higher level, well above the embedded level that is iniated by BIOS to drive the South Bridge. A pre-fetch in software does nothing more than push a pointer to a memory stack, that is ALREADY sitting in Hardware (the pagefile, RAM, cache or in the South Bridge). The Software (OS or not) does not have memory, it does it's best to manage memory found in the hardware - but all it can do is direct the hardware. WinXP has a pre-fetch, and most benchmarks have found that a maximum of 3 Quadwords was all that was required for optimal performance. Now a pipeline controller will obviously flush the pipeline in a unconditional branch or JMP - but if you think that a software "Prefetch" is magical, you are mistaken. That's why we have multi-level L2 and L3 cache. All the software does is write notes to itself, as to where the hardware stashed the code. The hardware then manages which memory locations are in the Read, Modify or Write phases, whether the data is stale, or if a core is presently preparing to update a memory area (modify flag). Don't believe me? Dive into your BIOS and disable the pre-fecth in your South Bridge, and crank the OS prefetch. Without the SB pre-fetch turned on, OS prefetch or not - you will take a significant performance hit.
I have yet to see any benchmarks that show the performance bump the Super Pre-fetch has over the standard prefetch, compared to the super-duper-double-fudge brownie pre-fetch. I question their 'real world' benefit. If your disk optimation program places frequently used applications, recent documents and the OS in high speed areas of the hard drive, the hardware is able to grab it a wee bit faster. Will it make your jaw drop? Probably not. Will you see the difference in a benchmark? Maybe. Will you 'feel' it in everyday use? I doubt it.
The NT Kernel is still wrapped around DOS.
Linky
Virtual DOS machine (VDM) is Microsoft's technology that allows running legacy MS-DOS and 16-bit Windows programs on Intel 80386 or higher computers when there is already another operating system running and controlling the hardware.
Recent versions of Windows NT for 64-bit architectures, including Windows XP Professional x64 Edition (x86-64), Windows XP 64-bit Edition (IA-64), Windows Server 2003 (x64) and Windows Vista (x64), no longer include the NTVDM; so they are unable to run 16-bit DOS or Windows applications. This is because an x64 CPU in its full 64 bit mode cannot go to virtual mode without a hard reset; Virtual mode is not part of the x64 specification, the CPU needs to be running in x86 mode
Superfetch has to do with the loading of information into main ram before it is needed. You should read up on what it is before you post again as you aren’t helping your credibility at all this way.
Dell has a vista 32 driver.
Due to superfetch apps like word, excel, VS2k8 start in much less time than they do without it. See - I actually tested.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.
