Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content count

  • Donations

  • Joined

  • Last visited

Community Reputation

986 Excellent


About jaclaz

  • Rank
    The Finder

Contact Methods

  • Website URL

Profile Information

  • OS
    none specified
  • Country

Recent Profile Visitors

11,621 profile views
  1. In orher words, the US government is the last one to know, and they are pretty much p***ed about this. The interesting part is however the last sentence: The key here is WHICH antivirus software makers were notified several weeks in advance, only US firms or also non-US one, including - only as an example - the not-so-much-appreciated by government's guys Kaspersky Lab? jaclaz
  2. Hmmm. It seems a lot like a (senseless) re-post of a thread by TrevMUN with the date changed. The actual article linked to is actually dated April 12, 2017, and the leading "I'm not even mad, I'm impressed" and ending "pruno-PC" seems waay too distinctive to be a coincidence. So, I don't think that Dang Dong Ho is a bot of kinds (though bots often declare having Vista Business as OS, for *whatever reaons*), as those rarely change the dates, but if it is a human, WHY (the heck) did he made this re-post? jaclaz
  3. Exactly and I would call that a 100% speed increase or driving 100% faster, as you said percentages are (very often) marketing figures. Still OT, and still in the speed/distance realm, the other (often) "vague" (or plainly wrong) figures are averages. Let's say you have a truck. When it is loaded it averages over a distance of 360 km (one way) 60 km/h, on the way back (empty) it averages 90 km/h. A number of people will believe that the truck has an average speed of (60+90)/2=75 km/h. So, I do the same with my car, but I manage to get 72 km/h average both ways. How much slower is the car than the truck? The truck takes 360/60=6 hours and 360/90=4 hours on the way back, total 10 hours. On the way to the remote location, my car takes 360/72=5 hours, and on the way back another 5, total 10 hours. jaclaz
  4. Let's talk cars. If you covered a distance of 90 Km in 1,5 hours, you drove at an average speed of 60 km/h. If (on the way back) you covered the same 90 km in 1 hour you drove at an average speed of 90 km/h. Were you 1h/1.5h=66,667% faster (than what) or were you 90/60=1.5 i.e. 50% driving faster (than 1)? jaclaz
  5. I would say that 2.141 s is 75% faster than 3.752 s, while 2.141 s represents 57% of 3.752 s. (if fast/faster go with speed, not with time taken) Anyway 82% seems off. jaclaz
  6. [VESA]UniGFX Graphics Driver

    Sometimes an image is worth a thousand words ... https://ravingreader.files.wordpress.com/2016/07/good_gnus_bad_gnus.jpg?w=584 jaclaz
  7. [VESA]UniGFX Graphics Driver

    In other words, no news. jaclaz
  8. Maybe mobius, definitely not moibus, actually either Möbius or Moebius: https://en.wikipedia.org/wiki/Moebius jaclaz
  9. Bootable Windows Embedded

    From OSCDIMG help (the -j1 is the switch that allows to re-create the image, with exactly same size): The issue with IMGBURN is not - I believe - actually with the joliet part, that seems just fine, but rather with the 8.3 short names. The Joliet "Program Files" is shortened by IMGBURN (when character set is set to either "Standard" or "Dos") to "PROGRAM " and the "Common Files" in it to "COMMON F". OSCDIMG abbreviates them to "PROGRAMF" and "COMMONFI" respectively. From your test (since it works) mkisofs should be making the same shoirt names. It is possible that there is a particular set of settings in IMGBURN that can make the same, but I couldn't find them in my brief tests. I'll try some more. jaclaz
  10. Bootable Windows Embedded

    Sure , it is well understandable, anyone who can afford a system engineer (or similar) will be able to get much more "operational features" from either WES or WEE, even on a Pos, the whole accent of PosReady is on the "Ready" part. IMHO "previous" version of Windows Embedded were (still are ) so mind§@ç#ingly difficult to build properly[1] that in typical MS style the geniuses at Redmond created the "simplified" PosReady which should actually be called PosHalfReady, BUT they couldn't anyway provide a simple way to actually make it "Ready" for anything (see the issues here with re-building the .iso, the non-standard - or however different from known layout and "queer" ways to add drivers - the "strange" unattended.xml location, etc. ). If anyone can make sense of the advantage of having a componentized version of Windows XP without almost any possibility to choose the components, PosReady2009 is exactly the right product. jaclaz [1] until you went through several tens of failed, or incomplete or however not fully working builds, tens of pages of (mis-)documentation, a couple hundred threads/posts on the various "official" support boards, where usually clueless MVPs fail to answer properly the same questions asked by final users finding the 1 in 20 or so that actually solves the problem at hand.
  11. Bootable Windows Embedded

    As often happens I have good news and bad news. The good ones are that seemingly (but you will have to test it, I just checked that setup autoran, without going through the installation), the "right" way to re-burn the image is through MS's own OSCDIMG, using this syntax: oscdimg -lPOSRDY -j1 -h -o -bD:\TestNew2009iso\Bootable_NoEmulation.img F: D:\TestNew2009iso\test2009.iso In the above: D:\TestNew2009iso\Bootable_NoEmulation.img <- is the extracted bootsector F: <- is the source, in my case is a drive letter as I mounted the original as CD image with imdisk, in your case should be the root folder where the files are extracted from the original CD image D:\TestNew2009iso\test2009.iso <- is the path and name to the image that it will be created The bad news are that - at least for the moment - the above is also the "only" method to create the .iso The issue is not about the bootsector, as said with the proper settings in IMGBURN the .iso boots just fine, it seems connected to the "queer" mix of ISO9660 "standard" (and its editions and "common violations" to the standard) and file/folder renaming. At first sight the OSCDIMG and the -j1 switch create non-standard short names (or however different from the ones OSCDIMG creates). A couple examples: Program Files <- (Joliet) becomes in the ISO9660 part "PROGRAM " (that is PROGRAM followed by space) in IMGBURN, while it becomes "PROGRAMF" with OSCDIMG \Setup\Microsoft.Embedded.Setup.Data.POSReady.dll is \SETUP\MICROSO2.DLL with IMGBURN BUT \SETUP\MICROS_2.DLL with OSCDIMG Loosely it is similar (but at first sight not exactly the same) issue we found a lot of time ago, here: https://msfn.org/board/topic/171435-allow-lowercase-on-multiboot-dvd/?do=findComment&comment=1073289 https://web.archive.org/web/20151007005513/http://www.911cd.net/forums//index.php?showtopic=25612 I am attaching (since 911cd is lost) the dashun9 little batch, just for the record. Now if you have (and/or can use) the OSCDIMG which you can get it from *any* 7 or later AIK/WAIK, or easier, using the nice GetWaikTools program: (the 7 version runs on XP just fine), I would tag this whole stuff as a glitch in the matrix and be fone with it. Maybe - just maybe - it is possible to use mkisofs (or similar) with some peculiar settings, even if I doubt it but IMGBURN (and similar ISO making programs) most probably can be used only with some post-processing of the created iso image. It is simply not worth the effort, if you can do with OSCDIMG (and if it works). jaclaz dashun9_01.zip
  12. Bootable Windows Embedded

    Hmmm? The one I have is seemingly a "plain" XP .iso, with an \i386 folder with the usual set of "flat" files, including setupldr.bin. BUT with a Setup.wim (not boot.wim, not install.wim) that is seemingly used by setup. Quickly pressing *any* key when the setup loads, opens a "normal" WinPE command prompt, the .chm says: The unattended.xml needs seemingly to be inserted in the \Setup folder Additional drivers can be added either via F6 or using an XML driver file, the actual driver files don't go in any .wim. @swain90 There must be some incompatibilities in the way IMGBURN creates this image (or in some of the settings). I did a quick test (recreating with IMGBURN the CD without changes, using the original mounted in Imdisk as source and using the bootsector extracted with 7-zip) in a VM, and if I press (really quickly) *any* key at the Setup Launcher fase, I can get to a working command prompt, but setup itself fails, I'll have a look at it and (hopefully) provide you with a replicable *something*. jaclaz
  13. IE 8 in 2018?

    Just in case , standard litany: https://web.archive.org/web/20160604095422/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/problem-report-standard-litany.html jaclaz
  14. How to install Windows 7 from USB 3.0?

    ... which creates the questions: Is it possible (and if yes, how) replace the wdfldr.sys 1.9 with a newer one? Is the "newer" backwards compatible with the wdfldr.sys 1.9? Or in other words, is there a way to "update" the boot.wim and install.wim in such a way that is compatible with both "old" anf "new" drivers using the co-installer (regardless if they are these specific VIA USB 3.x drivers)? jaclaz
  15. Looks like a Conexant modem. (ISDN? ) If you don't use it, it would make IMHO more sense to just disconnect/remove it. jaclaz