cluberti

While it is possible, using DNS for this is a bit overkill. Assuming you have access to the webserver (or have access to a technician that does), simply put a placeholder page (called default.html or similar) that does a redirect to the "long", ugly URL. http://www.w3schools.com/Html/tryit.asp?fi...ryhtml_redirect Once you have this page in place, requests to http://mail.spherelinksmail.com will get redirected to whatever URL is in the redirect page at the root of this webserver.

The only P4 chips that supported x86-64 were certain Prescott chips: Since the Prescott chips shipped from 2.8GHz to 3.4GHz, it's hard to say with 100% certainty what you have in there and whether or not it's capable of x64 or not. If you want to be sure if your CPU supports x86-64, download and run cpu-z and see if your CPU has "EM64T" instructions support:

I think he's thinking about group policy changes background, as the default refresh interval is 15 minutes. Anything done locally is either immediate, or will take effect the next time group policy is refreshed (a gpupdate /force may be required, which may in turn require a reboot if any changes applied are system-level).

There's not a lot of difference between 7022 and 7000 (some task pane visual differences, some icon changes, some WMP changes to playlists in the jump lists, and the ability to remove more windows components from windows features list, for example), although 7032 brings IE8 RC1 and 7048 and higher enter into the escrow builds for Win7 RC1 (and the changes that you'd notice are documented on the Engineering Win7 blog). Honestly, I'd suggest using build 7000 if this is going to be a machine you do any work on, as it was tested and tweaked far better than 7022 (or any other build since 7000, really), as these builds are really for testing changes between builds, fixing bugs, etc, rather than being an actual "beta test drive" of a functional OS.

