jaclaz

Just for the record, TeamViewer (but not only specifically TeamViewer, all "remote control" software) may represent an easy way to access the remote PC by you or by *any* hacker, so besides configuring it as securely as possible: https://www.howtogeek.com/257376/how-to-lock-down-teamviewer-for-more-secure-remote-access/ do NOT leave it running 24/7, have when needed the session initiated by your parents and closed after you did whatever you need to do. (only my two cents) jaclaz

Nice features. Maybe a list of "current" features AND a compiled, working, installable, testable *something* with those "current" features will make the project at least Alpha. The .7z file you pointed at seem only part of the source code from MS and from ReactOS (and mixing them is usually not a very good idea when it comes to licensing). jaclaz

Well it is not particularly difficult, as there is an (easy) workaround in the form of one of the filter drivers that "flip the bit" in software. It has to be seen if the fiter driver in the PE is working in your specific case, though. More or less Sandisk is the ONLY make/brand for which a "set fixed/removable" "Manufacturer Tool" is NOT available (all the others usually are, though some of these tools are easy-peasy while some other ones are so little documented and "tricky" to make it advisable to avoid them). There are basically three available drivers: 1) good ol' cfadisk.sys 2) Anton Bassov's dummydisk.sys 3) the "new" kid on the block, Karyonix's diskmod.sys They all work at least up to 7, but I believe you are dealing with 64 bit, and besides being the most recent one, diskmod.sys comesalso as a 64 bit and has a few added capabilities, so if I were you I would try it: http://reboot.pro/topic/9461-page-file-in-usb-hard-disk/ About flipping the bit in hardware, the reference page is this one (Russian, use google translate or similar): http://www.usbdev.ru/ A "forensic sound" image is nothing but a byte-by-byte copy of a a "disk like" device contents (much like a .iso image is the image of a CD or DVD media), in Linux the usual tool is dd, in Windows there are many similar tools, including a good dd for windows, the issue with Windows 10 in some cases may be permissions, the most compact one is dsfo/dsfi (part of the dsfok toolkit): http://members.ozemail.com.au/~nulifetv/freezip/freeware/index.html not the faster one, if you prefer a GUI (and faster) one, you can go for Clonedisk: http://reboot.pro/topic/8480-clonedisk/ http://labalec.fr/erwan/?page_id=42 but *anything* that can make an image of a disk and deploy it to another one would do for the experiment. jaclaz

The real problem (mine) is that I remember the early '80's like it was yesterday . There should be no issues with the DVD drive, it should be a drop-in replacement for a CD drive, then, reading some DVD's (not CD's) in Windows 98 might require additional installed software. jaclaz

Some good news and some bad news. The good news first: A CF card is pin-compatible with the IDE/ATA (PATA) bus, which means that adapters are "mostly electric and mechanical" adapters, not "electronic" ones, i.e. there is no fancy "translation" which means that all adapters are good, there is no particular chip in them that may cause issues or bottlenecks. There are usually two kinds of adapters around, a type for single CF card and a type for dual CF card. Typically the single CF card will have a switch to make it primary or secondary device, whilst the dual type has a connector hardcoded for primary and one hardcoded for secondary, I would suggest you the latter type since they cost the same and you have the possibility of expanding the storage by adding another card. If you get a fast enough card, it will anyway run circles around any IDE hard disk, not as fast as a SSD, but then again the whole point is being on par (or outperform) your (slowish) IDE/ATA bus. This (even if it is MAC oriented) will give you some insights: http://lowendmac.com/2015/the-lowdown-on-using-compactflash-to-replace-an-ide-hard-drive/ The bad news: We don't have AFAIK any meaningful data on the durability of these cards for several reasons, the first being that there are more CF cards (also based on different internal technology) than stars in the sky and typically they are used (besides cameras and similar, where the writes are in "bursts") in "peculiar" systems, often mostly read only. So we don't have a real idea on how long they will last in a "normal" OS install, where there can be often "granular" writes. And now again some good news: Notwithstanding the above, don't worry , a good quality card will run flawlessly for years in a "normal" DOS/9x/Me install. To give you a single data point, I have one installed in a re-furbished terminal client that I use as a router with a Linux install that is partially read-only but that continuously writes logs to the card and the device is in service 24/7 since more than 5 years and never had a "wear" issue on the writable filesystem portion. jaclaz

