Tripredacus

Thanks, I will take a look at it.

Verify that you are manually starting your install in EFI mode. You need to create the MSR partition in your XML. Ref: https://msfn.org/board/topic/154404-how-to-clean-gpt-hard-disk-using-autounattendxml/

Pitchers: For the Jeff Ballard example, these reflect to these in-game values PStatField #1 0x0012 -> 18 Wins PStatField #2 0x0008 -> 8 Losses PStatField #3 0x0157 -> 343 ERA (3.43) PStatField #4 0x003D -> 61 Endurance PStatField #5 0x0040 -> 64 Walks (1989 value: 57-5) PStatField #6 0x0108 -> 264 Hits (1989 value: 240) PStatField #7 0x0066 -> 102 Strikeouts (1989 value: 62) Endurance, Walks, Hits and Strikeouts are under "Player Ratings", and the first three are under "Actual Stats". Actual Stats are not really used for anything functional in the game that I am aware of. They only appear on the Pitcher select screen and are used as a reference. The data under "Player Ratings" are generated by the game when actual stats are input. Endurance has never seemed to make any difference if the number was high or low. Jeff Ballard's source stats for these values are Strikeouts (62) Walks (57-5) and Hits (240). I put the - on the walks because the game does have an input field for IBB, which I imagine that the game would not count as actual walks if it is using the walk rating for actual performance since IBB is a managerial decision. His IP from 1989 is 215.1 in 35 games. I have determined that the Endurance value is IP / G (innings pitched / games) removing decimal. For Jeff Ballard, Endurance = 61, IP = 215.1, G = 35 (215.1 / 35 = 6.1) For Pete Harnisch, Endurance = 57, IP = 103.1, G = 18 (103.1 / 18 = 5.7) For Gregg Olson, Endurance = 13, IP = 85, G = 64 (85 / 64 = 1.3) For the other three values, I am presuming it would (normally) use the "total batters faced" input value, For Jeff Ballard, his BF from 1989 is 912 Batters: For the Brady Anderson example, these reflect to these in-game values BStatField #1 0x0004 -> 4 Home Runs BStatField #2 0x0010 -> 16 RBI's BStatField #3 0x00CF -> 207 Bat. Avg BStatField #4 0x0080 -> 128 Walks (1989 values: BB 43, IBB 6) BStatField #5 0x00B5 -> 181 Hits (1989 value: 55) BStatField #6 0x00DA -> 218 2B per hit (1989 value: 12) BStatField #7 0x0024 -> 36 3B per hit (1989 value: 2) BStatField #8 0x0049-> 73 HR per hit (1989 value: 4) BStatField #9 0x00D3 -> 211 Strikeout (1989 value: 45) BStatField #10 0x02F8 -> 760 Speed (1989 values: SB 16, CS 4) As with the pitchers example, the first three bits of info (HR, RBI, Avg) are informational. They appear in game as reference data when the batter is at the plate. 1989 AB: 266. Actual PA is 317 but the game doesn't ask for PA only AB. PA = AB + BB + HBP + SF + SH (of which, all besides HBP are prompted for, and you can put -1 in for SF and SH). So presumably, in-game PA would be 314 OR 320 if IBB are counted. BstatFields 6-8 are percentages. 55 hits, of those 37 are singles (67.3%), 12 are 2B (21.8%), 2 are 3B (3.6%) 4 are HR (7.3%). Verified using this site: https://www.rapidtables.com/tools/pie-chart.html Data names: 1B 2B 3B HR Data values: 37 12 2 4 Also for real-world data the game uses, 1989 stats of any players in these examples, they can be found on Baseball-Reference, ie: https://www.baseball-reference.com/players/a/anderbr01.shtml

My next step is to write a program that can read and write to these files. I still have to determine how to actually accomplish it. The main issue at hand is that I do not know what the "data" is in the player records. I know what it is, it is the stat data. Data linked to how well they hit, strikeout, walk or base stealing. I believe it to be quite simple, that it uses numbers to determine probability. BUT these numbers are weird and not actually baseball related. You can see them in the game itself if you look at an individual player's stats. So the options would be: 1. Go the next step and figure that part out to. Then I can do all roster management outside of the DOS program, including "deleting" and adding players. 2. Refactor the batters and pitchers files, to basically remove the players who are "deleted" from the file entirely, shifting their position in file number upwards, and adjust the address file accordingly. 3. Use a second instance to create players, get the data from the respective file and replace "deleted" entries with that data. I think that the second choice would be the easiest... basically would be running a cleaner script on the files to remove unneeded data. The first option is more ambitious, but could include the function of the second as well.

