Glenn9999

Okay, this catches about 3/5 of it in the testing I've been doing. But not all of what I was looking for. The initial user name it requires you to enter, along with the name and organization (which I put "Your Name" and "Your Organization"). The user name is easy enough to go in and fix, but I'm not sure on the other two. Basically I want to get the copy of XP to be as "virgin" as possible for the buyer and not have any of my stuff in it.

I'm sure I'm not looking for the right strings in searching for an answer to this, but I'm looking for a way to get it so I can put a copy of WIndows XP on an old system I'm looking to sell, get it patched up, drivers on it, and all that, but leave the identifying information off of it at least until the buyer gets to it. Is there a way to do this, or is there a different way to handle this?

For those that are interested, I ended up with this one. Basically the Nvidia card in the same class as the ATI one listed (according to my research), because it supports VGA and I'm not ready to spring for a new monitor yet. The copy of Deus Ex picked it up and ran with it (given it is running DX9 drivers). The DX10 drivers will have to wait until the OS upgrade gets done. Running very smoothly now with all the graphics packs installed at the highest resolution. Quick question #1: I'm not really noticing much of a change for other graphics oriented things (flash games for instance). Is there stuff I need to reinstall so they'll pick up the GPU? Quick Question #2: I notice the card supports HDMI, which means I could probably plug my flat screen TV into it. Any experiences in doing that, or even letting your regular TV double as your computer monitor? Or are TVs generally too crappy to work well as monitors? Basically other than that, my computing is fixed until I can spring for the next set of upgrades.

Thanks for the suggestions.

Thoughts on the machine question? If I order the vid card, the order will likely include a copy of Windows 7 as well - will that machine handle Win 7 alright or will I be wishing for an upgrade anyway? Any ideas on what that should be, at a reasonable price point (main concern being what mainboard).

None in particular. The only thing that would interest me is older games that I took an interest in but couldn't run on the older system for whatever reason that I can get at reasonable prices. For example, Deus Ex: Human Revolution (if I can get it free of the DRM known as Steam, no active internet connections here for gaming). But the main projected potential use would be blu-ray and H.264, along with higher-end flash games, which dog on the new system. Ancillary interests in a new system would involve having features that I could program for and use that I have interests in (for instance, dynamic frequency scaling).

