jaclaz

No prob whaetever , I am sending him a link to this thread . jaclaz

What about hiring a programmer/IT expert? He/she would be able to easily accomplish the requirements, BUT he/she would also most probably tell the customer that a PE is not intended (and is not licensed) to be an OS replacement and would probably suggest the use of one of the "embedded" editions of Windows instead, which is what is used generally for Kiosk-mode PC's or otherwise suggest the use one of the several tools available to have "a computer that can not be messed with" running a "normal" version of Windows. jaclaz

Dave-H, the experiment is about a non-standard, border-line (or possibly even beyond the border ), crazy partitioning scheme. What you will see (or not see) in Disk Manager is or can be either accurate or totally inaccurate, but this has NO real meaning, what matters is whether both volumes (the smallish FAT12 one and the largish NTFS one) are accessible BOTH when connected to the 512 bytes/sector interface and when connected to the 4096 bytes/sector one. Running the switcher.cmd, even if the bootsector of the NTFS partition is already the "right" one should allow to make sure that a drive letter is assigned to th eNTFS volume (while a drive letter should always be assigned automatically to the FAT12 partition at connection time), in other words the idea (once/if everything goes as expected) is that these "dual mode" disks should never need to be viewed or "touched/modified" in Disk Manager. As I asked you before, do you have an XP to which you can connect the disk once as 512 bytes/sector and as 4096 bytes sector? If yes, can you try running the switcher command and verify that you can access both drives on both the interfaces? Explanation, being it so border-line, it is possible that: 1) the scheme only works on XP in my virtual environment and not in your real one 2) the scheme only works for some sizes of the parititons volumes 3) I have still some errors in the batches and what you get is different from the expected result 4) once we have determined that (hopefully) you can reproduce what I get here on XP, then it is entirely possible that the same scheme (for *whatever* reason) does not work in 8/8.1 (and we will need to use one of the alternative scheme(s)), but since - more or less - the "building engine" is ready, it will be easier to experiment with these alternative schemes. I have NO WAY to attempt reproducing in my "virtual" environment such big sized partitions, can you please try reducing the sizes (just for the test) in order to see if the batches on your system (and on XP) can reproduce a Disk Manager view similar to the one I posted on #138? I have to understand if the batches can produce on your real environment what they produce in my "virtual" one, next thing, also it is extermely difficult for me to understand from the results you post on which system/OS/Connection is run what. As I have understood it (correct me if I am wrong) you have 8 possibilities, i.e. 2 systems, 2 OS, 2 connection modes, let's call them: PC1XP512 PC1XP4096 PC181512 PC1814096 PC2XP512 PC2XP4096 PC281512 PC2814096Can you add the information on which system/Os/Connection either the output of the batches or the Disk Manager view belongs to? jaclaz

Yep, you are correct of course , the idea (in my perverted mind) was to have reports on what happens if the batch is run by a non-admin. I have NO idea if the UAC/elevation prompt "triggered" by the elevate.exe happens at all or if it allows to change user (if the right Administrator credentials or supplied) or what else. Let's call it for the moment a "place holder", that can be either removed altogether (because it is pointless) or reversed to something *like*: whoami /groups | find "S-1-5-32-544" >nul || ECHO Wait a minute I cannot elevate from non-admin&&PAUSE&&GOTO :EOFjaclaz

This is "queer". Look ATTENTIVELY at the screenshots I posted earler: http://www.msfn.org/board/topic/173265-formatting-an-external-drive-using-different-interfaces/page-6#entry1094034 The one "on the left" is related to the disk mounted as 512 bytes/sector and shows: a primary FAT12 partition 7 Mb in size (i.e. the size I used in mkprilog.cmd) between the above and the below the "fake" unallocated a logical inside extended NTFS volume the size I created it (i.e. around 73 Mb) The one "on the right" is related to the disk mounted as 4096 bytes/sector and it shows: a primary FAT12 partition 54 Mb in size (i.e. the size I used in mkprilog.cmd multiplied by 8) a logical inside extended NTFS volume the size I created it (i.e. around 73 Mb) immediately following the aboveCan you try again, this time giving 7 Mb as input in the mkprilog.cmd and creating a NTFS partition of 73 Mb? (this way the disk manager views in XP should be similar to the ones I obtained) I am starting to think that for *some* reasons (my fault *somewhere*) the batch(es) make a mess with the size and location of the FAT12 partition , i.e. when I multiply the size by 8 I am doing it wrong or doing it without checking if needed or not (when making last modifications I must have copied over unwantingly a "test" setting ). I'll recheck ... jaclaz

