Jump to content

jaclaz

Member
  • Posts

    21,300
  • Joined

  • Last visited

  • Days Won

    53
  • Donations

    0.00 USD 
  • Country

    Italy

Everything posted by jaclaz

  1. Yes , this is needed only if you boot form a hd-like device, such as a USB stick or external hard disk. To the numbered points: 1. *any* file, the idea is just to have a file that you can see with the ls command (in order to make sure that you are on the "right partition". I suggested a (can be an empty file or a text file containing something like "Hello peeps! ") named "thisis_64_bit_part.txt" but you can use any. I guess an explanation needs to be made. You are used to see partitions on the disk through Disk Management which shows them as a graphical map of the hard disk, i.e. representing them as a "stripe" with the beginning of the disk on the left and the end on the disk on the right, and with the various partitions represented in the order they occupy on the hard disk. I will try to be more clear, the "first" partition in disk manager is the partition the occupies the first part of the disk (leftmost), "second" is the one to the right of it, etc, etc. BUT a number of other addressing methods for partitions use NOT their position on disk but INSTEAD the position of the corresponding entry in the partition table. The partition table has 4 "slots" or "entries" for writing partition address data (let's for the moment set aside Extended partition and Volumes inside it). These entries are numbered, in grub4dos: #0 is first partition entry #1 is second partition entry #2 is third partition entry #3 is fourth partition entry it is perfectly possible (and happens more often than not, and especially when a "Recovery" partition is involved in the setup) that a partition entry does NOT correspond to the order in which it is placed on disk. Example, your "Recovery partition" may well be written to partition entry #0 BUT being placed at the END of the disk, OR, in one of the changes made in the past on the disk partitioning, entry #1 could be empty. So a sensible thing to do (better be safe than sorry) is to check which partition corresponds to a given partition entry. In grub4dos making a given partition (in the sense of the partition whose address data is written to a given partiion entry) root and then check which files are on it with ls is a quick way to make sure that you are dealing with the "intended" partition. 2. I am not sure to get the "meaning" of the question, right now, from what you report you have three partitions: the Recovery partition (which is already hidden, otherwise your first - 32 bit - XP install would have NOT gotten the C: drive letter) the partition (non hidden) where you have already the XP 32 bit installed (that you need to hide when installing the XP 64 bit) the partition (non hidden) where you are going to install the XP 64 bit (that needs to remain non hidden in order to install to it) 3. Yes and no. NO, as a matter of fact we are going to use grub4dos simply as a MBR partitiion table editing tool, you can do the same booting from a DOS floppy with (say) MBRwizard, or from a PE and using MBRFIX or *any* disk editor. grub4dos is simply more handy as it is easily bootable (from CD/DVD in your case), has NTFS read access, has direct (and IMHO simple/linear syntax) MBR partition table access. YES, the idea is to NOT touch the MBR (i.e. NOT writing the grldr.mbr to the MBR AND following few sectors) because this may cause the impossibility to boot again the Recovery partition. The "enhancement" (let's call it "difference" ) with the solution proposed by submix8c is that in his solution grub4dos (still NOT installed, but called/invoked through the renaming of the files approach) the grub4dos becomes a "permanent" part of the booting sequence, whilst in the one I proposed grub4dos is just a tool to manage the MBR partition entries at install time. If something is not really-really needed I find it better to NOT make it a key step of booting "forever", though nothing prevents from (as an eaxample) haveing grub4dos as a "third option" in the BOOT.INI. I am FIERCELY against the concept of the RENAMING of the files (still better be safe than sorry) before or later it could happen that because of you, or a stupid windows update or anyway *somehow* the NTLDR file (which is a grldr under false name) is overwritten (or that some stupid software checks that NTLDR is actually the real NTLDR or whatever) creates an unbootable system or some other "damage" (additionally the renaming of the grldr may cause issues in more recent grub4dos builds) The original idea of renaming was by spacesurfer: http://www.911cd.net/forums//index.php?showtopic=18031 but later it was (hopefully) "bettered" by this: i.e. by changing the filename invoked by the bootsector, so that files kept their original names. 4. There is NO provision in Disk Management to hide/unhide partitions AFAIK. Why do you think there are so many "third party" tools to manage the MBR? You will find tens of (wrong ) references about Diskpart being capable of hiding partitions, while most the connected commands are about assigning or removing the assignment of a drive letter to a volume, example: http://forum.thewindowsclub.com/windows-tips-tutorials-articles/31678-how-hide-show-your-hard-drive-partitions-using-diskpart.html There is however a way is to set a given ID to a partition, this is a RIGHT example: http://defaultreasoning.com/2009/05/29/unhide-the-recovery-partition-on-a-basic-disk-with-diskpart/ Basically (at least for MS "recognized" parition ID's) any partition ID that begins with 1 means that it is a hidden partition of the type ID-10, like: 16 is a hidden partition ID 06 17 is a hidden partition ID 07 etc. About backing up the MBR, we are before a doubt. To backup ONLY the MBR the easiest would be a GUI tool, such as HDhacker: http://dimio.altervista.org/eng/ the MBR is the first sector of the \\.\PhysicalDriven (n is the same as DISK #-1 in disk management or diskpart, i.e. first disk is \\.\Physicaldrive0, second disk is \\.\PhysicalDrive1, etc) BUT in your case we don't know whether the "Recovery partition booting mechanism" relies on: the MBR only the MBR and *some* hidden sectors the MBR and all (normally 62) hidden sectors, i.e. first 63 sectors none of the above and the code is in the BIOS To be on the safe side I would backup: only the MBR the whole first head (63 sectors) the whole set of hidden sectors (if not 63) using a command line tool like dsfo (part ot the dsfok toolkit): http://members.ozemail.com.au/~nulifetv/freezip/freeware/ the corresponding commands would be (choose the "right" n, for the first two : dsfo \\.\PhysicalDriven 0 512 C:\mymbr.bin dsfo \\.\PhysicalDriven 0 32256 C:\myhid.bin for the third one you need to check how many hidden sectors you have (normally in a disk partitioned under XP is 63, but if it has been partitioned in Vista or later this number maybe different, normally 2048) To check them quickly you can use the partition editor here (dtidata partition repair tool): http://www.dtidata.com/ntfs_partition_repair.htm http://www.dtidata.com/free_data_recovery_software/dtidata_partition_repair_tool.exe 99.99% you will have a partition with "Rel Sectors" (i.e. "hidden sectors" or "sectors before" or LBA offset of partition) of 63, in the 0.01% in which this does not happen, you will need to multiply it by 512, example for 2048 sectors 2048*512=1048576 and thus: dsfo \\.\PhysicalDriven 0 1048576 C:\myhidall.bin Take your time digesting the info, maybe I pushed too much in a single post.... jaclaz
  2. Look, I don't want to seem grumpier than I normally am , but the idea is that you come here for help because you cannot solve an issue by your own. You are here asking for advice. The advice is: there is NOTHING you can do on that disk, if not, maybe, salvage the data on it, whilst updating it's firmware will VERY LIKELY brick it for good, DO NOT, for ANY reason, attempt updating the firmware. Besides it is written all over the place that: NO hard disk is "safe" ALWAYS make backups (possibly more than one) DO NOT EVER "trust" a hard disk and NEVER, EVER one "revived" after unbricking with this method NEVER update firmware on any disk that does not pass BOTH the short and long Seagate tools test You cannot seriously come here saying that: you don't have a recent backup of the data you don't have a recent backup of the data of a disk that you have unbricked with this method you think that upgrading the firmware will solve the issue If you REALLY think that upgrading the firmware will solve the issue, then go on, do it , BUT don't come back whining that the disk bricked itself/became completely inaccessible. jaclaz
  3. Your disk is most probably gone (for good), unfortunately. This thread (and also the very limited knowledge we have) is ONLY about BSY or LBA0 issues, and NOT about ANY other issue. Use the Seagate tools on the disk to diagnose it, BOTH the short and long test, if it doesn't pass either, your disk is "gone". I hope that - since you already had this issue happen - that you have a backup of the Data, otherwise, procure yourself another disk and try imaging the failing disk as soon as possible BEFORE running the tests, if you are lucky you will be able to do that before the disk dies. jaclaz
  4. To translate Charlotte's post in plain English: Hoko, you SUCK at taking photos! AND Charlotte's eyesight is not as good as it once was! The Jumper J1 is (on the manual AND in the photo) EXACTLY where it should be. (Yes, it's the right one for AGP video). jaclaz
  5. @Ponch Here we have a "third" factor which is the Recovery partition. Until the exact nature (and booting/accessing mechanism) of it is ascertained, changing the MBR CODE is NOT a suitable solution , hence the suggestion to use a selection mechanism outside and beyond the MBR. Risks connected to overwriting the MBR code (in the case it uses a proprietary solution like the mentioned "Softthinks") are detailed here: JFYI, among the "self contained in the MBR only" bootmanagers, the current state of the art is (and it is since years) MBLDR: @androemda43 Only to counterbalance your report, I have run for several years a multiboot PC with: DOS (6.22) Windows 98 SE Windows 2000 (actually TWO installs of it) Windows XP without a single itch/issue/problem whatever (and each OS - within it's filesystem/addressing limits - could "see" the other installs). Certainly the multi-boot setup was accurately planned, and it is very possible that Windows 7 may have issues with XP, but I do have a couple system where there is Windows 7 installed as "main" system AND there is an XP "service" partition (and each can see the other) where I have had not (yet) any issue whatsoever, time will tell. I have run for years double boot XP+XP and never had a single issue, so unless you know for sure that there is some issues for XP32+XP64, your recommendation of preventing them to "see the other" seems overcautious (and in any case Dogway is going to have them NOT "see the other"). jaclaz
  6. Actually also DURING and AFTER it, until Me. The NT family was/is another thing..... jaclaz
  7. What happened is hard to say, but from what you write it is possible that the disk has NOT been damaged (much) All modern hard disks have a kind of "fuse" (actually two of them, one on the 5V and one on the 12V ). They are not actually "fuses" as we normally know them, if they are triggered they short to ground. Technically they are called TVS diodes, see: http://en.wikipedia.org/wiki/Transient-voltage-suppression_diode If the TVS(s) worked as they should have been: when the disk is powered by a "proper" power supply (with short protection) the effect is that the PC won' t start at all or very quickly shut down. when the disk is powered through an (usually el-cheapo) external power supply such as those you find in external cases and "SATA/IDE adaptor", which have not such protection the effect is that the power supply fries . So, maybe, you are lucky and you just fried the sata/ide adapter power supply because the disk protection actually worked and the TVS (either or both of them) shorted the power to ground. If this is the case, besides getting a new power supply for the adapter (or buy a new complete set, most probably cheaper) all you need to do is to verify that the TVS are shorted (any common multimeter will do) and remove them (by desoldering them or CAREFULLY prying them out of the disk PCB). Please consider that without the TVS's in place the PCB has NO protection against overvoltage/overcurrent, so the idea is first get another new hard disk and use the old one in this unprotected setting ONLY for the sheer time needed to image it over the new one. Later, and depending on how cheap you are, you may think to get a couple of TVS diodes from another disk you can find as scrap and re-solder them. It is fairly easy to "spot" the TVS(s) on a PCB, example: If you need help in finding them, post a picture of the PCB. jaclaz
  8. The cause for the issue is to be detemined, but the actual effects can maybe be mitigated. Right now the issues (effects) are that: you cannot boot win "normal" mode (because the system crashes) you can boot to safe mode BUT the shell doesn't load (fully), i.e. you get the desktop and Explorer is running BUT you have no Start button/tray Your next attempt could be that of attempting to load an alternate shell (winfile) to see if you can boot in safe mode (and from it do what rloew suggested). Try following this: http://www.mombu.com/microsoft/windows-98-general/t-windows-starts-but-no-start-button-desktop-image-only-229791.html jaclaz
  9. What I care to stress about is that NO such thing as an EISA partition exists (if not in the perverted mind of the good MS guys) since something like 25 years (and actually never existed as a "standard"). EISA is (was) an update/extension to the ISA bus: http://en.wikipedia.org/wiki/Extended_Industry_Standard_Architecture On some machines equipped with that bus, a "hidden" partition containing the configuration utilities was created. This partition had a partition ID of 12 which has NEVER been tagged (if not by the good MS guys) as EISA, as a matter of fact everyone know (knew) it as the Compaq Diagnostics partition: http://web.archive.org/web/20030411231940/www.powerquest.com/support/primus/id233.cfm http://www.ctyme.com/intr/rb-2270.htm (Compaq was one of the "Gang of nine") because it was the firm that at the time made the first machines and particularly the first "commonly used" machines based on this bus. The bus soon faded into oblivion, and was replaced by faster buses, such as VESA and later PCI. But there was a precedent of a "hidden" partiion with id 12 that has been later used extensively by Compaq itself and later by other manufacturers (including Intel and IBM to name a couple) for Recovery or Diagnostics use, see: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html Microsoft NT based systems - trying possibly to be smart - tag in Disk Management the ID 12 partition as EISA instead of "unknown". A partition ID that means "nothing" in the sense that it DOES NOT IDentify a particular filesystem as it can contain everything and the contrary of everything should not be tagged with something that actually does not exist (and possibly NEVER existed), IMNSHO. Dell's Recovery partitions normally have a partition ID of DE, see: http://www.goodells.net/dellrestore/ http://www.goodells.net/dellutility/ if XP tags a DE partition as "EISA" it is twice wrong (and no, that doesn't make it a right ). jaclaz
  10. On unrelated news, the rage is mounting about the "hypothetical" EULA of the "hypothetical" google glasses: http://www.wired.com/gadgetlab/2013/04/google-glass-resales/ http://hothardware.com/News/By-Prescription-Only--Google-Will-Brick-Glasses-If-You-Loan-Them-Out/ jaclaz
  11. Yep. Yes, but you need some background. Drive letter is a "residual" of DOS, NT based systems do not really-really use drive letters (though 99.99% of programs running in them do use them). I know it sounds "crazy" apparently, but that is how it works. Boot.ini uses ARC paths (and knows nothing about drive letters), this is why a typical entry in it is like: multi(0)disk(0)rdisk(0)partition(1)\WINDOWS i.e. a partition/volume is accessed by it's address, in the above first partition (1) on first disk (0). Then NT boots and the same volume is seen (in disk management or diskpart) in a similar way, the actual NT name will be \Device\Harddisk0\Partition1 or \Device\HarddiskVolume1 or \Device\Harddisk0\DR0 or , you can use the nice Sysinternals program Winobj: http://technet.microsoft.com/en-us/sysinternals/bb896657.aspx and also an GUID is assigned to it (try running the MOUNTVOL command), like \??\Volume{83092730-6bfc-11df-b90c-806d6172696f}. then a drive letter is assigned to it (i.e. the Volume is mounted to a drive letter). If there are no related settings in the Registry (namely in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices ) the letter assignment is automatic (following a given set of Rules, first non-hidden primary on first disk is given C:, etc.) OR you can choose to NOT assign a drive letter (i.e. the Volume is NOT mounted) OR you can use INSTEAD of a drive letter (on NTFS only) a mountpoint see: http://technet.microsoft.com/en-us/library/cc938934.aspx So, the idea is not to "hide" the partition(s) but simply to NOT mount the "other" volume on each of the two installs. The easiest is to use migrate.inf during setup to have it mount to a "different from C:" drive letter, let's say U:, and later, once install is complete, de-assign the drive letter from the volume. The reference I made was about the impossibility of accessing the BOOT.INI (as the only item that may need to be edited) on the non-mounted volume, but it is only a matter of temporarily mounting it in order to do the editing. Yes, but actually in the worse case you will have re-installed to the "same, wrong" drive letter, nothing catastrophical. I gave you the "complex" way in order to see what you thought about it. The key question here is if you have a working PE of some kind and you are familiar with it in order to do the editing of the migrate.inf. Booting a grub4dos (from say a USB stick) and simply hiding the first partition (second in your case) before installing the XP 64 is far easier. The only issue with this approach might be if the second partition (third in your case) is not a primary one but a volume inside extended. Well, as a matter of fact what most people fail to realize is that a menu.lst is correspondent to a batch file, i.e. it is a way to repeat a set of commands at will, in this case you need not a menu.lst, you simply want to run a few grub4dos commands on the command line. Think at grub4dos like you would think at DOS: it is a (minimal) Operating System with a set of commands available. Think at menu.lst like you would think at DOS' Autoexec.bat and Config.sys, a set of commands (and choices) that will execute when booting the OS. The grub4dos guide by diddy: http://diddy.boot-land.net/grub4dos/Grub4dos.htm details enough most of the basic usage of the tool (though since the time it was written a number of new features were added to grub4dos). You need to read just these pages: http://diddy.boot-land.net/grub4dos/files/basics.htm http://diddy.boot-land.net/grub4dos/files/cli.htm and something about disk swapping: http://diddy.boot-land.net/grub4dos/files/map.htm#swap and learn about three commands: http://diddy.boot-land.net/grub4dos/files/commands.htm#hide http://diddy.boot-land.net/grub4dos/files/commands.htm#unhide http://diddy.boot-land.net/grub4dos/files/commands.htm#makeactive You are welcome. If I were you I would boot from a USB stick with grub4dos on it (an easy way to create one is using RMPREPUSB: http://www.rmprepusb.com/ ), then issue these commands: first three lines "restore" the disk order as if you hadn't booted from USB, the ls should show the contents of your current XP 32 partitions, it is just a check to make sure that device/partition numbers are correct. Then: this should list the contents of the partition on which you are going to install the XP 64. You should (from the XP 32) delete the contents of this partition and make on it a "tag file", deleting the contents is needed because otherwise the XP install will probably use the current "wrong" drive letters from the XP 64 Registry and making on it a file like "thisis_64_bit_part.txt" is just a way to make sure that partition is the "right" one. Then: i.e. make active the third partition and hide the second one. Then reboot and install the XP 64 "normally". Once done that simply unhide the second partition, either booting to grub4dos and: or by using *any* Windows tool oriented to managing partition tables/MBR, the mentioned PTEDIT32 would do, but also any disk editor will do as well or any other tool you are more familiar with. When you reboot you will still have the XP64 only actually booting, this time the XP32 partition (since it is non-hidden) will get a drive letter, up to you if you want to change it or remove it alltogether in Disk Management. Now you need to edit the BOOT.INI (on the XP64 partition) to add an entry for the XP32 partition. This way the "main" bootmanager will be the one on the third partition. If you want to use instead the one on the second partition you need to make that active instead (and add to the BOOT.INI on the second partition an entry for the XP64 install). This is IMHO the less risky because you have handy a tool (the USB stick with grub4dos) with which one can fix any and all issues that may arise. BEFORE doing any of the above, obviously, it is strongly recommended that you make a backup of the MBR "as is" (which BTW, since you have a partition that is - incorrectly - identiifed as EISA by disk management and that is a Recovery partition of some kind, is VITAL since besides the DATA also likely contains a non-standard MBR CODE allowing the access to the recovery parittion). jaclaz
  12. Ok, let's start again from scratch. The grub4dos is NOT anymore on sourceforge (since YEARS). The current release is here: http://code.google.com/p/grub4dos-chenall/downloads/list ALWAYS use, unless specifically told to use a specific version, LAST one marked as "Featured", right now: grub4dos-0.4.5c-2013-03-03 http://code.google.com/p/grub4dos-chenall/downloads/detail?name=grub4dos-0.4.5c-2013-03-03.7z&can=2&q= There is NO NEED to rename anything to anything else , on the contrary it is STRONGLY ADVISED to NEVER do that. grub4dos is MORE flexible than GRUB (legacy) and GRUB (GRUB2) because it has been designed with features that both the original GRUB and the unneededly made complex GRUB2 completely miss. But to simply dual boot two XP's there is NO need for using any third party bootloader/bootmanager, the NTDLR is enough. The real issue here is: The quick answer is NO. The long answer being, YES, it is possible but the procedure is so long, complex and prone to errors that it is NOT a smart approach. Reinstalling from scratch is highly advised, really. Yes, it is possible. Ideally you should have three partitions, (one for the boot files NTLDR/BOOT:INI/NTDETECT.COM) and two one for each XP, but it is doable even with your current setup. You need to re-install the second instance of XP, however AND have a "separate" booting media (ideally a PE). The key is the file migrate.inf, that you will find in \$WIN_NT$.~BT\ after running the first part of the setup, see: http://www.911cd.net/forums//index.php?showtopic=19663 the file is used to "migrate" the current drive lettering (from the first XP install) to the second (new) one. You need to edit it so that in the "new" install the first partition (the one with the XP 32 bit install) is NOT assigned to C: and INSTEAD the second partition (the one to which you are going to install the XP64) will get it. (in practice you will simply need to invert the drive letters, your migrate.inf will have two entries). This way the C: letter will be assigned in the XP64 install to the second partition where the XP64 is installed to and the "other" letter will be assigned to the first one. Later you can remove the drive letter from the "other" partition from each of the two XP's from Disk Management. The issue here will be that to edit (if needed) BOOT.INI from the XP64 install, you will need to assign a drive letter to the first partition in order to access it. The above is the "difficult way", if we are allowed to use grub4dos - at least for the mere install phase - it would be much simpler, as we can use it to hide the first partition (and thus there will be no need to edit migrate.inf). The approach sketched by submix8c (set aside the renaming of grldr) is valid but it is "permanent", and at every other boot you will be setting/unsetting data in the MBR, something very like it can be used only during the install, and later provide a "normal" NTLDR choice between the two XP's. Let me know which way you prefer, ask for directions BEFORE doing things. jaclaz
  13. And the answer is "Yes and No". Yes, depending on the actual OS you are using it is possible using no third party tool (but the key is F8) to access a WinRE (one of the least talked about setups/environmants, actually a PE), but No, in most cases a third party tool is used as it is simply much easier to setup (and you can choose another key, though loking for F11 is normally an issue as it is a non-standard key, choosing F10 is advised) AND much more robust (as the "switch" happens in the MBR, which has less probabilities of being corrupted if something happens, or, if correupted won't let the PC boot anyway). If you prefer, using the \boot\BCD mechanism is possible but overly complex, far from "failproof" and all in all not "smart". Anyway, for Vista and later: If you decide to go for third party tools, there are several ones "self contained" in the MBR or - personally prefferred - grub4dos that can do that easily, just ask. jaclaz
  14. Eh? I assume specific to non-US keyboards. Should be Ctrl+Alt+Del on US ones. Yep , my bad , forgot to translate the "Canc" (Italian) to "Del" (English), BUT since I posted an image in which CTRL+ALT+DEL (again) is mentioned , you are given honoris causa the grammar police badge I received just today from submix8c: (It's like a hot potato , pass it on ) jaclaz
  15. Well, the Borowitz Report is a good source for almost anything, another not so much OT recent one: http://www.newyorker.com/online/blogs/borowitzreport/2013/04/facebook-unveils-new-waste-of-time.html And now, in a (swift ) unexptected move, let's talk of CHEAP 7" tablets (and having LOTS of them): http://techland.time.com/2013/03/11/invasion-of-the-low-cost-tablets/ Can these 50 to 70 Euro "no name" ones (example, redo on your local e-bay): http://www.ebay.it/sch/Laptop-Netbook-/177/i.html?LH_BIN=1&_sop=15&_nkw=tablet+android&_pgn=2&_skc=50&rt=nc be "good enough" for doing the ONLY things that you can do on a 7" tablet ? (yes working on it is EXCLUDED ab initio ) jaclaz
  16. Which version of WinPE? Has it WMI/WMIC running? WMIC Path Win32_UTCtime GET hour WMIC Path Win32_Localtime GET hour jaclaz
  17. Good moorning , Mr. de La Palice .... jaclaz
  18. You mean that you don't get the "Start" button? What happens if you press when booted in safe mode Ctrl+Alt+Canc? Do you get Task Manager? As in: http://www.guidebookgallery.org/screenshots/win98se Which tasks do you see running? jaclaz
  19. Well, here you are assuming that togermano will fail in his attempt . jaclaz
  20. sparkles , with all due respect, I have rarely seen so much nonsense as in the forum you linked to, this thread particularly: http://78886.activeboard.com/t7886792/ebay-loves-profits-from-and-supports-crime-worldwide/ So, a lot of crooks use e-bay to re-sell stolen or counterfeited goods, hardly news , but this is a mish-mash of every possible article about criminal behaviour where the words "e-bay" or "paypal" are mentioned. People that formerly worked for e-bay committing crimes like child abuse or homicides? http://78886.activeboard.com/t7886792/ebay-loves-profits-from-and-supports-crime-worldwide/?page=19 What the heck has this to do with whatever evil commercial practices e-bay or paypal or both may do (or do not)? jaclaz
  21. Yep , the point being if OP didn't come back because he/she is ungrateful BUT the proposed solution worked (and thus all subsequent posts are superfluous ) or if he/she didn't come back because by following the given suggestion his/her PC took fire or exploded . jaclaz
  22. Well, IMHO the snippet in #222 should be way faster, as it loops not. There is (and there will always be) debate over using "skip=" or "| FIND "something" if different versions of tools are used. In the case Yzöwl pointed out, probably the best option is to combine them : FOR /F "skip=2 tokens=*" %%A IN ('cabarc L test.cab ^| FIND "/"') do ( jaclaz
  23. Naaah, outdated in the sense that they were old news, the reality (updated) is worse. Of course the real cause of this is the US patent office and related Laws, in Europe things appear much better. jaclaz
  24. AND outdated. Fresh news: Microsoft adds Foxconn parent to list of Android patent deal scalps http://www.zdnet.com/microsoft-adds-foxconn-parent-to-list-of-android-patent-deal-scalps-7000014133/ Microsoft signs Chrome and Android deal with Foxconn parent Hon Hai http://www.guardian.co.uk/technology/2013/apr/17/microsoft-chrome-android-deal-foxconn-hon-hai List here: http://www.fosspatents.com/2013/04/foxconn-parent-hon-hai-signs-with.html jaclaz
×
×
  • Create New...