I either don't know what to look at exactly, just checking if any difference is spotted. More like "excluding the impossible", There is normally no filesystem difference in a 8 Gb vs. 16 Gb size (re: cluster size), What it could be is some (if not bug) "peculiarity" of the BIOS/UEFI (or even of the OS), it is not uncommon that there are "arbitrarily" behaviours conneceted to "size", though I don't remember any in that particular size range. A typical one is different behaviour when the USB stick is set as "removable" (like 99% of sticks are) or "fixed" (like say 1% of sticks and 100% of hard disks) or something connected to the CHS limit (nowadays *nothing* uses or should use CHS anymore, still 1024*255*63*512=8,422,686,720 is the limit of CHS, and it is possible that the 8 Gb stick is within it whilst the 16 Gb is definitely beyond it) and even if in theory it should make no difference whatsoever, in some cases it happened that different disk order was attributed connected to these.., It could also be the drivers .inf files that expect the RAID to be (say) first disk or whatever, including some "peculiar side apps that - for whatever reasons - cannot "reach" a given LBA. Another experiment you can do is the following: 1) prepare the 8Gb stick 2) verify that it installs drivers 3) make a "forensic sound" image of it (using dd or dsfo, etc,) 4) prepare the 16 Gb stick 5) make a "forensic sound" image of it (using dd or dsfo, etc,) 6) deploy the 8 Gb image "as is" on the 16 GB stick 7) verify that it installs drivers like the 8 Gb did If it does: 8) extend the filesystem to cover the whole 16 Gb 9) copy (at filesystem level, i.e using copy, Xcopy or similar) to it the contents of the 16 Gb image, overwriting existing files This way the LBA address of the files already existing on the 8Gb stick will (should) remain the same. jaclaz

In case of need (the .qic format has changed in different DOS/Win9x/Me releases): https://web.archive.org/web/20110924215033/http://www.fpns.net/willy/msbackup.htm jaclaz

@Yellow Horror Not that I am suggesting these workarounds as a "standard", but JFYI, it is perfectly possible to boot a GPT disk from BIOS (of course provided that the OS understands GPT disks) with a few tricks (and without making a Hybrid-MBR disk): http://reboot.pro/topic/19516-hack-bootmgr-to-boot-windows-in-bios-to-gpt/ (don't be fooled by the title, several different approaches are used, none of which actually modifies the BOOTMGR) of course only useful in some "edge" or very "specific" cases. Simplest being using the grub4dos UMBR: http://reboot.pro/topic/19516-hack-bootmgr-to-boot-windows-in-bios-to-gpt/?p=197690 but several other possibilities/variations have been experimented successfully. jaclaz

I have not a detail of how much I paid the specific monitor (it was a "bundle" with the PC, that costed, included shipping and taxes, around 900 €) but I have a copy of an offer for a couple of similar monitors of roughly the same period (February 2009): so, very likely it was in the €120-190 range. jaclaz

Converting a drive from MBR to GPT only affects the partitioning type, no changes are made to the filesystems, so there are no issues foreseeable, Whether "Acronis" will do a plain conversion (which is all that is needed) or - due to its "automagical" nature introduce any change, it's hard to say. The only reason why there could be changes to the last partition/filesystem would be if there is not enough space at the end of the disk for the reversed copy of the GPT tables, but it is extremely rare that a "normally" partitioned MBR disk is occupying the whole disk. At the beginning there are no issues, usually the whole stuff goes in 32 sectors, so even the "old" 63 sectors before were enough, and with the "new" default of 2048 there are definitely no issues. A quick check with gdisk would be a good idea anyway: https://www.rodsbooks.com/gdisk/ which can also do a "manual" conversion. jaclaz

What is the "structure" of the USB? I mean does it still contain the .iso or it is "flat" or "semi-flat"? There are/were some issues with the placing of files in large .iso's, but that happened on smaller sizes (like 4 Gb) and were limited to files that were accessed by NTLDR or BOOTMGR, if I recall correctly, and in any case that would provoke a "a file is missing" or "cannot access file", kind of issue, not a "working build" overstepping a driver installation. Depending on how exactly the stick is made you could try making a partitioned stick with two smaller partitions, and use a mountpoint in the first for the second, but it simply doesn't sound a good idea. Maybe - just maybe - something that is happening is that the larger stick *sommehow* is mapped differently by BIOS/UEFI, and it changes disk order? If you boot to the install PE and get to command line (Shift+F10) can you run Diskpart from the two sticks and see if there is any difference? jaclaz

