jaclaz

No need to ban you on request, simply forget your password. jaclaz

It means that some specific "apps" (let's call 'em "programs", OK? "apps" are the things - with feathers - on the Microsoft Store) are (easily) scriptable/automatable other ones need anyway user interaction. For these latter programs, all you want/need is a batch file running their setup. For the former programs there may already be known available scripts, tricks, methods, etc. So - example only - if you ask: How can I automate the install of 7-zip right after the installation of XP? You might get valid, specific answers (or you may be told that you cannot, etc.) Right now you are instead asking: How do I install *any* app program right after the installation of XP? Which will get you either answers like "it depends" or more plainly stupid answers, likely to not actually solve your problem. However there is a "generic" (and hopefully non-stupid) answer, which is "use RunOnceEx (or cmdlines.txt, svcpack.inf, and GuiRunOnce): https://web.archive.org/web/20080724013742/http://gosh.msfn.org:80/using_runonceex.htm https://web.archive.org/web/20080323172855/http://support.microsoft.com/kb/232509 jaclaz

Getting my popcorn and taking a sit on the couch, this is gonna be fun to watch ... jaclaz

jaclaz

Good. if needed I can extend the Pitchers and Batters parsers to parse the "rest" of the data, So, for pitchers (let's take the Jeff Ballard example) this is not correct: Since in other fields were used "words" the data should be: Next 14 are stat based data: 12 00 08 00 57 01 3D 00 40 00 08 01 66 00 And these likely translate to 7 fields: PStatField #1 0x0012 -> 18 PStatField #2 0x0008 -> 8 PStatField #3 0x0157 -> 343 PStatField #4 0x003D -> 61 PStatField #5 0x0040 -> 64 PStatField #6 0x0108 -> 264 PStatField #7 0x0066 -> 102 Which BTW creates a nice, symmetrical situation with the batters (that is as well not correct, probably a typo): As there are 20 Bytes, so for Brady Anderson that would be: Next 20 is stats based data 04 00 10 00 CF 00 80 00 B5 00 DA 00 24 00 49 00 D3 00 F8 02 BStatField #1 0x0004 -> 4 BStatField #2 0x0010 -> 16 BStatField #3 0x00CF -> 207 BStatField #4 0x0080 -> 128 BStatField #5 0x00B5 -> 181 BStatField #6 0x00DA -> 218 BStatField #7 0x0024 -> 36 BStatField #8 0x0049-> 73 BStatField #9 0x00D3 -> 211 BStatField #10 0x02F8 -> 760 If you find these values in the visualization of the game statistics we can assign the right field name to each . jaclaz

Yep , but what is next? I mean. it seems like the "Address" is a "plain" enough database, with 50 or so records (possibly 52), one for each team, Then both the "Batters" and "Pitchers" are as well plain enough databases with respectively 739 and 477 records, corresponding *roughly* to 50*15=750 and 50*10=500, with the names and the characteristics of each player. If they were my files I would probably put together an Excel spreadsheet and write a couple (half-@§§ed as always) batches to "translate" forth and back the contents. jaclaz

You are right, I was *somehow* parsing the same range twice , but the record size is correct, 50 bytes. What throws off manually viewing the file is that some entries have 00's, i.e not all entries are "populated". Attached the corrected Address.MPS, replace the old one with this (no more the "whatever" field ) Now, in "Address" Entry # should be the Team #, whilst in "Batters" and "Pitchers" the "Prefix" should be the Team #. I.e. in Batters, Batter #589 Roy White should belong to Team #42 (value of "Prefix"). And in Address, in Entry # 42 there is (last filled entry in Batters) #589. As well, in Pitchers, Pitcher #387 Mike Torres should belong to team #42 (value of "Prefix"). And in Address in Entry #42 there is (last filled entry in Pitchers) #387. jaclaz ADDRESS.mps

Yep, only for the record it is also in the post by Tal Aloni here: https://hardforum.com/threads/windows-xp-x64-nvidia-driver-fix-page_fault_in_nonpaged_area-when-two-monitors-are-connected.1972152/ (but the actual dowload link is the same): http://vm1.duckdns.org/Public/Nvidia/368.81-PAGE_FAULT_IN_NONPAGED_AREA-fix/nv4_mini.sys jaclaz

The answer is yes and no (and no ), the disk detected as 3.86 GB can be the common symptom of different issues. So: 1) Yes (if it is one of the fixable ones) 2) No (if it is not one of the fixable ones) 3) and No, nothing that you can do yourself, besides the serial connection some specialized tools are needed and it is NOT an easy to do procedure, you have to ask a professional Here is an example of a recovery: but more often than not the issue is due to head(s) gone bad, which implies going to a reliable data recovery firm (with the appropriate tools and knowledge to perform platter/heads swap and recalibration). A software only data recovery should be in the hundreds of dollars, if a platters/heads swap is needed you are likely crossing the border to thousands. jaclaz

