PiqueABoo

Directly is not quite the right word. Pretty much everything we care about is a userland app and they use virtual memory i.e. it's indirect. The best fit for your concept is AWE where some greedy app needs truckloads more virtual memory than can be addressed with 32-bits, so it gets the OS to swap the extra memory it needs in and out of that limited virtual address space. Application code to manage this aside, this is essentially done by moving pointers to physical memory pages i.e. large chunks of data are not being copied from one region of memory to another. 64-bit does save seriously memory hungry apps from having to do that kind of faffing around, although AWE memory may still get used because it never gets swapped out to the pagefile.

Nope that was yesterday, but alright I'll do it again.. ;b If it's so bad why has PAE been recommended for Exchange 2K3 for a few years?

Because? I thought (provided the hardware supported it) Windows Servers supported remapping the I/O reserved memory.

"Compact" is for mobile devices.

Yes, but only in the approriate context. In principle (and practice for me) if it's a single domain forest a) GC +IM does not matter, b) it's good to make your DCs GCs.

Oh you don't need to.. lots of 100Mbps workstations simultaneously grabbing lots of big files from one 100Mbps server is going to be slow with or without CC4. They needed a better switch when they first got CC3 back whenever. Uhh? They had a CC3 system and chose to spend £££s on a CC4 upgrade which won't make much difference to the user's desktop experience, as opposed to getting a £2-300 switch that would immediately improve network performance? Or was this a recent CC3 installed as a stop-gap until CC4 was ready?

I had VS2K5 fired up for something else so I just quickly threw an Main() and a few brackets at the bottom of your code excerpt and it built with no complaints.

Given the "using" line interop just works for me (do have SDK, do always put ".dll" in there but I'm not convinced you need to, don't have interop it in the references). What does VS actually complain about?

Same principle here, but I usually send an ARP to the target IP to check for signs of life (which works nicely provided your targets are on the same subnet) Have thrown the GetHostEntry/ByAddress code away now, but must have been catching. Didn't notice that lag but it's got to be teensy compared to an RPC timeout.

Cannot compute.. cannout compute.. ::head explodes:: This aspect is regular Microsoft WAIK technology. To make a USB that boots a PE image you need to add a Vista boot sector to the USB and then throw a standard set of folders and file on it, including the WinPE2 *.wim file. You can do the boot sector part on Vista, If on XP/2K3 you can use the MS tool Bootsect.exe. All of this just works. The difference for CC4 is that they provide a custom version of a PE *.wim file (that you may have added drivers to) and an XML file with some parameters for the RM build app that runs as soon as PE has loaded. You can copy those with Explorer. In short you don't/didn't need RM to build CC4 boxes via USB. Not sure why they wrote their own utils, but perhaps they're more friendly. That XML file is why you can't take build CDs to other sites. It would have been nice if the build app got that from the network (chose one from a list). Apart from saving making CDs, it would also mean that PXE builds, yet more regular Microsoft WAIK technology, would work.

That's fine.. I've got VS on a PC and VSE on a laptop and having written lots of seriously geeky code there a) are no projects I can't pick up and move between them, b) is nothing I've needed to do that I can't do just as easily on VSE.

Oh you do that everywhere when you need to, but in this case a) the DNS service running on the same box is authoritative for my queries, b) I only want an answer from DNS (and I want it to be correct!), c) there's not enough mileage in it to justify coding threads and locks etc.

Doh! Answer: Swap the last two bits around: dnscmd /recorddelete example.com. fred A 192.168.1.99

Assume a DNS forward zone "example.com" contains two RRs for the same host e.g. first one got there via the normal NIC, the second when connected to the LAN via it's wireless NIC: fred A 192.168.1.27 fred A 192.168.1.99 I can't make dnscmd delete just one of those records. This is what I'm trying: dnscmd /recorddelete example.com. fred 192.168.1.99 A But it deletes both of them. So, does anyone know how to make dnscmd.exe just take out one?

Haven't done reverse DNS lookups on Windows for a long while and just found out the hard way that it can be a pain with dotNet and the experience is worth writing down: 1) Use an older function like Resolve() and you get told it's 'obsolete' and you should use GetHostByAddress(). Do what you're told and you may well hit this problem: MS Connect link 2) Either way your code may end up hanging around a while if the IP isn't in DNS. Presumably it tries asking whatever is at that IP address for it's NetBIOS name, and if that box isn't switched on eventually gets around to timing out. YMMV but I didn't want the latter. 3) So I gave up and went and found a 3rd party DNS resolver dnDNS and so far that works just fine.

