CoffeeFiend

Sorry for your loss Kel Take the time you need. WPI users will wait patiently. That would be of poor taste for sure.

Celerons never were as bad as a lot of people put it in the first place. They're cut back versions of their flagship CPUs but they're certainly NOT crippled junk. Most of the time they actually offered great value (almost the same performance for most things, but for a lot less money) The other thing is, "Celeron" by itself means very little (same for their Xeon brand). They had Celerons based on the Pentium 2, the Pentium 3, the Pentium 4, the Pentium M, the Core 2 Duo series and now Nehalem. Performance can vary dramatically between two Celerons depending on what "generation" of CPU they're based on. The Celeron M @ 1.5GHz is based on the Pentium M which is a LOT more efficient (much higher IPC) than the Netburst junk that is the Pentium 4 so it's no surprise it's a lot faster still (clock speed is very similar too). The *only* difference between that Celeron M and the Pentium M it's based on is that it only has 512KB of L2 cache vs 1MB for the Pentium M. Not that I could pay much for such a laptop mind you. Any modern ~$400 laptop completely slaughters it in every possible way, and there are faster netbooks out there as well for even less (based on some of the newer Atom CPUs or the new AMD V-series CPUs). And those come with a warranty, a new battery that actually hold a charge, they have a lot more disk space, they have a better LCD, they come with a newer OS and so on. But hey, if it's dirt cheap (definitely under $200) then why not.

I don't see anything abnormal. The first 6 connections are to a computer on your network called Cindy-PC. The last one is your PC fetching a web page from MSN. Not sure about the 2nd last one (it's getting a securized web page, most likely from MSN too) but there's nothing that looks like you're compromised.

The Celeron M 1.5GHz is almost twice as fast as a P4 1.7GHz, and it also has 4x as much RAM. Easy choice to make for sure.

There's no need for a fancy module or library to do that. Any language that can use any old database can do it natively in a handful of lines, using the ACE OLEDB provider. MS Office doesn't have to be installed either, it just needs the related database driver which is free. Personally, I do this kinda stuff in C#. LINQ -- and its extension methods along with lambda expressions, anonymous methods and other bits functional programming-styled (declarative, somewhat MapReduce-like) code -- makes processing the contents at least 10x faster than using almost everything else in most cases.