I think there are TWO (or more) concurring issues, one is how the BIOS enumerates the disks (when compared on how the actual ports are marked on the motherboard) and the other is how the booting OS reads these BIOS mappings and assign them to NT objects and whether these mappings are "constant" or change depending on some BIOS settings and/or by the actual contents of the disk (like -say - silly things in Windows like the "system" - which means "boot" - volume, priority to MBR vs. GPT disks or viceversa, and the like). Example (to simplify), a simpler system with two internal disks, connected - say - to SATA0 and SATA1 ports (as marked on the motherboard). If in BIOS you select something like "boot from first hard disk" you will likely have this situation in SATA port/BIOS/Windows Disk Manager: SATA0=DISK 128=DISK 0 SATA1=DISK 129=DISK 1 BUT if you select something like "boot from 2nd hard disk" in BIOS, you will likely have this: SATA0=DISK 129=DISK 1 SATA1=DISK 128=DISK 0 AND if you add to the equation (say) a booting from USB device such as a USB stick, it is likely that you will have something *like* USB0=DISK 128=DISK 0 SATA0=DISK 130=DISK 2 SATA1=DISK 129=DISK 1 OR: USB0=DISK 128=DISK 2 SATA0=DISK 130=DISK 0 SATA1=DISK 129=DISK 1 OR: USB0=DISK 128=DISK 2 SATA0=DISK 130=DISK 1 SATA1=DISK 129=DISK 0 What -X- may want to experiment with (provided that it really there is a *need* for this "matching" ports with disk numbers ) would be to pre-boot to grub4dos and re-map disks in it (which plainly means re-mapping the disks in the BIOS table) and see if the Windows Disk Manager numbering is affected by this. jaclaz

Hmmm, try checking what happens now in the Windows XP. Before you run the mkdualdisk.cmd the second (NTFS) partition is mapped as a Primary partition (which you just created). Once you run the mkdualdisk.cmd that same partition is re-mapped as a logical volume inside (fake) extended partition, but most probably the situation is not updated until you disconnect and re-connect disk. It is perfectly possible that the stupid Windows 8/8.1 somehow does not accept this "abnormal" partitioning scheme but I am not yet fully convinced of this, while it is entirely possible that the switcher.cmd does not work because of this missing pre-requisite (the Windows 8.1 not "seeing" the logical volume). Or, try doing the following: in Windows 8.1 re-start from the "dsfi \\.\PhysicalDrive1 0 0 PriLog.img" still in Windows 8.1 re-create and format the NTFS partition reboot to the Windows XP (it should not matter if the disk is connected to the XP through the 512 or 4096 bytes/sector interface) and run from the XP the mkdualdisk.cmd and copy to the first (FAT12) partition the switcher.cmd (and related files) try to run the switcher.cmdWhat happens? jaclaz

dude? hit and miss game= if something doesn't work, try something else [1] jaclaz [1]maybe this *something else* will work, and sometimes it won't, no way to say in advance .

Yep, sometimes it is just a hit and miss game you'll need to try with *something else*, ideas: http://alternativeto.net/software/httrack/ jaclaz

