jaclaz

You need a loop checking that the process is running, issue may be that continuous loops in batch use lots of CPU time, so usually a timeout is inserted in the loop, since a timeout/sleep command is not available in XP, you will need a third party tool or use one of the poor man's alternatives, such as Ping. AutoIt does not use as much CPU as batch AFAICR, still a timeout/sleep would probably be needed. There are workarounds, like the excellent: https://www.bill2-software.com/processmanager/ but it seems to me like a bit too complex if a quick AutoIt would do it. (this is a sort of taskmanager that - among many other features - allows to monitor a process and do something whenever the process is started or closed) BTW if start /wait works, you can use/spawn a child process, check: https://ss64.com/nt/start.html maybe you don't want to use the /b option? Start /wait has a whole number of issues, you need a lot of experiments to find the "right" command line. jaclaz

I am not sure to have understood the question, but there is nircmd that can kill a process from batch (or tasklist/taskkill). Why would the focus on a window matter? jaclaz

What do you mean exactly? (please describe your setup) An issue with arcpaths in boot.ini (or *something else* in the BCD, [1])? jaclaz [1] but the BCD should not be involved for XP booting

In theory, yes, in practice no, in the sense that (IMHO) the time that will be needed to create a perfectly working automated installation disk with drivers/updates/programs will take you far more time than making many (and I mean many) normal, attended, manual installations. If you have the need to make a few tens or hundreds of installations (on exactly the same hardware, on different hardware it will be much worse), than it will be justified, if you install or re-install every few months or so, it doesn't really makes sense, and if you have only one or a few machines, it is much more convenient to setup the system manually and then image the install. jaclaz

These kind of tools (like the Paragon one) are "low-level" enough to be likely to conflict with one of the zillion modifications/patches and what not a "modern" 9x/Me system will have, but Jumper is correct, if you are hot-plugging the disk drive, don't, hot-plug support in 9x/Me tends to be shaky at best and most of the used USB drivers are as well often not-so-stable. jaclaz

DOS/9x tools have always worked on the "most common" at the time NTFS, that is the version used in 2000 and XP. It is not a very good idea to use NT4 NTFS, as it anyway will be converted to the "new" Windows 2000 version as soon as a newer windows NT OS will access it (and this - depending on the NT4 install - may make it become inaccessble by NT4), of course this is not a problem in a DOS/9x/ME (and NT4) ONLY environment/setup. Read Only NTFS is "easy", and usually works fairly well, for 9x I would recommend the lesser known: https://www.diskinternals.com/ntfs-reader/ (now "Linux Reader") https://www.diskinternals.com/linux-reader/ which in my experience has proved its utility several times (for recovery purposes). The "several drivers/tools" are very likely to have created conflicts, you try ONE of them, then you uninstall/delete it, and then try another one. Read/Write tools have their issues, though a number of them do not depend on the tool, but rather to other factors involved with large filesystems and/or large sized files on them. Read/write there is - I believe - only the Paragon tool still available: https://www.softpedia.com/get/System/Hard-Disk-Utils/Paragon-NTFS-for-Win98.shtml jaclaz

Which is "another" way to do what I suggested earlier (hiding the "other" partition through a bootmanager). If a partition is marked as "hidden" it is "more protected" than having the drive letter removed. Probably you missed in my earlier post how the hiding (of the "other" partition, and the unhiding of the currently chosen one) in a bootmanager works, it is done on-the-fly at boot time, before the old (or new) OS is booted. The "other" partition is never auto-mounted by the "current" OS (as opposed to be automounted but without a drive letter). Typical grub4dos menu.lst example: title Windows 2000 hide (hd0,1) unhide (hd0,0) makeactive (hd0,0) root (hd0,0) chainloader +1 (or chainloader /ntldr) title Windows 7 hide (hd0,0) unhide (hd0,1) makeactive (hd0,1) root (hd0,1) chainloader +1 (or chainloader /bootmgr) (the makeactive directive might be not strictly needed, but by including it when the ntldr or the bootmgr loads the disk will appear as a "standard" disk with the "current" partition active) jaclaz