Try the attached ADDRESS.mps and PITCHERS.mps. jaclaz ADDRESS.mps PITCHERS.mps

Ok, in the meantime get TinyHexer from here: https://www.softpedia.com/get/Others/Miscellaneous/tiny-hexer.shtml Put the attached ,mps in the \mirkes.de\Tiny Hexer\scripts\Structure Viewer folder and use it on the BATTERS file. There is a little glitsh as the single quote character in the batter name makes things "go green", but it is only a visual one. Of course I need BOTH the "stock" and the "modified" files to go on. jaclaz BATTERS.mps

And where is "PITCHERS"? jaclaz

Well, the rule of the thumb is that (speaking of consumer products, not "bulk") if the manufacturer cannot afford a "proper" package for their products, then I cannot afford[1] their products, judging from the e-bay listing they had "one box fits all", that thingy, besides the current low cost on e-bay, must have been really "el cheapo"[2] even at the time. jaclaz [1] meaning that I can, obviously, but that I cannot afford the issues they will provoke. [2] which in itself may mean little, as an example I have found in my experience no real differences in the lifetime of PSU's between "good name" and "el cheapo" ones, nor the cheap ones ever caused any particular issues

Well as said if any of the power rails is shorted to ground the PSU will simply not power on, it could be really anything, including some (conductive) dirt in a connector. Try re-adding cards one at the time, check that connectors are clean. If you are "lucky" when you add one of the PCI cards, you will have the same symptoms, if you can re-add all the cards without issue, then it will be a problem as you won' t know what made it happen. jacla

Can you post the actual files? This: Is not accurate, 00 is - as said above - not a delimiter, it is more likely the higher value byte of a two byte numbering, Good, this explains why second grouping stops at 0x00A0. jaclaz

Well, to give you some (non-random but not necessarily meaningful) data, I fiddle around with PC's since the early 1990's and (maybe luck/case, maybe not) in these almost thirty years I replaced on the various computers I manage, partly mine partly of friends/relatives: 1) a large number of failed hard disks (tens of them) 2) much more than that, I would say "countless" failed PSU's 3) a handful of motherboards, maybe 3 or 4 that were beyond meaningful repair[1] (out of a total of - say - 7 or 8 total failed ones) 4) a handful of graphic cards, maybe 3 or 4 Anyway modern PSU's have a protection circuit and if any of the rails are shorted to ground they won't simply power on, so - to all practical effects - a shot TVS diode on the +12 V or on the +5 V has the same effect, but the same symptoms may be shown for a whole lot of other reasons. jaclaz [1] i.e. with very minor issues, one or two capacitors to be replaced, a shot PS/2 diode a couple broken solder points/connectors, an on-board network adapter gone beserk, and similar.