I remember seeing a "Windows 99" version floating around usenet back in the day.

The duplication of next batters does not appear in the raw data. There is no repeating of data that I can see. Easier to see differences using the Address2016 file rather than the default one.

When it comes to system files from newer OSes, especially when dealing with running a program below requirements, this is not the recommended thing. Rather, to put such files into the working directory of the exe... with the hopes that the developers were lazy and did not specify a custom search order or use an absolute path. Then in the chance this trick works, it may be enough to allow the program to run. And since such an effort is a blind try, there is no guarantee that the program will work properly or be error free.

You'll need a Legacy firmware ( "BIOS" ) GPU that meets the requirements of the games you'll be playing on Windows 10.

This programs certainly looks a bit different. Attached is the Pitchers file, as well as some 3 year old versions of the modified files. In the 2016 example, players who have a Decimal value of 49 are players who are "deleted" as Team 49 (in the 2016 version) is the "temporary" team that I always move players to for deletion. PITCHERS ADDRESS2016 BATTERS2016 PITCHERS2016

You are right. It is closer to being a section. 01 00 is the first player in the first "group" of the batters file. Because further along, there is a 01 01, which is the first player int he second "group". This is only evident in the stock files, which are "in order" like this, where everyone in the first group are in order in the Address file. Files from the updated version are not so nice to look at. I have attached address and batters from the stock version. ADDRESS BATTERS

There are situations where a component will work when hot but not when cold. This can be the electrical or thermal sense. A board not posting due to a faulty add-on component may actually be a feature of the board design. It would be difficult to know for sure without a tech document but I doubt Gigabyte makes such things available.

The licensing status is "unknown" as it is one of those products made by a company, who was bought by another company, that was folded into another company, etc. The common thought is that it is "abandonware" and can be found on those websites. The program is called "Major League Manager" by Spinnaker Software. It runs on DOS. The only version online is the "1990" release (has 1989 rosters) but apparently the older versions have not been found. The insinuation that the designer never expected it to be used "for years" is true... BUT this bug the software has is not due to an extreme length of time it is used. I first encountered this issue within a year of using the software initially back in the early 90s. The game is designed for you to create teams, and to create players for those teams. It also allows you to "delete" players, whether they are created or built-in. If you created 10 teams and the 25 players for each of those teams, you'd hit the bug quite quickly. I have attached my notes regarding the files. For the purpose of clarity, in this thread "FILE2" is BATTERS and "FILE1" is pitchers. Also to note: the stock program does not have any teams in custom league. In my notes, "MLM2018" is my active custom version that has about a half dozen slots left in the BATTERS file. "MLM2019" was the next instance I was working on that encountered the EOF situation. FileDetail.txt

I do not know whether or not if the software is actually storing the data in hex. There is no key as to what kind of files these are, and I only have decoded how they work by opening the files in a hex editor, making a change with the program and comparing the changes. I think that the data is not actually in Hex, but I am viewing it in a hex editor. I was unable to view the data properly in Notepad or Scite, but it did show properly in UltraEdit... but it automatically had shown the data in the hex editor mode. I know Mike is entry #3 because it is the third entry in FILE2. That was my main concern. The ADDRESS file only is storing the position of the data entry in FILE2. BUT in FILE2, the entries have no index value. I can easily look at the ADDRESS file and say "ok I need to find the 200th entry in FILE2" but then I go into FILE2, I would have to manually count the entries (and hope I didn't miscount) to find what is in the 200th entry. What I want to do is determine how to calculate where in file 2 I can read the data, by either the offset shown in the hex editor, or by using a character position/count. So I will need to know this math portion for when I write a program to manage the "deleted" content. So far, my attempts at determining the position of the data in FILE2 from the values in ADDRESS have not worked, Even the example of the Mike I can't even math that properly.