@awkduck Yep, but though grub4dos can do *almost anything* it can only be used to re-order (or hide/remove, or add) disks/volumes, etc. the drive lettering remains the "default" automatic MS one, so you won't be able through it to actually "assign" drive letters as letter assigner can, besides the complexity (which is relative, it is not difficult to use grub4dos after an initial learning of the basics of it) you simply cannot obtain some letter combinations. Subst can be used in some cases, though. jaclaz

If I recall correctly there are more than one possible ways to have DOS in WinME (three or four of them). Maybe you can try the "other" one(s), I seem to remember that at least one of them needs not patching the IO.SYS (but still it may not be compatible with letter assigner). The "latest" one (using files from LTOOLS.DTA) may also work, but cannot really say, the explanations in MDGGX's TIPSME:TXT are rather confusing. TIPSME.TXT is inside W95-11D.ZIP https://www.mdgx.com/bin/W95-11D.ZIP jaclaz

Good. jaclaz

JFYI, in the good ol' times of DOS, there was only one text editor that I liked (shareware), called Qedit (everyone had it as q.exe): https://en.wikipedia.org/wiki/The_SemWare_Editor jaclaz

Maybe. But first it is needed to test if a .pif made on Windows 98 dies actually work on ME (it is entirely possible that the "old" setting is ignored), and if it works, it has to be seen if it is worth it (as opposed to hex-edit a single byte, which may possibly be automated in a batch script). What you should try would be: 1) make a .pif for your executable on windows 98 without the setting 2) make .pif for your excutable on Windows 98 with the setting 3) make a .pif for your executable on Windows ME (of course without the setting) 4) test all three .pifs on Windows ME and verify that all work as expected 5) post the three .pifs so that we can check that differences are where they should be jaclaz

Sure you are not :). Sed is waaay more powerful than gsar and much more suited to this task than gsar (and in some versions sed can also use Regex expressions), but as I said earlier it is much more complex and BTW I suspect that the "generalization/simplification" of the search/replace string by the OP may not be entirely accurate, I think he should post an example text with more specific data than AAAA and aaaa, as they risk to be misinterpreted, resulting in a "non working" suggestion. jaclaz

You might need two passes with gsar: 1) [SPACE]AAAA[SPACE] 2) [SPACE]AAAA[CR][LF] (this of course does *another* thing from what you asked, instead of ignoring what is inside quotes, it picks what is between spaces or between a space and newline, taken from your example) SED is probably more suited, but it is of course much more complex. jaclaz

Yep , the files from RainyShadow have the Windows 286 section before the Windows 386 one, that is 16h (section header) +6h (section length). Could it be that the files by Rainyshadow are for the original DOSPROMPT pif (that has the 286 section) and your tests are with another "generic" .pif (missing the 286 section), I doubt that different installs of Windows 98 may have different files structure (or different sections order) but it is of course well possible. But once it is confirmed that it is the same byte, according to the doc: 01 means "Prevent Windows detection" (not "Close on Exit", maybe it is a translation issue of sorts, as the Author of the doc is probably Russian) 04 means "Not automatically offer transition in a MS-DOS mode" 10 means "Not warn before transition in a MS-DOS mode" jaclaz

@jumper It sounds "queer". The size of the sections and of the section headers per documentation are fixed, 1B0h is 1Ch (28) before the calculated 1CCh, which is at relative offset 10h+3=19, so your 1B0h seemingly falls before the beginning of the 386 section, right into the section header. AND "Close on Exit" should be in the Basic section, at offset 63h. and it should be 10h as value, not 01h Post a .zip containing your y.pif and z.pif, I would like to have a look at them, comparing with the files RainyShadow posted. jaclaz

No, rest assured, the WPA (or whatever it is called) compares a sort of inventory of the connected hardware at activation time with the current one, the list and then cast "votes", what hardware pieces are used is known/documented, JFYI: http://www.aumha.org/win5/a/wpa.php See also: https://msfn.org/board/topic/161662-nic-and-wpa-votes/ jaclaz