Since this post has all the details (namely specs for both computers) for some questions I want to ask, I decided to necro it to save time. The person I built this system for wanted something more portable, so I ended up taking the opportunity offered me and acquired it. So I have both computers. But I need to downsize since I don't have any personal need to run both computers. People might remember the video card thread I made regarding the Athlon XP 2000+. That's still a valid concern, but doubly more so with the new system (specs in #15), since I built it more as an Internet surfer than a general computer capable of games and high-end video, consistent with the needs of this person. Thirteen year old Deus Ex looks like crap on this system, and that's saying something. Needless to say, old computer is running that. So...suggestions? I've been literally completely out of the hardware side of things for the last year and a half or so, so I can't really comment on the new stuff that's out. I can obviously research and locate a video card for the new system and be okay with that, but is the reasonably priced newer stuff worth enough of my time that I should drop both the systems, especially since getting into Windows 7 would be a consideration in the planning? Should I go portable myself, would what is reasonably available run about anything I could want? Again 2-3-5 years down the road?

Maybe it is, because like I wrote above, I got it implemented. But I have no special scroll origin icon like Internet Explorer does. That's the point behind this post. What do I need to do to get one?

I managed to get Reader Mode (*) implemented for an application of my own. The only thing I haven't managed yet is to get it working exactly like Internet Explorer/Firefox, where it pops that particular icon down where you middle click. Anyone have any ideas on where I can find it in the system? It should be in a relatively standard spot if it's been in since Internet Explorer 8 (and probably before). But if not, is there a good place to download one (preferably license-free)? (*) - I had to research a ton to figure out that the particular feature was even *called* that. Middle click on an application that supports it, and it picks a spot and then you scroll the box you're in simply by moving the mouse. Clicking the mouse shuts it off.

Thanks for the references. The more I look at it, the more it looks like that I need to just write more of the main part in assembler (if I can). Meantime, I got other things I need to get done (like yesterday, I got something that will compare a folder of files against a text file list (like a WUD UL or one from my downloader) and point out the files that don't exist in the text file list. Basically a "get rid of all the old patch files" function.). Thanks again for the help and hope what was posted here was useful to those that downloaded them.

Got a look at it. Can't say for sure the rest of it is good, but the MD5 part looks relatively standard coding. If there's much appreciable difference from different good implementations (i.e. nothing completely stupid is done), it's probably going to be from the degree of quality of the assembler/compiler used (best being full ASM of course). To that end, I do notice a small speed overhead from UPX-packed executables, so what you'll end up with will be *slightly* faster if it's not UPX-compressed.

FWIW, I just tried this one on Machine 2 with a 734,003,200 byte file (as all the other ones). 3824ms. Some of that I'm sure is the fancy progress indicator, but I'm sure a lot of it is that the algorithm is just the main stock one with no optimizations whatsoever. Edit: In searching, I think the "Md5sum" name is pretty standard because that's how it's appeared in Unix/Linux, etc. That something is named that is probably not indicative of whether it is a specific version of code or not, since just about any implementation is probably being considered as a OS candidate or a clone/replacement/whatever. Edit2: dfso.exe on Machine 2: 2796 ms. My stock MD5 implementation, no optimizations whatsoever: 5312 ms. Just interesting to compare.

If it's the same MD5Sum I looked at up above, then the real source wouldn't be too useful because it's just API calls, wherein the real work is happening. Not really thinking Microsoft will release the source to that. Though it might be quicker to call those instead of calling the supported API calls to do the MD5 (which the other exec I posted uses). Edit: Just did some timings myself. YMMV I suppose.

Cool. So I'm not dreaming on my benchmarking. Of course, I spent a lot of time trying to get it to run quicker. Usually, though, to match what Microsoft has done is pretty good since I'm sure they spend a lot of time on their implementations as well. The problem comes in thinking of ways to improve things (along with reading and finding those standard ways) since Microsoft has many more minds at work. The only thing I could think of after I posted that was to optimize the memory move, and I ended up equalling FCIV after that (on my machine here). But there's the issue of size there, too. I think, though, most people have walled out the MD5 algorithm in terms of that and I would expect Microsoft's work to be representative. SHA-1 is another kettle of fish, though. I have a non-API IA32 implementation of that here that beats FCIV on IA32 machines by about 200ms on similar size files, but not on SSE3 capable machines. These kinds of algorithms are great illustrations of understanding exactly what you are doing with programming and spending time to do things both right and efficiently. Edit: Something I've often found is that code size is often not very reflective of execution speed. Sometimes it is, but you might have to do something to get speed (e.g. unrolling loops or inlining code) which will increase the code size and ultimately increase the executable size. The ironic thing with MD5 is that the most effective change for speed that I found increased the code size by about 2K. The reason for this should be easily seen in looking at what has been posted above. Though I might get my stock MD5 implementation and see what the executable size is, just for fun.

I went ahead and got my non-API implementation of MD5 and posted it. Tested it on a Windows ME VM. Worked. Put it on a good diet between some changes (along with UPX compressing as I have been). Did the same dietary changes to the other file, reposting that, too. For the MD5_file one, all you need to do is put the file name you want after it. Works the same as the other one for output. Still thinking on how to handle error-trapping the API calls on hash_file. (Files Pulled)

Here is the effective source I used for the *supported* API calls in Delphi to do an MD5 hash of a file. The source in the exec I posted is very close (but a little more generic to call the API with different algorithms). Probably something wrong with the API calls related to what is available on the OS. They should exist or you'd have real nasty errors. I don't do a lot of error-trapping on the API calls (interest of size), but that probably should get addressed now that I think on it more (SHA256, SHA384, SHA512 are only available on Windows XP SP3 and above). But like I wrote above, I have a (relatively good) non-API implementation of MD5 I can throw into an exec and post which *should* work on any 32-bit Windows OS.

FWIW, did a little work myself. Basically a pass-through to the API, but had the CRC32 and Adler32 on hand so threw them in too. Trying to find if I miss algorithms that the Windows Crypto API supports, but I'm not sure I did. Hope it helps someone out sometime.

Okay, probably not much to worry about then if there *is* an option. As for the script, probably because it's assuming a string is getting passed somewhere and adding characters. Hard to know though.

All I can tell you if you have that background is just start reading references and start reading code. If you use VB, you'll get the Delphi Form designer easily enough (I literally had almost zero learning curve there). Other than that, try looking at http://www.delphibasics.co.uk/ to get a good start on the syntax.

If the API functions aren't there, you'd have to supply them yourself (which isn't *that* hard). Of course that's going to mean the EXE will get bigger, but again it depends on what exactly you're looking for. I don't know if FCIV works in 2K or not, but if it doesn't, like I said above I can always post something that should do MD5 on any OS that'll do 32-bit executables.

Yep, ASM which direct calls the MD5 functions in the API (MD5Final, MD5Init, MD5Update in ADVAPI32.DLL).

FWIW this is what the API calls look like when you use Delphi. Hope they can be adapted to VBScript. function MD5_File(infile_name: string): string; // Create digest of file with given Name const bufsize = 65536; var infile: THandle; inbuffer: pointer; amount_read: longint; cbHashDataLen: Integer; Digest: TMD5Digest; hProv: TCryptProv; hHash: TCryptHash; begin GetMem(inbuffer, bufsize); infile := CreateFile(PChar(infile_name), GENERIC_READ, FILE_SHARE_READ, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL or FILE_FLAG_SEQUENTIAL_SCAN, 0); hHash := nil; hProv := 0; CryptAcquireContext(hProv, nil, nil, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT); CryptCreateHash(hProv, CALG_MD5, nil, 0, hHash); try ReadFile(infile, inbuffer^, bufsize, amount_read, nil); repeat CryptHashData(hHash, inbuffer, amount_read, 0); ReadFile(infile, inbuffer^, bufsize, amount_read, nil); until amount_read = 0; cbHashDataLen := 16; CryptGetHashParam(hHash, HP_HASHVAL, @Digest, cbHashDataLen, 0); finally CryptDestroyHash(hhash); CryptReleaseContext(hprov, 0); end; CloseHandle(infile); Result := write_hash(@Digest, cbHashDataLen); FreeMem(inbuffer); end;