Sounds like a bad PSU. Try detaching hard disks and SSD's and try again booting. It wouldn't be the first time that a capacitor (or whatever) goes bad in the PSU and the computer cannot boot (but it can with the hard disks removed). Conversely, it could be a hard disk gone bad, and preventing the machine from booting. (JFYI most hard disks have a "safety" diode, called "TVS" that simply grounds the +5 or +12 V) see: http://www.hddoracle.com/viewtopic.php?f=100&t=86 jaclaz

First thing, it is a two byte numbering, little endian. I.e. what you call "01" is a actually "01 00" and it means 0x0001. The 0101 is actually 257 , if you prefer the sequence is: 0x00FE 254 0x00FF 255 0x0100 256 0x0101 257 So you can have at the most, since 0x0000 is not used, max 0xFFFF values, i.e. 65535. It is "queer" how there are holes in the numbering, I continue to fail to understand half of what you are saying, what (the heck) do you mean by: How (the heck) are you determining that the entry "Mike" is corresponding to entry #03? Can you post the first (say) 512 bytes of File 2 (as opposed to an arbitrary small snippet of it starting at 0x0080?) You can replace text like "Mike" with "wxyz" if there is any sensitive data. Loosely, it resembles a lot a FAT 16: http://www.ntfs.com/fat-allocation.htm jaclaz

Well, it seems that all the update contains is an updated IFSMGR.VXD and a couple Registry settings: https://web.archive.org/web/20030730005106/http://support.microsoft.com/default.aspx?scid=kb;en-us;q273017 AFAIK .vxd's are not "localized" files, so most probably the different language files only differ in the "install program" language. As a matter of fact on this "updated" page: https://web.archive.org/web/20130521085102/http://support.microsoft.com/default.aspx?scid=kb;en-us;q273017 the ME fix is "usa only", and I cannot see a reason why the 98 version should be "localized". The 273017USA8.EXE can be found here: http://www.tacktech.com/display.cfm?ttid=90 If I were you I would try the "usa" version on a fresh dutch install (VM) and see what happens. jaclaz

Well, I can understand maybe 1/3 of what you wrote. If there is no sensible data involved, post the actual files. or at least some snippets of the files as they are. jaclaz

I am actually far less curious than you, basically because I perfectly know the tools (BOTH ones) and I have no use for the "old" DOS one (since some 20 years), as it is largely obsolete (and it wasn't even that miracle of usefulness even in its times). Wow, never thought I could use a VM for such a test. jaclaz

No, it is not, if you have a program running on DOS/Windows 9x/Me it is likely ANOTHER program that is also called gdisk, most probably a software dated 1999 or so from Symantec. Rod Smith's gdisk (which is what I suggested you) first Windows version is 2010 and first versions actually usable by end users is circa 2013m current version is 1.04 dated 05 July 2018: https://sourceforge.net/projects/gptfdisk/files/latest/download jaclaz

Yes, gdisk is command line only, but I wonder what would be its use in the context of "Windows 98 drivers back disks" , you must be talking of "another" gdisk. jaclaz

No idea whether any of those tools will show the GUID (maybe selecting the partition and viewing properties)? I would use gdisk : http://www.rodsbooks.com/gdisk/ and make sure that it sees it as "ef00". jaclaz

Maybe, just maybe, the (stupid) MS tool wants a "canonical" setup, complete with the MSR partition (ad possibly the mysterious second recovery partition)? Or maybe it is the order of the partitions that affect the result, but I doubt it. You posted a screenshot of a tool I am not familiar with, normally the "boot" EFI partition shoudln't be a "GPT (Data Partiton)" but rather a "ESP", of course every tool will call it slightly differently, but it is entirely possible that the GUID/type of that FAT32 volume is not correct (that would be an error that might lead to "Failed to retrieve system partition NT path" (remember that MS calls System what anyone else calls boot and viceversa). Check the actual GUID of that partition, it must be 2C12A7328-F81F-11D2-BA4B-00A0C93EC93B", see: https://en.wikipedia.org/wiki/EFI_system_partition jaclaz