Corrected previous post, I read the document incorrectly, it is accurate. Re-checked it. The 0x1CC is correct. The four byte value is at offset 0x10 from the beginning of the section, since the 0x04 is the most significant byte, it is the fourth byte, i.e. there are 3 bytes before it. The section begins at 171h+16h+16h+6h=1A3h (basic section+basic section header+first section header+first section length) To this you add 16h for the second section header, 10h for the relative offset in the section and 3 for the relative offset inside the 4 byte value: 1A3h+16h+10h+3=1CCh jaclaz

The linked to doc uses lengths of the section (excluding titles) and some lengths within section seems wrong (possibly something has changed in the format) and there is some 00 and 20 (SPACE) padding, but all in all the 0x1CC offset is fine. jaclaz

Good. The 04 seems right, the offset is - pardon me the pun - way off, but if the byte is there it is there (and the mentioned doc is not at all clear in the way it provides offsets or I am very bad at calculating them, maybe sections are in a different order from what seems to be described). BUT I checked the files, and the offset is actually 460 decimal i.e. 0x1CC that makes a lot more sense, I will try later to re-calculate if it matches. jaclaz

Most probably (but should be tested) it is the 04000000h value in the bitmask at offset 010h of section Windows 386, marked as "Not automatically offer transition in a MS-DOS mode" in the linked to document, which sounds like a "reversed" description of "Suggest MS-DOS mode as necessary". @RainyShadow If you have time/will can you make: 1) two copies of a same .pif 2) save a copy of the .pif with the setting enabled 3( save the other copy of the .pif with the setting disabled 4) compare in a hex editor or run fc /b against the two files jaclaz

AFAICR, the properties you are setting are connected to .pif files. They are like the least documented MS files ever, the only document I ever found that deals with them is here (via Wayback Machine): https://web.archive.org/web/20220214185118/http://www.smsoft.ru/en/pifdoc.htm (no reference to what works in ME, though). There could be two possibilities: 1) the ME simply does not respect/read/parse the setting in the .pif file 2) the ME respects/reads/parses the setting correctly BUT the editing interface misses the setting Of course if it is the 1st case there is very little that can be done, but if it is the 2nd there may be ways. Have you tried creating the .pif in Windows 98 and then trying running it unmodified in ME? ( you would need another system or a VM runnning 98) Or creating a "same" ..pif under 98 and under ME and compare the actual files to see if there are differences (and if they are in the relevant areas according to the provided doc)? jaclaz

@Wunderbar98 JFYI, not really, it depends on a number of factors, on brand/model and what not, most (if not all) laptops that are "recent enough" won't have a BIOS access password reset by taking the CMOS battery off, some may still have a jumper to reset passwords, many will need specialized hardware, to either re-program or downright replace a chip: https://www.computerhope.com/issues/ch001302.htm @ frank woolf We need to know the EXACT make/model of that laptop in order to be able (maybe) to provide you with some specific advice. jaclaz

... it may sound strange to many people, not too. Your comparison does not really apply as Microsoft is a collective of people that changed over the years, and historically in many cases made new versions that were objectively terrible[1], Nuhi is always himself, the appearance of the tool may well have changed and be terrible (too light) for the eyes (BTW like many apps in the "washed down" Windows 10 interface), but I doubt that this may qualify it as "crap" and that it fails to do the whatever it is supposed to do. I never used either Vlite or NTlite (and only briefly used Nlite) so cannot really express a personal opinion on them, I was only trying to provide a possible explanation. jaclaz [1] compare with the move of the short sighted bishop (or of the limping knight): https://msfn.org/board/topic/155290-windows-8-deeper-impressions/?do=findComment&comment=996327

Maybe you miss some of the history behind nlite, vlite and ntlite. They are (were) developed all by the same person Dino Nuhagic (Nuhi) and (at least up to nlite and vlite) with support from MSFN members. So - once said that de gustibus non disputandum est - I think it is understandable that to many people on MSFN it may sound strange that a new product re-written by the same programmer (with many added years of experience in the specific matter) may suddenly become "crap". jaclaz