Is there a reason why you must always somehow use more than one scripting language of some sort? It really seems to add pointless complexity (a hodge-podge of scripts trying to pass infos from one to another) with exactly *zero* added benefit. There's really nothing batch files can do that you can't accomplish with another language (and often in far better/modern ways), including perl. ^ What he said. ^ Ditto. Well, I've never seen a "Windows shop" that actually uses perl for anything like that (then again, hardly anybody in the Windows-centric world uses perl at all). That's *much* more of a Linux thing, and then again it's more to "glue" the output from actual applications, mainly because the way of doing things in the Linux world is based on parsing text passed by a bunch of different tools (via piping) to accomplish a job, whereas in the "Windows world" when it comes to scripts we have object passing in powershell, or direct manipulation of most things using technologies like WMI, ADSI, COM, etc and that most tools simply aren't meant to work the same way. We don't tend to string together a bunch of tools to do a job but rather have a specialized tool meant for the one particular job instead. And even in the Linux world, you don't often write scripts that use a bunch more scripts (which all do completely trivial things) when you can typically have one small to medium script that just does the job. Honestly, batch files are the last thing I'd be using these days (it's not 1985 anymore and the MS-DOS era is long gone -- I mean, we've had vbscript built-in for over a decade), and while perl isn't bad per se it's not exactly a common choice for Windows admins. The *only* place I've seen it used is guys writing VmPerl to admin vmware machines, but even then that was *heavily* outnumbered by folks using VmCOM (the COM based interface). It mainly seems to add a pointless dependency as it's not built-in, and also far less admins know perl. What you guys are doing (scripts that call scripts that call scripts) isn't so typical. It sounds like your boss is one of those "I only know Linux, so let's try to use everything as if it was Linux" guys (by using brute force and a bunch of ugly hacks). It looks like you're already having quite a bit of "fun" (mainly working against the tools, in ways that pretty much nobody else does), and judging by your posts I don't this is going to change anytime soon so good luck to you (I'm glad my boss doesn't impose such strange language constraints on me, it would feel kind of like juggling in a straight jacket) It would be easy to help if we knew what the actual problem to solve is (we really try to help too -- I mean, like here where I've written 6 scripts in 5 different languages to do a particular job for one guy), but here it just seems like we're wasting time by trying to help you work in a very atypical, inefficient and perplexing way.

Doesn't really matter. The OP is doing something completely different in the first place like he explained in post #4 (using regular expressions). And then again, he already had a working solution that did the file open/read/close, processing, then file open/write/close separately. His only problem was opening the file just once with R/W access, reading from it, seeking back (which he wasn't doing so it was effectively appending) and then writing again -- which as-is was bad idea in the first place: if your new content is shorter than the old one, then you end up with junk (contents from the old file) tacked on at the end of it (I tried to explain before that he had to seek back, and that this often wouldn't be sufficient to solve the problem too) So changing language without any real technical merits or benefits, not using regular expressions, or adding specific logic that's completely irrelevant to the problem and such? Ok, whatever... But this doesn't actually address his actual problem in any way: reading from & writing to the same file by opening it just once. Not mentioned (because he hasn't discovered the next problem that would arise once he gets this working), but it must be able to "shrink" the file too if necessary. There is a way to do exactly what he's asking for (and in perl, still using regexp's and all), not that it really offers any actual benefits vs opening it twice IMO: open the file with RW access (using "+<") read its content into some variable storing the size/length of the said "old" contents in a variable do the processing on it just like before seek to the beginning of the file: seek(FILE, 0, SEEK_SET); (what he wasn't doing after reading from the file, thus making it append) write your new content if the size of the "new" content is less than the size of the old contents previously stored, then call truncate(FILE, newSizeHere); on it (discarding the extraneous bytes) close the file Not that it's any better than his current/old solution IMO. He's seemingly trying to do that for performance, but saving a file open/close operation (just getting a file handle) vs the added seek & truncate operations... There's basically going to be no measurable difference between the two (way less than 1ms difference*). I'll much sooner use the code that's more solid (proper error handling for starters), better written, better written/documented, easier to understand, more versatile/reusable, is better tested (e.g. has good unit tests), is easier to use, will be better supported in the future, etc. Either ways, I think this is completely pointless in the first place (and this is why I have not/will not bother spending the 5 minutes to write code that does exactly this). This particular problem (replacing text using regular expressions) was already solved 35 years ago by AWK (using sub or gsub). He's just reinventing the wheel, and poorly at that. * Edit: allen2 sure has a good point there too (see post below). I mean, if this executes once in a while it's pointless trying to spend hours of coding to shave off a few microseconds of execution tme. But if you're going to use this in a situation where it actually matters (like running it a billion times in a loop) then a scripting language probably isn't the best tool for the job in the first place (you'd want something compiled for sure -- and probably make the tool iterate through the files instead of running it a bazillion times). Then again, sometimes regular expressions are also overkill (or not the best pick) for the job and something like a Boyer-Moore search might be faster to find the parts that need replacing. I don't personally bother much with optimization (assuming the code is already half-decently written) until it actually becomes a problem (then you profile and see what needs to be optimized -- the file I/O, the time spent on string ops, the time spent spawning the same process repeatedly, etc -- and then address that particular problem)

+> truncates the file (makes it a 0 byte file) so it's hard to read from that for sure. It will also create the file if it doesn't exist already (either ways, you're getting that 0 byte file) +< is read/write. However, after you're done reading the file, your "position" is at the end of the file, so if you start writing then that's where you'll be writing from -- essentially appending (very much like it would using any other language in this specific scenario). If you want to write from the beginning, you have to seek to the beginning first. Not that I would do it this way, unless you're at least 100% certain that the content you'll be writing will never be smaller by *any* amount (even a single byte), because then you'll have garbage appended at the end of your new file. Your best bet (again, for any language -- so long as the files aren't huge) is to first open the file, reading its contents into some sort of variable, then closing it. Then you do whatever processing it is you wanted to do. Then you finally reopen it, this time for writing, *truncating* the old file, write the new stuff to it and close it once last. Or you can also rename the old file as a backup (if you want one), and create the new file. That's much more fool-proof in most cases.

Batch files don't do GUI, it's tech from the 1980's. vbscript, a far more modern (then again, we now have powershell too) and powerful tech can though. Your best bet is getting rid of the batch file part, and just using vbscript. Whatever the batch file does, vbscript (and pretty much any other scripting language) can easily do as well. Even using something external from a batch file (to popup a messagebox or similar) is kind of a pain anyway (e.g. getting result using errorlevel)

In that case, you don't need a gaming PC at all. Almost any computer will do just fine (so long as it doesn't have the old Intel onboard video). Even my kids' ~3 year old machines with onboard video (AMD 780G chipset i.e. a Radeon 3200) can easily do over 30fps in UT 2004 @ 1280x1024. A Radeon 5450 would be plenty fast for sure.

Assuming the "flat" design you have (i.e. using a single database table) it would be quite simple. Definitely within the reach of a beginner who's open minded, willing to learn and try new things. Access is meant to be used by mere mortals (regular old office workers without advanced training of some sort). If you keep it simple enough, you could make something half decent in a few minutes. There's even wizards to help you do most of the job (it'll generate the entire form for you, leaving mostly minor tweaking or cosmetic changes to do) Like I was saying, filtering in Excel (as a substitute to a DB) isn't so great, and a LOT of users won't actually see (and often don't understand) the tiny flags that appear in the column headers when you're filtering. Then they just think it's broke somehow (or that the part doesn't exist/isn't available, etc). It's not so great for searching either (just filtering). VBA can be a pain with all the security settings these days. It's often disabled for security reasons (thanks to old macro viruses), it requires confirmations to somewhat scary warnings that often scare users (so they leave it disabled and then it doesn't work). VBA can be powerful for some things, but it's a lot more complicated than just using access here, and it's not exactly a great development environment either (starting with the language itself or the tools). Access would let users type in text to search for and what not on a simple and user-friendly form. No security warnings or anything weird/unusual. No programming required. That's why I suggested it before. Access is meant precisely for this kind of usage. Considering all options, excel + filtering and/or VBA is about the dead last option I'd pick myself. Personally, I make a client app most of the time (C#/.NET FW 4/EF4/LINQ/SQL Server/Reporting Services) or a sometimes an ASP.NET MVC web app (same stack mainly), but that's quite a bit more complicated than just using Access.

Anything will completely slaughter that regardless of what you pick That won't get you anything one would call high-end, but you can build something pretty decent (for gaming) still. $539 + a video card, so that's more like $700+ ($741 with a 6870). For modern games, you don't quite need a super fancy high-end CPU, most of the time your bottleneck is the video card, so you have to spend a good amount there. The most high end CPU combined with ghetto video will make for poor gaming performance. A really slow CPU (something old) would hurt performance for sure but you'd almost have to go out of your way to buy something way too slow. You kind of have to balance both based on your budget. That list is from 2 years ago, so I wouldn't waste my time with it. In 2 years things can change quite a bit (completely new lines of GPUs, new price points, etc) Out of $500, I'm not sure I'd manage to get a fancy i5, a decent basic motherboard, 4GB of RAM and a video card worth getting, for example: Intel Core i5-2300 $185 MSI H67MS-E43 motherboard $110 G.SKILL 2x2GB DDR3 1600 (@1.5v) $48 That so far leaves $157 for a good video card which could be OK, but then you need a PSU and a hard drive too... Even going with a i3 it would be sort of difficult. Say, if you pick a $125 i3 2100 -- their most low end offer for their current socket (dual core obviously) instead of the i5 then you have $217 left. Then you get a good quality but basic PSU, like a Antec Earthwatts 380W 80+ Bronze for $40; you got $177 left. Then a fairly basic 500GB SATA hard drive at like $40, you got about $135 left for a video card. That will get you an alright card like a Radeon 5770. It isn't bad, but that's about the the slowest card I'd consider getting. I wouldn't quite call it a gamer's dream. Long story short, it's compromises all-around, and you don't get an incredible gaming rig. Then again, if you can spend a bit more on a fancier card then you can have something quite nice (it's just hard to get it all for $500) If you pick AMD, on the same $500 budget you could get: Athlon II X3 450 for $80. 3 cores, and still plenty fast for all but the most demanding games (and pretty much anything else) ASUS M4A78LT-M motherboard for $70 (there's plenty more within $10, lots of choice) the exact same RAM and PSU, and a similar 500GB SATA drive around $50. Without making compromises, you still got $212 left for a really nice video card (and possibly a larger HD or fancier CPU) You could pick say, a significanty faster Radeon 6850 (and slightly OC'ed, it's way better for gaming than the 5770 e.g. twice the FPS in FarCry 2 & Metro 2033 both @ 1920x1200) around $175 (you'll also get $20 back in the mail sometime and a $10 gift card with it) and still have money left for an upgrade to a quad core CPU like a Phenom II X4 840. There's simply no need to compromise, cut corners or skimp on anything here. If I had extra $ to spend, I'd consider a slightly beefier (and still good quality) PSU, a bigger HD, a faster GPU (6870, 6950) so you could still have something that competes with the i5 even on a bigger budget.

I have yet to find an alternate PDF reader that fully supports PDFs. All of them seem not to support some features (later versions of PDF, or not working with 3D PDFs, or not being able to turn layers on or off, or the colors being messed up on CMYK PDFs or what have you). That, and a host of other annoying issues (fonts looking like crap, printing-via-bmp-file-generation, etc). I've tried lots of them (Foxit, PDF-Xchange, Sumatra, the one from Google Chrome, etc) and the only one that "just works" is still Adobe's. If you care about opening plain vanilla PDFs on an older computer then the alternative options might be useful. If you need more advanced documents to JustWorkTM then Adobe Reader is pretty much the only game in town.

I haven't seen that kind of problem on any computer so far, and I don't go disabling services like that either. Try running the performance monitor (search for it in the start menu, or run %windir%\system32\perfmon.exe /res directly). Go to the disk tab, and see which process is hitting the disk so hard. You could also do this using performance counters.

There's your problem. You want a database, but you use a spreadsheet instead. Completely wrong tool for the job. There are way to filter data tables manually in Excel but that isn't quite what you're asking for, and it's still the wrong tool for the job regardless. I'm not a big fan of MS Access but it's a far better tool for this (it's also part of MS Office)

There are plenty of newer keyboards that use nicer mechanical switches than the ancient model M IMHO. More of a "click" than a "clang!" sound, and requires a bit less of force too but you still get the awesome tactile feedback. I'm most likely going to buy a Das Keyboard this year. Nice cherry MX switches, USB goodness, but still no "bend" in the rows alas...

Keyboards with mechanical switches FTW.

That's how I like it personally. In fact, the very first thing I do to machines with a bunch of crappy small partitions is blow them all away (including recovery partitions) and recreate one nice big partition. No matter how big they make the C: partition I'll run out of space. OS + number of large apps + pagefile + temp files + large user profiles + current downloads and working files just takes a LOT of space (nevermind if you want to have some games on there too). And those other small partitions usually end up being mostly unused/wasted (while struggling to make space on C:). Of course, videos, music, vmware images, disc mages, installers and what not end up on other drives. Most decent backup solutions will let you save the backup directly on the drive you're backuping, on an external hard drive, on a network share or FTP server (and other network-related means), on USB devices, on DVDs, etc so it hasn't been a problem for me.

No idea how you'd go about SANs, but as far as the servers go, I'd have a peek at the SerialNumber property of the Win32_BIOS WMI class. It just might return what you're wishing for.

It certainly is a lot faster than most dinky NAS solutions. However, the direct attached solutions are all faster, and a *LOT* cheaper too. You can get a similar 4 bay DAS solution under $100 ($90 - 15% so around $75), whereas the Thecus N4200 is $679.99 at newegg, and the QNAP TS-459 Pro is $899.99 -- plus drives of course. That's a lot of dough for a simple Atom system with 4 drive bays IMO.

That's pretty much it. It uses the drive's native interface, and it's faster than pretty much any drive can handle (save for some high-end SSDs), whereas USB2 is quite a bottleneck. The downside is, not that many computers have a eSATA port yet, so having eSATA only might somewhat limit your options. If being able to use it everywhere (lowest common denominator, if you will) isn't much of a concern, then this is a great solution. There are also some direct attached storage enclosures (to use many drives, sometimes in RAID) on a eSATA port which are fairly inexpensive too. Addon controllers with eSATA ports are dirt cheap as well. A lot of USB 2 enclosures plain suck. There's some of decent quality, but the vast majority don't really have much in terms of cooling (they don't expect you to do much with it basically) which also affects reliability quite a bit, and on many enclosures, long transfers tend to slow down dramatically (I've seen some transfers of a few GB start at 30-something MB/s and drop below 5 by the end). With non-native interfaces like USB, there's a "bridge" chip (which translates the requests, if you will) which can also be a bottleneck and overheat if you ask too much of it... I wouldn't say it's that complicated but it's by far the slowest option, unless you're willing to pay top dollar -- and at that price point you can usually do something FAR better/faster yourself (FreeNAS, etc). The main point is supposed to be ease of setup over a "DIY" NAS solution (again, like FreeNAS on your own box). Life's too short to be waiting after most of these devices. USB 3 will probably end up "killing" eSATA in the long run. It'll be super fast when people have USB3 ports (as much as eSATA for traditional drives basically, as neither is a bottleneck), but it's also backwards compatible with any old USB port so it also works everywhere -- best of both worlds. USB3 controllers are also inexpensive (like eSATA cards). So this is a great option, assuming the enclosure doesn't suck of course... By the time most people have USB 3 ports, I don't think there will be much of a point to eSATA ports anymore (kind of like how we see a lot of firewire ports on the current mobos now that we've mostly moved on). eSATA may still be a good option until that day. Newegg seems to have a LOT of USB 3 enclosures. Not all enclosures are equal though, and some brands tend to be alright (vantec) and others consistently suck (bytecc -- they seem to reliably fail). Lots of such solutions are listed in different categories on newegg. Like this unit for instance ($130 for 4 bays, RAID, good cooling, has eSATA controller, etc). You may even find some open box deals, or inexpensive solutions if you already have a eSATA port. Just look around

That's actually pretty well matched. Spec'ed voltage is within 5% of what the laptop's specs states, but it can vary by ± 5% or more (not bad, the SMPS will simply compensate by adjusting its PWM ratio), and it's able to supply more amps than it needs (it's just more capable than it needs to be, it's not harmful or bad in any way)

It's not a matter of chance (nor "my" windows -- it's a very typical/vanilla install), it's just how it works (Vista would mostly do the same, and Win2008 series too). If anything, it's not shortcomings of the OS but of your script i.e. relying on optional features that are turned off by default, killing processes which you probably shouldn't, etc -- instead of standard ways that work just fine & reliably (like using the .Quit() method of the Window objects instead of killing explorer). You do have to keep such things in mind when you program or write scripts -- changes between different versions of the OS: security changes, varying locations/paths, different locales and so on (and everything that could go wrong, because it will) Good one. You posted something 3 months after the question was asked, so most likely not (you're basically wasting your time, unless you're doing it just for fun) I haven't tried your last script, but I can already tell it's not looking for unique entries yet (i.e. if 2 explorer windows are opened in the same location, just reopen it once, as per the request in post #4), nor doing anything against explorer being opened in other places (like network connections) either. You're slowly getting there though (sorting + delay while reopening added)

Well, that's a step in the right direction. But: -killing explorer.exe is still problematic. On Win7, you lose the start menu + taskbar + notification area -- they don't return on their own (you just get to wait for 5 seconds while staring at nothing), even if other windows reopen/script doesn't crash. You have to ctrl+shift+esc, then manually run explorer.exe by hand to get them back after running the script (it's easier to just use the .Quit() method of the Window object themselves -- it saves you from all this hassle) -as per the user's request (read post 4), you still have to sort windows alphabetically (using _ArraySort() or something), and to not reopen duplicated entries (iterating through the list, keeping only unique entries), while not forgetting the required delay between opening each window (otherwise they'll reopen in a random order anyway). That was the whole point of the script (not just closing them all then reopening the exact same thing blindly which basically accomplishes nothing) -should any explorer window be open in anything else than a "valid directory" (for example open network connections by running ncpa.cpl -- there's plenty of others though) before running the script, then some windows may not be reopened at all (or partially, depending in which order it sees them) You're getting there...

Not sure what for, or in what language. So I'll assume VC++ and doing nothing else besides lock/unlock... #include <windows.h> #include <iostream> void main() { HANDLE hHeap = GetProcessHeap(); //or HeapCreate if(hHeap == 0) { printf("GetProcessHeap error %d\r\n", GetLastError()); return; } if(!HeapLock(hHeap)) { printf("HeapLock error %d\r\n", GetLastError()); return; } //do something with it... if(!HeapUnlock(hHeap)) { printf("HeapUnlock error %u\r\n", GetLastError()); return; } } Edit: looks like Glen9999 beat me to it, and with nicer code too (and it's unicode...) Oh well