After discussion of this offline with seedofonan, I finally get what is being asked, so I will publicly acknowledge my misunderstanding of the question and offer my apologies to all involved for the misunderstanding. He's talking about Windows taking an application's 4GB of shared kernel/process VA, and having the Windows memory manager physically placing it above 4GB on the system (say, physically locating mspaint.exe's VA in pages above 4096), and on an x86 server OS that supports this via /PAE, yes this is possible. Henceforth, a public mea culpa for not understanding the question clear enough - and if Boardbabe was asking this, then I apologize as well because it was a misunderstanding of the question on my part. x86 Windows client OSes are indeed limited artificially to 4GB and no more, due to the 64bit address space shown to drivers and potential for issues (real or perceived - I'm not aware of any drivers that would crash when confronted with 64bit addresses vs 32bit addresses on load in the last few years, but I guess it's possible). There's also the memory manager overhead, as the server OS has to translate the memory address above the 4GB boundary for either the kernel or process' share of the VA down to a 32bit range, although on newer machines I do not know what kind of a performance hit this would incur. I also admit I hate it when I'm wrong in understanding a question. My apologies to all involved, it's my misunderstanding. However, I do 100% stand by my statement that there is no real detriment to switching to a 64bit OS (and skipping the PAE hack and performance overhead you will incur), and that for an app to directly access RAM above 4GB on Windows it needs AWE (Windows itself is using a form of AWE to perform the hack), but I will admit publicly that I misunderstood the question. What I posted is technically correct info, but not in answer to this question. And to answer the original question, I guess it would be possible to hack the 2008 R2 memory manager down onto Win7, although it'd probably be a violation of the EULA.

All I/O goes through the filesystem filter drivers - it's not enough just to show it loaded on the stack. While it may be symevent, we need a full memory dump to see the IRP and the status of the IRP, the I/O path we're in, and anything loaded into csrss.exe that would otherwise cause an issue as well. While you may be right, it's never enough with a minidump to say what causes csrss.exe to terminate - as can be seen here: // It's an F4, so what does param 4 say: 0: kd> .bugcheck Bugcheck code 000000F4 Arguments 00000003 86fa28b0 86fa2a24 805d164c // Param 4 should be an ASCII string: 0: kd> da 805d164c 805d164c "Terminating critical process 0x%" 805d166c "p (%s)." // The thread actually does seem to indicate it's NOT symevent, as the terminate call came before // we went through that driver - note that this thread is an LPC server, so it would be interesting // to know who is the client thread and exactly what that thread was doing (there should be an IRP // there as well to take apart). This thread is a worker thread to crash the box, note it's just running // through the exception handler: 0: kd> !thread GetPointerFromAddress: unable to read from 80561134 THREAD 86b1a528 Cid 0380.0eac Teb: 7ffac000 Win32Thread: e9bed9d0 RUNNING on processor 0 Not impersonating GetUlongFromAddress: unable to read from 805611cc Owning Process 0 Image: <Unknown> Attached Process 86fa28b0 Image: csrss.exe ffdf0000: Unable to get shared data Wait Start TickCount 8394 Context Switch Count 94 LargeStack ReadMemory error: Cannot get nt!KeMaximumIncrement value. UserTime 00:00:00.000 KernelTime 00:00:00.000 Win32 Start Address 0x0000aded LPC Server thread working on message Id aded // <- Would be nice to see this thread and it's IRP Start Address 0x75b44616 Stack Init a7b07000 Current a7b06c1c Base a7b07000 Limit a7b04000 Call 0 Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 0 ChildEBP RetAddr Args to Child a7b0649c 805d07f3 000000f4 00000003 86fa28b0 nt!KeBugCheckEx+0x1b (FPO: [5,0,0]) a7b064c0 805d16f7 805d164c 86fa28b0 86fa2a24 nt!PspCatchCriticalBreak+0x75 (FPO: [3,0,0]) a7b064f0 a8ea2175 86fa2af8 c0000006 86ab3f70 nt!NtTerminateProcess+0x7d (FPO: [2,4,4]) WARNING: Stack unwind information not available. Following frames may be wrong. a7b06574 805413fc ffffffff c0000006 a7b069b0 SYMEVENT+0x12175 a7b06574 a7b069d8 ffffffff c0000006 a7b069b0 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ a7b06574) a7b065e8 80501131 00000008 00000246 804fe7de 0xa7b069d8 a7b065f4 804fe7de ffffffff c0000006 a7b069f8 nt!ZwTerminateProcess+0x11 (FPO: [2,0,0]) a7b069b0 8050289f a7b069d8 00000000 a7b06d64 nt!KiDispatchException+0x3a0 (FPO: [Non-Fpo]) a7b06d34 80544cc7 015af288 015af2a8 00000000 nt!KiRaiseException+0x175 (FPO: [Non-Fpo]) a7b06d50 805413fc 015af288 015af2a8 00000000 nt!NtRaiseException+0x33 a7b06d50 75b7cfd5 015af288 015af2a8 00000000 nt!KiFastCallEntry+0xfc (FPO: [0,0] TrapFrame @ a7b06d64) 015afe9c 00000000 00000000 00000000 00000000 0x75b7cfd5 Don't jump to conclusions just because there's something non-Microsoft in the stack, especially on a bad I/O dump or F4 dump - all I/O goes through registered system filter drivers, not just bad ones. We need a complete memory dump and another .dmp file from said complete dump before we can say more.

Things like the Paradox crack, for instance.

180 days isn't a hard trigger, it's just an example - it can happen sooner, if Microsoft so decides - if they blacklists a key, or release a WGA update, etc. If Microsoft triggers a re-validation, your Vista install will ultimately attempt to re-validate, and must be online to do so. However, it seems like this happens 2 to 3 times a year, hence the ask for whether or not the machine was off for 6 months.

I stand corrected, looks like Be did this in 2000. The QnX one I knew about, but it requires DOS to load and a few drivers, so it's not self contained. Be appears to be, however, so it counts. And my google-foo is good, it's just that all 8 people who used BeOS didn't really document anything in depth regularly, and the Be archives aren't exactly easily searchable.

Sorry for the OT, but does this mean that if a PC stays disconnected for, say, 181 days, Vista activation needs to be redone? jaclaz Correct.

You will probably need to call HP for assistance, and see what they suggest. They may require you to do a restore using a restore point (if you hadn't tried that already), or perhaps a reinstall with their restore media.

I'm assuming the HP machine came from HP with the Vista Business OS installed already? Were there any changes to the system, hardware or software, that would potentially have caused Windows to think it needed to reactivate? Or, was the machine offline from an internet connection for more than 6 months?

Good catch .

Well, for what it's worth, that is the error message you're getting. Perhaps something about your system, but it's definitely a foobar'ed install.

Would you care to quote your source on this? Because it is totally, utterly, wrong. A running Windows process knows *nothing* about the RAM underneath, only the memory manager does. And the memory manager can only map VA to either physical RAM or to paging file space that it can address - in 32bit, it is *4* gigabytes of RAM, and if you enable the PAE kernel, 32 to 128GB of paging file depending on the version of Server, and *no more*. If a process wishes to make use of actual, *physical* memory above the 4GB boundary on a 32bit system, it *has* to do so itself, *without* the help of the NT memory manager, using the PAE kernel and the AWE API set as I've mentioned above, and it *must* incur the overhead of mapping the memory addresses into a VA location within it's 2GB or 3GB (depending on whether or not /3GB is enabled) of VA so that it can be addressed when necessary, and the app must do the translation and memory managemtn.If you're running a Windows service (like Terminal Services, for instance) that is written to take advantage of the PAE kernel, then yes, you can see Windows Server editions actually using more than 4GB RAM - but again, the limitation of *only storing data*, and *no executable code* persists even to Windows, and it's important to denote that it's not technically any Windows binaries using the additional memory, it's Terminal Services (in this example). It is not physically possible to execute code in an address space above the 4GB boundary, as FFFFFFFF is the largest area that can be addressed by a processor in 32bit mode, period. Anything higher will cause an exception. Yes, it has been. Just because you do not get it doesn't mean the answer isn't here. It's been discussed ad nauseum here and elsewhere, and unfortunately you fail to grasp memory management in Windows - I'm sorry, but you do. Please, please read Windows Internals, either the currently shipping 4th edition or grab the 5th Edition when it releases later this year before posting about this again here. If you want some more information, please let me know, but what you currently understand seems to be incorrect.

I'm not sure exactly what it is - a google search turned up some hints that it may be a trojan, but it wasn't conclusive. I'd upload it to virustotal.com and have it scanned there, to get a better idea of what it is.

Which, the fisher price child's toy block blue/green look? I hope this statement is a joke, but I'm guessing I will be wrong...

Unless you can find one online, say eBay for example, then no. Microsoft hasn't distributed ME discs in years, so unless you can find a 3rd party selling them, you're out of luck.

Looks like your nLite install is bad: # for hex 0xc000007b / decimal -1073741701 : STATUS_INVALID_IMAGE_FORMAT ntstatus.h # {Bad Image} # The application or DLL %hs is not a valid Windows image. # Please check this against your installation diskette. # 1 matches found for "c000007b" I'd suggest removing nLite, downloading again, and doing a reinstall.

Just because the file was republished does not mean anything in it changed. If it hashes the same as the old (as has already been discovered), it was likely a page update to the old page that required a republish of the page and file.

Done

Legally, if there's no COA affixed nor media purchased with the box, then yes, you *must* get media and a COA/license to legally reinstall Windows. If you're providing support, you could look into retail OEM packs (3, 5, 30, etc) for cost savings, but you'd have to ask Microsoft on the legality of reselling a machine with a *new* OEM license - I do not know if that is OK or not. Note that in the ME and 2000 EULAs, any OEM upgrade media had to be acquired *from the vendor*. So, if you wanted an OEM upgrade copy of Windows, you *had* to buy it from the vendor to be legal, or you had to go out and purchase an FPP retail copy of Windows from the retail channel. Also, there was one other quirk that existed at least through the XP OEM EULA (not sure about Vista, as I've not seen a Vista OEM EULA as of yet, but I'd bet it's there as well) - if you swap the motherboard in an OEM machine, you *have* to get a new copy of Windows (either from the OEM or from a retail channel). That was the only caveat/instance of an OEM machine with an OEM COA/license where said license was invalid, that if the motherboard is swapped it requires a new license. If the OEM repaired it, they were responsible for the new COA and license, but if the owner did so outside of warranty replacement they were technically in violation of the EULA if they reinstalled the OEM copy that shipped with the machine onto the machine with a new/different motherboard inside.Again, just FYI.

Correct, because posting an "in layman's terms explanation" for the vast majority of the people who can't figure this out in technical terms for themselves is somehow creating bias. Great, you know math and probably some electrical engineering, and understand the concepts - guess what, the vast majority of people in the world do not. And you should probably re-read the definition of the word "bias", because there's none in my post - if you think "bias" means "reiterating facts", then yes, I'm biased. So I'm sure the 8088 was good enough for you, because programs were designed that didn't need to take advantage of the additional 16 registers in a 32bit processor? There *are* applications that run well on 64bit, and if everyone thought like you, we'd all be running either a 16bit 8086 or a true 64bit only like the Itanic. Yes, let's hold back progress out of the limited 32bit architecture just because most apps won't use it yet. Let's ignore the fact that there's really no problems with moving to an x86-64 architecture on 64bit hardware, and throw out the "why if only a few apps will actually use it!" argument. Because holding up progress that really doesn't bring with it *any* perceptible problems to the architectural design of the system, and yet allows for it to be able to do far more, both now and into the future, is definitely a great idea.And as to the design of the x86 architecture, no one screwed you. It was designed when even 1MB was a *huge* amount of memory, let alone 16MB or 160MB and it was the intent that we would be using an x64 architecture before we hit the 4GB limit of the CPU's design, or so they thought. In fact, Intel *failed* with the original Itanium to gain any traction anywhere but the high-end database server market, and AMD's x86-64 was seen (and ultimately won as the choice for x64 on the desktop and server platforms) as a far better design for both the x64 platform in general, and also the migration of x86 to x64 (because it could run x86 code natively on the CPU without using an emulator, like the Itanic does). Again, you're free to your opinions, but the rest of us are free to look at them and think they're crazy. The original question was answered - it's not the OS (or Microsoft "jerking you off" or whatever you think). It's a limitation of the design of the 32bit architecture, and if you don't get that then no amount of explaining this is going to get you to understand that, I guess. Adding PAE to a system via Windows' AWE API set is something that you can "get around" by simply purchasing a 64bit version of the OS, for the same price as the 32bit version. Same price.

If you are selling the machine, and not just the copy of XP, it's legal to reload the Dell with the Dell royalty OEM XP CD and Dell COA license that is affixed to the chassis. XP is tied to the OEM machine, not the owner - if you sell the machine, you have to sell the CD, but it has a nice converse - when you resell it, you can reload with the OEM license key on the sticker legally. As to your question about the Dell XP Home sticker on an HP, no, that is not legal. You would need the OEM license that shipped with that HP to reload XP on that (unless you buy a retail copy, of course). If the machine is owned by the leasing company, and they have a license with Microsoft that allows this, it certainly is legal. You should talk to a Microsoft sales rep, you can likely get volume discounts if you need to be buying thousands of copies a month.

This is basically what I mentioned in this thread on February 3rd, except I think my approach is more "classic start-menu-like" than what the article mentioned. The article I found actually tells you how to achieve this, and gives visuals. What you described on Feb 3 gives no hard knowledge of how to actually achieve this, just generalities, and lacked any visuals for the readers to have their hand held while doing it. Please do post step by step the method you hinted at. I myself would like to know exactly what you are talking about and exactly how to do it... visuals and all. If you already know the classic menu, you know how to make a toolbar folder and put things in it. If you need a description and screenshots, sorry, I don't have the desire or time to do such a thing right now. You create a new folder, put the start menu folder structure you want inside, then right click on the taskbar and choose New Toolbar and point it at the new folder you created. Look at the Start Menu folder on an older XP/2000 box if you need a reference. It should be easy for anyone familiar with classic to do, as it's quintessentially "classic".