JFYI, it is perfectly "normal" to have failed/missing dependencies while having a seemingly fully functional app/tool (which can either be actually fully functional or only seemingly so), a .dll dependencies can be either "implicit" or "static" (i.e. declared as a needed function in a given .exe) or "dynamic", i.e. being not declared in the .exe but being needed/called by one of the "static" dependencies or even be "dynamic-dynamic" i.e. called by a "dynamic" dependency and only upon execution of a given function. There are tools that *seem* to need everything (and the kitchen sink) when examined in dependency walker and even more so when profiled in it that continue merrily working 100% with several of them being not present on the system. As an example I guess that 95 to 99% of all apps appear to be missing MSJAVA.DLL or similar (see FAQ's) on XP: http://www.dependencywalker.com/faq.html As explained there, a number of missing .dll's in a dependency walker windows can be (and often are) "false positives", this is inherent to the way dependency walker analyzes (or traces) the file at hand. The flaw (if any) is in the stupid way the whole architecture was created, which includes the known issues about so-called DLL Hell: http://www.desaware.com/tech/dllhell.aspx http://www.drdobbs.com/windows/no-end-to-dll-hell/227300037 http://en.wikipedia.org/wiki/DLL_Hell which BTW is largely caused by programmers (besides some limits in the compilers) that never, or almost never think a bit whether it would be better to make statically linked builds or plainly re-write the needed function inside the .exe instead of creating a link to a trivial function in a misknown/uncommon .dll, and to this you can add the terrible (I cannot find a better word to describe it ) workarounds that were later created to mitigate the issues, that - like the pure folly (again I have no better terms to describe it) WinSxS is, and that can create more issues that they can resolve: http://www.davidlenihan.com/2007/07/winsxs.html http://blogs.citrix.com/2011/04/21/history-of-dll-hell-and-why-it-will-repeat-itself/ jaclaz

Maybe wget is simply not suited for the task at hand and a more "comprehensive" approach is needed, *like*: http://www.httrack.com/ jaclaz

As Requested .. ~DP Good It is still to be determined if it makes more sense to have just two three "categories": Xp or 2003 (conventionally pre-Vista ) Vista or later up to Windows 10 this must be a crappy new OS or differentiate them in three four of them: Xp or 2003 (conventionally pre-Vista ) Vista or later up to Windows 8.1 Windows 10 this must be a crappy new OSBut I guess that since it is a batch and essentially the only needed mod (apart the check for "crappy new os" that I completely forgot to put originally in the thingy) everyone will be able - depending on the specific need to modify the FINDSTR argument and corresponding ECHO lines and add/remove checks for specific OSes, as anyway the "final scope" of the small batch is to provide a "reference" for use in batches that need elevation to do their work, such as the one(s) that prompted for putting together the testelev.cmd : http://www.msfn.org/board/topic/173265-formatting-an-external-drive-using-different-interfaces/ http://www.msfn.org/board/topic/173265-formatting-an-external-drive-using-different-interfaces/?p=1094177 jaclaz

Well, you cannot really attribute for sure the fault to dscrypt. It is possible that it is actually the culprit, but a whole lot of other possibilities exist, including "permanent" issues in the actual hardware (a usb stick if I get it right) or "transient" ones (at the time the files were written) which could e attributed as well to the hardware, but also to the drivers or more generally to the OS or filesystem. As always the issue is the lack of a "plan B" (B stays for Backup ) which is always a good idea, it is very important when managing "unreliable" (no offence intended to all the good guys that make USB sticks, of course) media[*] and even more so when dealing with encrypted data. The whole point that the good guys that make encryption software and the users of such tools often miss (because it is outside their "main" scope of securing contents) is that the file format (like *all* binary formats, but much more than average with encrypted files) is intrinsically extremely fragile, a single byte (actually bit) corruption, for any reason, and bam, you have nothing at all So the next step would be to make a dd-like image of the stick "as is" (better if two, one to work on and one as backup) and then first check if the issue is in the actual media or filesystem, but - to be honest - unless it is a trivial issue in the filesystem, there are very little chances that the contents of the file can be recovered. jaclaz [*]If you think about it, they are extremely reliable, but essentially you carry all day long in a pocket together with keys, coins and *what not* a teeny tiny device, that is thus subject to each and every possible mechanical shock as sometimes it falls on the floor, which open connector may be contaminated by *any* kind of dust, that you insert periodically in any (low) powered USB outlet you can find and that can happen to be "surprise" disconnected or machine washed together with your trousers etc., etc., as a matter of fact it is IMHO a miracle that these little devices tend to work notwithstanding the tortures to which they are subject.

And the OS will re-assign DRIVE letters (which DO NOT belong to this topic) according to the known MS "lettering rules" depending on the way both DISKs are enumerated (which is the actual topic at hand) and on the type/order of volumes/partitions in them (which is NOT the topic) The way DISKs (which is the topic) are enumerated depend essentially by BIOS but in latish (Vista an later OS's) they are in some combination of BIOSes/DISK types pretty much "hectic". Reviewing quickly dictionary: a DISK is NOT a "drive", a DISK is "the whole thing", i.e. anything which first sector is a MBR (or a GPT), and it is accessed \\?\Device\Harddiskn\DR0 or as \\.\PhysicalDriven (should it be not confusing enough) a DRIVE is the *whatever* Windows NT can mount by assigning to it a DRIVE letter to (which is a volume - see mountvol - or a partition - which is also a volume) i.e. *anything- which first sector is a bootsector (or PBR or VBR), and it is accessed as \\.\<drive letter:> (if mounted to a drive letter) or \\?\Volume{GUID} and if residing on a hard disk like device also as \\?\Device\Harddiskn\Partitiono or \\?\Device\HarddiskVolumepHTHM. jaclaz

Well, NO. The issue talked here has NOTHING to do with DRIVE letter assignment (which in Windows NT systems can be easily managed) BUT is all about DISK order, which is another thing. jaclaz

Good , so the "S-1-5-32-544" and "S-1-16-12288" remained the same and the version is at the moment 10.0, so this should do: VER | FINDSTR /i "10\.[0]\." > nulIF %ERRORLEVEL% EQU 0 (ECHO Windows 10 ...whoami /groups | find "S-1-5-32-544" >nul && ECHO OK, I am a local admin ...whoami /groups | find "S-1-16-12288" >nul || ECHO I am NOT running elevated, BAD.&&GOTO :do_elevateFSUTIL DIRTY QUERY %systemdrive% >nul || ECHO ... wait a minute, I need elevation anyway&&GOTO :do_elevateECHO ... and I am running elevated, good.PAUSEGOTO :just_do_it)ECHO NOT Xp/2003, NOR Vista and later up to 10.0, this must be a crappy new OS...exiting...&PAUSE&GOTO :EOF@DosProbie Can you try adding the above snippet just above the ":just_do_it" label and re-test? @Yzöwl Or maybe something *like*: would be better? But then what if the good MS guys decide that Windows 11 will be 10.3 and change the Admin/Elevated SID's? jaclaz

OK, let's see if this version works. (0.06 09 February 2015) Please do re-read ATTENTIVELY the readme.txt AND any output/feedback given by the batches. jaclaz mkprilog.zip

Possibly you can find here something of use in your case: http://www.msfn.org/board/topic/127790-silent-net-maker-synthesized-20100118-w2kxp2k3-x86/ jaclaz

Well, post the FULL error, AND the specifications of BOTH the OS (I presume Windows 7 and have to guess that it is a 64 bit version of it) AND of the hardware, SPECIFIC make/model, etc. Usually that error is connected to EITHER a "bad" device driver OR the one or the other Antivirus (but of course it may be a defective peripheral, like - say - the network card or the video card). Until you provide the needed, basic, info and details, as per Standard Litany: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/problem-report-standard-litany.html be my guest : jaclaz jaclaz

...and it wouldn' t even be that much a completely "new" idea, that is more or less what the good Apple guys have done in recent years for IOS (but not for OSx, which they keep as two completely different and separated OSes/platforms/whatever) A decision that seems to me like slightly more intelligent than the "Thou shalt have a same OS on ALL devices" the good MS guys are trying to inscribe on the tables (tablets ? ) of the Law as 11th Commandment. jaclaz

Which is good , as another confirmation how stupid the stupid Windows 10 (which at the moment of this writing is a NON-released new, experimental OS) actually is. When (if) it will be released, then - maybe - we will be able to see what are the results in that stupid environment of the "base" commands used in the batch and hopefully there will be some official documentation about the stupid changes that are/will be implemented in it. If you could post the output of running the VER and of the WHOMAI /groups commands in it, I could add a few lines *like* : VER | FINDSTR /i "6\.[4]\." > nulIF %ERRORLEVEL% EQU 0 (ECHO You are running a stupid OS, we cannot cure that, sorry .GOTO :EOF)More seriously, add just before the ":just_do_it" label a line *like*: ECHO NOT Xp/2003, NOR Vista up to 8.1, this must be a crappy new OS...exiting...&PAUSE&GOTO :EOFAnd experiment with adding something *like*: VER | FINDSTR /i "6\.[4]\." > nulIF %ERRORLEVEL% EQU 0 (ECHO Windows 10 or whatever, ...whoami /groups | find "S-1-5-32-544" >nul && ECHO OK, I am a local admin ...whoami /groups | find "S-1-16-12288" >nul || ECHO I am NOT running elevated, BAD.&&GOTO :do_elevateFSUTIL DIRTY QUERY %systemdrive% >nul || ECHO ... wait a minute, I need elevation anyway&&GOTO :do_elevateECHO ... and I am running elevated, good.PAUSEGOTO :just_do_it)in the same place, before the added "ECHO NOT Xp/2003, ...". I am assuming in the above that the windows version reported is 6.4 and that the whoami/groups output has not changed, but have no way to check these assumptions. jaclaz

Like the ones I have in blackbox since - still say - 2005 or 2006? http://www.msfn.org/board/topic/172826-windows-10-first-impressions/page-3#entry1088850 Though I personally find them a very nice feature , it's hard to sell them as "new"... jaclaz

Yes and no. Coming from someone that still runs a couple NT4.00 and 2K machines (connected to the internet) 24/7 365 days a year and whose "main" PC, also connected to the internet runs XP Service Pack 2 (with a bunch of selected updates - but not that many), yes traditionally a large number of updates are not really-really *needed*, but no , there is the actual need of a properly configured setup (like a good firewall (hardware) and similar) and that would IMHO count as "safety nets". As I see it is more about responsibility, if (when or if and when or when and if ) I will get some nasty malware (or *whatever*) I will blame myself (and noone else) for having being not capable of preventing/filtering it, whilst most people would prefer in the same situation to blame someone else, like, you know : jaclaz

No prob, with these (lately) few hiccups of the board it is easy to get "out of sync" . So, it seems like the thingy - at least in 8.1 - is working fine. jaclaz

Yep beauty is - as always - in the eye of the beholder, to me 200 Mb for a stupid program, half-way between a database/library and a backup/restore tool is like 199 Mb too much. , but you will find a lot of people calling that crazy amount of bloat "only". jaclaz