Here is what the beginning of the address file looks like: EDIT: Typo in this picture, "03 is first, should be 03 is third) Here is where the address file moves past 255 and FILE2 example data: The two questions I have are: 1. Does this flat file database method have a particular name? 2. How do I determine the Offset of an entry using the address file. In this example, 03 00 (from Address file) points to the third entry in FILE2 which starts at offset 8A. 8A to Dec is 138 / 3 = 46. Since the data entries are in 55 byte groups, this is the wrong math. I need to be able to take the entry from the address file and find it in FILE1 or FILE2. Is the problem that I am doing a decimal conversion in trying to figure this out? FILE2 reference. First entry starts at offset 0. Second entry starts at offset 45, third entry is at offset 8A.

I am working on a project in which I want to be able to create a workaround to a flat file database issue, referenced here: https://msfn.org/board/topic/179737-cause-and-workaround-for-a-50k-file-size-limit-in-dos/ The problem in particular is that two files are potentially a problem, as they have a fixed size or addressable size. The software does not replace data, rather it appends it and does not actually recognize the EOF. The EOF is actually in the middle of a dataset, so when data is entered, it writes the half that it can, then duplication and data tabulation bugs begin to occur. I am fortunate that I have a backup from just before and just after this issue appeared, as well as the original files. I have already attempted to manually figure out how the addressing works in my design, but keep running into problems getting the correct results. So there is something I am just not grasping about how these files work and maybe someone has an idea about it. Perhaps whatever the programmer used to create this has a named method that I can look into... if I knew what it was. The files that this program uses are non-indexed, non-addressed but in hex. It uses hex values and appears to "count" entries (or known block sizes) to find relevant data. Examples: FILE1 has 44 blocks per entry FILE2 has 51 blocks per entry ADDRESS refers to data in either files in blocks of 30+20 (15+10) With an example in address of 01 00 within the first block of 30 (or 15), this is pointing to the first entry in FILE2 (Offset 0) file. If an address of 01 00 in the first block of 15 (or 10) which is the second section, it points to the first entry in FILE1 (offset 0) file. In the 3rd block of 30, an address of 10 00 is the 16th* entry (Offset 40B) in the FILE2 file, and so on and so on. Does this method have a name? How would I search for how this data is being organized? * This is one example where I can't figure out the math on locating the data manually. It is some math error I am making in my head. I know that 10 in hex is 16 in decimal, I know the data is the 16th entry (I counted it, and this is why I am using low numbers in my examples) but I do not know how 40B is determined. 40B in hex to dec is 1035, divided by 51 is ~20 not 16. 40B is the offset shown in the hex editor.

This topic is quite bare. You should post some of the actual errors you are seeing in the Event Viewer.

What aspect ratio is your display? What is the resolution you have set in Windows? I also seem to recall that some game in 9x would have issues depending on what the color depth was set for.

Did you also receive a bugcheck on your system like the guy in those links?

From what I have gathered, currently there is no PoC for this. It is basically saying that at some point in the future, you'll need this to do certain things. One of which, I am presuming, is use Windows Update. The thing about being able to connect to wireless networks is valid enough I suppose. Currently it seems Windows 7 is in an in-between-land regarding those (at least in my experience) so I may mitigate that issue entirely by not using Windows 7 on wireless computers.

Windows Update does a process similar to the old in-place upgrade for Feature updates. So things you have removed may not be retained, because they are present in the OS that is downloaded from Windows Update.

This thread is just for XP we have seen "out in the wild" or on the internet, not our own personal systems. We have a thread for that kind of thing here: Which I will be posting in soon once I get my notebooks sorted out.

Ok then, create a new topic and post your XML and we can take a look. But one thing to remember, you can have either XML to create partitions on UEFI/GPT or Legacy/MBR. If your XML is written to create Legacy partitions, but your boot your install media in UEFI mode, Setup either will show the formatting prompt (as shown above) or give an error. Vice Versa has similar issues. So always make sure you are booting correctly, and for this I recommend using the one-time boot menu for your system.

Just making sure you aren't being generic, but IIRC you need Windows 8.1 Update 1 to go to Windows 10.

I have redone my notebook to have a dual boot with Windows 10 and Linux, and now before I attempt to update Win10, I want to make sure I can restore the multiboot ability should Windows Update decide to rewrite things. Windows 10 is an LTSB edition, so it should never get a feature update. Currently the system boots to the Linux boot menu, from there I can choose the OS and I'd rather like to keep it that way. The disk type is MBR. There are 3 partitions: 1: Boot, 2: OS (first two windows) and 3: Linux. It is an SSD if that matters. What are some ways I can easily back up and restore the boot information/menu should Windows decide to take back control of that? Preferrably something that can be run in a WinPE.