Sure , in every single non-observation the number will be indeterminate, but given a sufficient number of such non-observations the statistical result may (improbably) tend to the irrational number. jaclaz

Well, there is definitely some differences between your experience and the "mass market", 16:10 has been popular since 2003/4 and roughly till 2008/2009 and only later shifted to 16:9, in an "industry move" to unify with TV's: https://en.wikipedia.org/wiki/16:10 You will be happy that the wikipedia page mentions 5:4: Coincidentally, I am writing this on a 2008 16:10 1680x1050 Asus ASUS VW222S : https://www.cnet.com/products/asus-vw222s-lcd-monitor-22/specs/ jaclaz

I thought that as long as you don't look at them quantum pixels would work just fine . jaclaz

Only to provide a single anecdata point. I have a tiny Chuwi 8 tablet paid some 120 Euro or so, dual booting Windows (10, but the 32 bit version) and Android. Honestly it simply works[1], both with the Windows and with the Android. jaclaz [1] for the very limited scopes it is used for, basically browsing the web, no fancy new programs installed on it, no tweaking, changes, nothing, only "stock from factory" software (with the only exception of 7-zip),

To be fair a more extensive one is "broken piece of crap, increasingly more broken at each upgrade/update, broke (again)" jaclaz

Naah. Sometimes the trouble is if the monitor EDID does not provide the correct native resolution (or the windows doesn't understand it correctly) and if the native resolution is unknown or *somehow* forced to a different one, see, as an example of a "queer" case: but your monitor is native 1600x1200 and you run it a the correct native resolution, so nothing to worry about. jaclaz

Which OS? (I am assuming NT/2k/XP or 9x/Me) The easiest would be to use bootpart: http://www.winimage.com/bootpart.htm to recreate a new one. jaclaz

Well, I am sure that it is 4:3. It is native 1600x1200: https://www.cnet.com/products/samsung-syncmaster-213t/specs/ 1600/4=400 400*3=1200 @Rloew Quantum pixels? jaclaz

Yes, we are agreeing, of course noone is going to re-write the existing (and working) .scripts, but the issue/risk I was mentioning is that since (part of ) the Community is ( for the known reasons) ideologically anti-Winbuilder, the risk is that something that could run just fine under Winbuilder will be written on purpose to only run under PEbakery, doing IMHO a not-so-good service to BOTH Winbuilder and to PEbakery, creating more confusion to the "common users" . A "neutral" developer (like Misty) would use such a feature to "better" the experience under both Winbuilder and PEbakery, someone not-so-neutral may leverage on it to exclude or worsen the usage under Winbuilder (while still using its "botched" syntax). About the converter, I thought (maybe wrongly) that for each "Winbuilder command" you had a corresponding "internal PEbakery command", so it should not be so difficult to make a mapping between the "new sintax commands" and your "meta-commands" . I mean, while a "simple" converter would be very likely to introduce bugs or however chosse the "wrong possibility" in case of ambiguity, the capacity of PEbakery of interpreting correctly Winbuilder commands (by creating builds with original Winbuilder .scripts) is a guarantee of the correctness of the interpretation. Of course, there is nothing in itself "bad" about creating new projects, or .scripts (or plugins ) that will run ONLY under PEbakery using the "old" Winbuilder syntax but surely it would make very little sense, if we agree that one of the base main issue is the syntax and not the engine itself (set apart some minor "queer" behaviours and the often cited and mostly fluffy 32-bit vs. 64-bit argument). Another thing that I vote for is (if possible of course) Alacran's suggestion: and (as always only if possible, in due time, etc., etc.) have a detailed list of which parts/subsystems/whatever of .Net are actually needed. In a perfect world the PEbakery should be runnable even in a very minimal PE, so making a reduced .NET subsystem for these cases, or where the running OS for whatever reason has not a full .NET installed would be IMHO a plus (much like what Nuhi did in the good ol'times for Nlite). jaclaz

