Content Type
Profiles
Forums
Events
Everything posted by dencorso
-
Iron Maiden - Fear of the Dark
-
Since there always is room for improvement, let me please suggest one: @ECHO OFF PUSHD %~dp0 SET Program="C:\My program directory\eps to pdf\epstopdf.exe" for %%A in (*.eps) do %Program% %%A POPD The pair PUSHD/POPD saves the current drive:\directory, before changing to the new one, then returns to it, respectively. So, at the end, you'll be back to the folder you started in.
-
Copy only files that have newer version?
dencorso replied to tomasz86's topic in Unattended Windows 2000/XP/2003
Well, here I am, back to the subject of PETimestamps... When one needs to determine it, what options are there? Just two: 1. Use the latest version of Matt Pietrek's great PEDUMP.EXE console application. This has the advantage it can be used in batch files or CMD scripts, but it requires some tricks because PEDUMP gives just too much information besides the sought-for PETimestamp, so filtering, possibly twice, with FIND will be required... and moreover it is based in a WIN32 api function that corrects time for the user machine's currently set Timezone (and Summer time, if applicable), so that the times become confusing, when comparing results from different users across the world. On the bright side, it does also show the hexadecimal unix time string, as it appears in the PE Optional Header. 2. Use MiTeC's great EXE Explorer (v. 1.0, because the newest v. 1.3 is buggy). This has the downside it's a GUI application, so not usable in batch files or CMD scripts. It also does not show the hexadecimal unix time string, as it appears in the PE Optional Header. They've taken care to display time in GMT (aka Zulu = UTF), although they do not ever mention it (they should). However, they've decided to show dates as "aa/bb/yyyy", where "y" is the year, while "a" and "b" may be either the day and month in this order or in the reverse, depending on each user's machine's settings for the short date format, thereby also becoming confusing, when comparing results from different users across the world. So, neither of the available solutions really is satisfactory, IMO, and that prompted me to write my own application for this, using an unambiguous format for the time and date string, and also presenting the hexadecimal unix time, together with the file name, all this in just one line. And it also supports "*.*", of course! I called it, rather unimaginatively, PETmStp (attached below), and here's hoping it will be as useful as I anticipated it should be. Please do report any bugs found. PETmStp.7z -
Resurrecting a 1999-Vintage Win98SE Machine
dencorso replied to TELVM's topic in Windows 9x Member Projects
Try replacing it in C:\WINDOWS\SYSBCKUPS (if it's not there put a copy of the modded one there), then in C:\WINDOWS\OPTIONS\CABS, and last in C:\WINDOWS. Does it still get back? And, BTW, when hexediting it, take care to replace any unwanted character (for me that meant all of them -- I just wanted to remove the string) by hexadecimal 20 (which is <space>), so as not to change the size of the string. If the size changes windows will see the file as corrupt. -
I'd go for more ram than for faster FSB speed. PC3200 mean 3200 GB/s while PC2100 means 2100 GB/s... while the latter is a whopping 35% decrese in speed, I really doubt if you'd ever notice it, given the speeds of all the periferals, which are *so* much slower. Hence, with a single stick onboard, change "by SPD" to "Manual", and the grayed settngs will come to life, then set the bios advanced settings to the 3-3-3-8 and reboot. Does it boot OK? So far, so good. Then turn it off, and add the other stick. Cross your fingers and turn it on. Does it boot?
-
It seems to me your in to learn a lot! Trial and error eventually wins the day... get yourself lots of patience and do it only if you can see it as fun. Here is a little help: DOS 7 Commands.
-
.CMDs do not work on 9x/ME at all, of course. You must convert them to batch files, taking a lot of care, because many commands have had their syntax, parameters/switches and capabilities upgraded on going to the NT-family.
-
No, it's not! It works like clockwork on 9x/ME!
-
Elaborate, please. I went to WD's site and couldn't find anything about it (then again, it can be just a trivial case of bad Google-Fu, of course).
-
Resurrecting a 1999-Vintage Win98SE Machine
dencorso replied to TELVM's topic in Windows 9x Member Projects
Changing subjects a little, you're aware it's quite easy to do away or change the "Fabricado y con soporte de:" for another phrase not exceeding the number of characters of the original, with a simple hexedit in sysdm.cpl, right? -
The Imposible to remove Windows Security Warning
dencorso replied to Willaraz's topic in Windows XP 64 Bit Edition
Many answers. Try the very first one. -
There is also OPPCOMME, of course, although it's not exactly what you seem to be asking for.
-
All his basis is belongs to us. To become part of this OS, prepare for assimilation! Resistance is futile...
-
Try installing to a VM, then cloning to the real machine. Does it then work?
-
According to the Microsoft Extensible Firmware Initiative: FAT32 File System Specification (Microsoft Corporation, Version 1.03, December 6, 2000, pages 33-34) aka FATGEN103: Of course, as we have seen in this thread, the statement: "This limit does not apply to the number of files in the directory. This limit is on the size of the directory itself and has nothing to do with the content of the directory." is misleading. But the rest of the quoted text makes a lot of sense, IMO. I think so, but only systems bearing the patch would able to find those surplus files, so it probably is not a good idea.
-
Thank you, Multibooter, for the swift feedback! Well, the reason I called the program VRFYPE was exactly this: if it manages to identify a file as a PE file and that file bears a checksum, it can verify whether it matches the true checksum or not. One reason for non-matching checksums is file corruption, but another one is sloppy file-patching... and that's why I had VRFYPE say the checksums don't match, not "FILE IS CORRUPT"... that conclusion may or may not be warranted, since a sloppily patched file may work all right (the patcher having just forgotten - or overlooked - to fix the checksum after patching). I had VRFYPE in mind sometime before the start of this thread, but I only actually had a good reason for writing it because of this thread. However, it's not quite a "CHEKDLL": it's less beacuse it cannot check NE DLLs, but it's also more, because it can check EXEs, TLBs, OCXs, SYSs, MPDs and even files having other extensions, provided they are files in PE format. Now, before anyone can create a true "CHEKDLL", it's necessary to find out how the NE checksums are actually calculated, since MS documentation of this point isn't reliable... and then, there still will remain the unsolvable case of non-checksummed files. In any case, I'll incorporate a tally of how many PE files were checked in the next version. But I think that to cause it to print the name of every file it ignores because of not being a PE file not a good idea, at least not by default, because it'll create too much output, defeating any advantage accrued from supressing the output for non-checksummed and matching checksum files. I think it should report just the mismatching checksum files and a tally of files checked, unless the "verbose" switch is used. To find out how many non-PE files are there, it's just a matter of subtracting the tally it'll provide from the total file number as reported by DIR.
-
Hi, Multibooter! Thanks for testing VRFYPE, your results are very encouraging. I'll try to provide a next version incorporating the suggested improvements soon. I don't think so. I bet those 44 DLLs are NE files, which VRFYPE is ste to ignore. Please do check it: if they turn out to be PE files, then we have a bug, unless they are PE files damaged so as not to be recognisable as such (unlikely, put still possible).
-
Win 2k and Win XP use Win32 (= Portable Executables aka PE files) for almost all system files and applications (*.DLL, *.TLB, *.SCR, *.OCX, *.SYS, *.CPL, *.EXE, *.AX, etc.), and most of them *are* checksummed, so that for those (and latter NT-Family) OSes, VRFYPE does a pretty comprehensive job. Taking the C:\WINDOWS\SYSTEM32 folder of my Win XPSP3 as a sample, there there are just 64 in 2770 files that are Win16. Of course, most of the files in C:\WINDOWS\SYSTEM are Win16, too, so that adds more 26 in 33 files. So, in SYSTEM and SYSTEM32 together my machine has 90 in 2803 files that are Win16 (*.DLL, *.DRV, *.TLB, *.EXE, etc.): that's 3.2%. And there are also a handful of DOS (Real Mode) executables... All in all, I think it's safe to affirm that 90+% files in a Win 2k or Win XP machine are PE Files, and more than that for Vista+ machines. The situation for Win 9x/ME is much less bright than that. Even so, if I were able to produce a companion VRFYNE, to cater for the Win16 files, it'd be possible to even the field somewhat, and it apparently is possible because they should be checksummed too (there is a checksum field in their headers) and MS aparently documents the algorithm of their checksum in KB071971. However, finding actually checksummed NE files (i.e.: those that have a value different from 00000000 in the correct header field) is quite unusual, and, by using those few that are checksummed and bona-fide as a test for my implementation of the algorithm in KB071971, I found out that either I did some gross mistake I cannot yet find or the published implementation of the algorithm *is not the right one*, because it consistently calculates values different than those present in the test NE files' headers. output of vrfyne *.* lzexpand.dll Header Chksum: 80377b2a Real Chksum: db651403 lanman.drv Header Chksum: 2702481c Real Chksum: f1dcd01a mciseq.drv Header Chksum: 7141695e Real Chksum: 3448c449 mciwave.drv Header Chksum: 7cda4a3c Real Chksum: 256b0a7e olecli.dll Header Chksum: d51e6641 Real Chksum: 98cb4cda pmspl.dll Header Chksum: 4959782e Real Chksum: 93dbfb5d sysedit.exe Header Chksum: 5bb2317e Real Chksum: 475db7ca ver.dll Header Chksum: 9539a529 Real Chksum: 2253e723 output of filever /a *.* W16 DRV ENU 2.10.0.1 shp 221,600 08-23-2001 lanman.drv W16 DLL ENU 3.10.0.103 shp 9,936 08-23-2001 lzexpand.dll W16 DRV ENU 3.10.0.103 shp 25,264 08-23-2001 mciseq.drv W16 DRV ENU 3.10.0.103 shp 28,160 08-23-2001 mciwave.drv W16 DLL ENU 1.32.0.0 shp 82,944 08-23-2001 olecli.dll W16 DLL ENU 2.10.0.1 shp 46,592 08-23-2001 pmspl.dll W16 APP ENU 3.10.0.103 shp 18,896 08-23-2001 sysedit.exe W16 DLL ENU 3.10.0.103 shp 9,008 08-23-2001 ver.dll The VRFYNE used for those tests is an "as is" implemetation of the code in KB071971... I just tweaked the final output string format. So, in fact, I had to use a FOR command to obtain the results, because that VRFYNE doesn't know what to do with "*.*", but I've omited that in the report above for simplicity. In any case, the practical use of VRFYNE would be limited, because MS seems to have eventually abandoned the checksums both for plain DOS .EXEs (which I hadn't mentioned up to this point, its the "16-bit checksum" in the quotation below) and for Win16 (that's the "32-bit checksum" below), around the time it moved on to Win32 for good: So I decided to relase VRFYPE, while VRFYNE remains on hold, pending I find a way to calculate de novo the NE checksum. But, by now, I really doubt that much will ever happen.
-
OLEAUT32.DLL 2.40.4522 Windows 2000 SP4 works with no problems on my system. I think maybe you should try it out.I haven't had any apps break or any popup errors I'm sorry I wasn't quick enough to react in time but OLEAUT32.DLL v.2.40.4520.0, with PE Timestamp of 12/3/2007, is actually *newer* than v. 2.40.4522.0, which has a PE Timestamp of 06/20/2003 !!! I've discussed it at some lenght here and here.
-
Get error on Memtest86 - How to solve the issue?
dencorso replied to persson121's topic in Windows 9x/ME
No. I've googled around and I still think his mobo's FSB is 100MHz... that's why I've mentioned PC100 SDRAM. -
Get error on Memtest86 - How to solve the issue?
dencorso replied to persson121's topic in Windows 9x/ME
If new memory sticks (where do one get new PC100 SDRAM nowadays?) gives the same error as the old ones, and you've cleaned the slots thorougly with a soft brush before inserting the new sticks, chances are the motherboard is no good anymore... consider replacing it. I'm sorry. -
HonorAutoRunSetting should also be set, besides NoDriveTypeAutoRun (KB967715): [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer] "HonorAutoRunSetting"=dword:00000001 "NoDriveTypeAutoRun"=dword:000000ff
-
-
The Police - Roxanne
-
You may try: vrfype folder\*.* | find /I "match" if that does not solve it, let me know, and I'll implement the required switch.