Never used it, but this sticks out a bit: My.Computer.FileSystem.GetFileInfo "My Computer" could be a problem considering the file is on some other computer. Get rid of that and try it the System.IO.FileInfo way bizzel mention back in March.

AIUI current live CC4s are all field trials so "how it runs" now is not necessarily related to how the official release will run. ::touches wood::

Yes.. but you've got a dual homed DHCP server, whereas I've always thrown everything on one virtual network (in most cases that has been VMNet8).

> problems with RAID controllers < Hmm.. haven't seen very many, but some variations of RAID controller failure can be stealthy and extremely evil. > whole domain is botched < On your network there's a central database called "Active Directory" that holds all the information about the Windows "domain" - that's info about the user accounts, the computers, who is permitted to do what and so on and so forth. That database is critical so rather than keep just one copy on one server, it is almost certainly replicated to other servers. Unfortunately it is possible for broken data to get replicated, so those multiple instances of the Active Directory database aren't much use. If that had happened I might be caught saying something like the "whole domain is [something rude]!"

> CentOS with Xen Fails the Windows host requirement.. - Had a very quick play with XP VB1.6 host and a VMW6 virtual XP disk.. had problems getting keyboard input to it and it freezes part way through the Windows boot menu countdown. Other than that I was pleased to read somewhere in the manual that it emulates the same NICs as VMW e.g. PCNet, e1000.

Comtemplating and about to try using Virtual Box 1.6 OS edition (free) instead of VMWare 6 WKS (not free). Host will be Windows XP and guests will be Windows XP, 2k3 etc. Want to use existing VMWare VMs and snapshots are a key ingredient. Has anyone already compared them in this scenario and have any comments, tips etc.?

How so? Was this a new Exchange and (presumably) you had umm.. hiccups with them doing the relaying in and out? Guess this might have crossed your mind by now, but **wherever possible**, my strategy for seriously messing with school e-mail is to overlap i.e. the new system gets a new domain name (often a none sch.uk one they've already got) so they have both running in parallel for a while - admins can fully test and get up to speed with the new one, and switch when it's working perfectly and they're happy.

> I'd hardly call Debian a vendor, more of a "bundler and packager". You read my mind. Had counterparts who did the unix dev protesting a few times about folk "gluing a few things together with a bit of script and thinking they're proper developers.." only with a bit more uhh.. vim. They all worked on Solaris and despite the short haircut I had a Solaris x86 2.1 running INN for a few years, but not sendmail - stuck with mercury/Netware, later post.office/NT 3.x. > If it's anything like most of the "technical" mailing lists out there, the signal to > noise ratio is very low Long time since I subscribed to their lists, but they were a bit more annoying than most and I lasted maybe a year decreasingly wanting to be helpful. OpenSSL must be about 10 years old now... just can't imagine wanting to stick with all that repetition for that long. > he did consult the open-ssl dev mailing list That was an essentially anonymous "When debbuging applications that make use of openssl using valgrind, it can show alot of warnings" and the advice they got in that context was fine. It was a far cry from say "I'm a package maintainer for for X, here's a patch I've made and next week I'm going to roll it out to zillions of users - any reason not to?" A lot of clueless ankle-biters running around saying it was really OpenSSL wotdunnit (because of X, Y and the 'consulted" thing), does not make it true.

The KB that appears to be about this is here

> One should not blindly trust compilers or in this case valgrind warnings One should understand what valgrind/whatever warnings really mean e.g. "oh look here's X" is not the same as "oh look, here's X and it definitely is a deadly bug that absolutely must be eliminated at all costs". Kind of thing I thought anyone who'd done much compiling et al learnt a long time ago. I've certainly got enough code that would die horribly if anyone was rententive enough to try and make all the warnings go away. > not having the right resources, ie people with the necessary skill, to do the job. > This doesn't mean they shouldn't try Trying is fine & I'm all for it, provided the triers have a real job to do and factor in the consequences of failing. I spent some time with the OpenSSL source for win32 builds in the crypto embargo days and unless it's had a makeover since, you'd be insane to touch 90% of it, especially anything concerning critical-to-crypto randomness. I had a good reason to fiddle e.g. making it build at all. Why anyone would want to (presumably) "improve" it is completely beyond me. > Debian did screw up here in one regard No they just screwed up. Here's a bit of Ben's comments I didn't include the first time: "the Debian maintainers, instead of tracking down the source of the uninitialised memory instead chose to remove any possibility of adding memory to the pool at all". As in they chose the wrong fix for that warning and caused some significant collateral damage. An out and out mistake... baby and bathwater.