Not impossible, only very, very improbable. @Mcinwwl The divergence is only in the intended meaning of "common" or "popular" (and - conversely - of "not-so-unpopular") The 5:4 has never been IMHO "common", as it equates in practice to only 1280x1024. Remember we are talking of LCD's native resolution, not resolutions available on video cards. On CRT's, curiously (I presume due to the non-square form factor of the "pixel") the 1280x1024 worked just fine (often even better than the the actual correct resolution for 4:3 that is/was 1280x960) and it is entirely possible that the amount of such resolution we see is partially due to its use on CRT's (besides laptops/notebooks of the time, that AFAIK were very popular at 1280x1024) . This might be interesting (though it doesn't have much pre-2007 data): http://www.teoalida.com/database/screenresolution/ The Author divided some of the sheets in the nice spreasheet: http://www.teoalida.com/database/Screen-Resolution-Statistics.xls into columns 4:3, 16:10, 16:9, Less common resolutions, Weird resolutions, BUT put the 1280x1024 among the 4:3 ones (even if he perfectly knows it is 5:4). Anyway the registered "peaks" at around 17-18% allow us to be both right at the same time , as it is not enough to be called "common", but more than enough to be called "not-so-unpopular . jaclaz

Can you post which specific SCHTASKS.EXE command you used? This command: findstr /c:"[sR]" %windir%\logs\cbs\cbs.log >C:\sfcdetails.txt will write to the file C:\sfcdetails.txt all lines containing the string "[sR]" found in file %windir%\logs\cbs\cbs.log (if any). It is ismply a "filter" to avoid scanning visually the cbs.log for thoise lines. It is the CONTENTS of the file C:\sfcdetails.txt that may be relevant (or it may be not). Please, provide the standard litany: http://web.archive.org/web/20100713063536/http://homepage.ntlworld.com:80/jonathan.deboynepollard/FGA/problem-report-standard-litany.html jaclaz

Really? How queer and surprising! Sure , just like - say - Demotic is much more readable than Hieroglyphs, but the point was about my hope for some new Greek, and JFYI: http://reboot.pro/topic/3380-sounds-arabic-for-me/ http://reboot.pro/topic/3380-sounds-arabic-for-me/?p=24277 BTW, and as a side-side note, the use of external programs, unless you are a computer science guru pontificating on how other people should write programs[1] is just some of the usual fluff, with no merit, there is nothing bad or good in using external programs or in not using them. If an external program exists, does what is supposed to do and does it well, there is no reason to re-implement it internally if not saving a few microseconds or milliseconds. And, as I already said, it is not that having a few seconds savings in a build actually makes that much a difference for the most part of the audience of the builder (while having a language that is simple, powerful and understandable may [2] make a difference). jaclaz [1] I mean programs that actually do something useful. [2] I am an optimist, and I still believe that removing the initial steep learning path (or at least smoth it down a bit) may contribute to have more people involved. :dubbio:

If I may, this is philosophically and philologically "wrong". EITHER PEBakery is (or will become) a "drop in" replacement for Winbuilder OR it is not (and it will not become) one. What I mean is the risk of creating a sort of Winbuilder "dialect" that PEbakery will understand whilst Winbuilder won't, You (Misty) and probably a bunch of other good people will have the sensibility to write (and maintain) their .scripts in such a way that they will work with both builders, but most will "choose" (for whatever reason) the one or the other (or will not willingly choose one but by chance or whatever will adopt the one but not the other) created (if there was not enough of it) some more direct or indirect reasons for divisions and quarrels. Mind you, I am still, in my perverted mind, of the opinion that the full all-round compatibility check for PEbakery, once successful is (or will be) the first step to have in the future a "better" scripting language. The till now exceptionally good syntax interpreting of PEbakery (and the possibility of directly run succcesfully "pure" Winbuilder .scripts) is what makes me hope that it will be able to achieve this goal. Temporarily, and while joveler is refining/completing/debugging it, it is of course fine to use "specific provisions" to workaround any issue, but it shouldn't be something that becomes a "habit". jaclaz

Not only NEC, there are still quite a few 4:3 monitors available, particularly in the high-end/professional sector, examples: http://www.eizoglobal.com/products/flexscan/s2133/index.html Now, current prices for these are not exactly "cheap": NEC EA245WMi (24" 1920x1200) US$ 379 NEC P212-BK (21" 1600x1200) US$ 899 EIZO S2133 (21" 1600x1200) US$ 934.05 There are also still a very few other "affordable" makes/models, besides the "no-name" ones from China, you can still find some "new" Samsung SyncMaster 204B, but I believe they are "unsold warehouse" items. This is a good rant summing up the situation: http://www.inetdaemon.com/q-and-a/why-cant-i-buy-1600x1200-monitor/ jaclaz