jaclaz

I am attaching three cropped screenshots (it is a .7z file containing three .bmp's, I didn't intentionally use .jpg format to avoid any image compression artifacts) to show what I see here. The text (ALL text) is severely blurred and/or too d@mn small to be easily readable. As said, in Opera it is more blurred but a little larger, and in Chrome (Ok, Iron) it is slightly less blurred but way too tiny, even enlarging it in 110% it remains blurry. It is UNREADABLE, and since the idea of publishing anything is that people is able to read it (and read it easily) it seems to me like a serious issue. The text on Qtweb is much crispier. and - as a side note - even with javascript disabled the "Unread Content", etc. i.e. contents of the gray bar work fine in it. I am also attaching three small .jpgs of Dave-H latest post, only to show the differences in the readability (or lack thereof) of a single post text. As expected the .jpg compression severely worsen the quality, the "real" QTweb view is much crispier than what it seems from the jpegs. jaclaz msfn_view.7z

Either a 3 or a 4 Tb disk (real disk) BUT with 512 bytes sector (i.e. AF, not "native" 4K). Both a virtual disk or a virtual machine may introduce whatever added layers/incompatibilites. Instead a "normal" 3 or 4 Tb disk would do nicely. The idea is that seemingly only the two fields in the MBR the "Sectors Before" or "LBA offset" and the "Sector number" or "LBA sectors" are 32 bit, as the NTFS bootsector (or $Boot) has 64 bit fields for LBA addresses. Since the first partition/volume (that is the boot and system partition) is entirely within the 32 bit range there won't be any problem (just like there aren't any on any 2 tb disks with a single partition/volume) so anything in the booting sequence including NTLDR or BOOTMGR, etc. won't have any issue. At this point the second partition/volume is only a "data partition" so it should work unless in some parts of the actual filesystem driver or related files *somehow* the LBA addresses (absolute) are summed up, in theory each and every address in the filesystem is (should be): 1) relative to the beginning of the volume 2) accessed by/through the cluster "grouping" so, since the whole volume is below the 32 bit limit in size, the cluster numbers will be well below any 32 but limit, since the typical NTFS cluster size of such a big volume should be anyway 8 sectors or 4 kb jaclaz

No, I have NO problems whatsoever, nor does Opera have any, this board (its software) have them, we were asked to report if we noticed any problem (of the board and of its software) and that is what I did. The non-solution to these problems (very common BTW) is to blame the user for not using this (or that) browser, this is an entirely wrong approach by a number of arrogant, usually clueless lazy developers, including particularly the guys at IPB board, who well demonstrated in the past to be among the most clueless and less custom oriented folks around. They (as well of course as Xper that obviously has much less power in fixing any bug) are perfectly free to botch (as they ALREADY did at EVERY SINGLE new release of the board) the board, the looks of it, the readability of it, each and every link, reference and Quote and Code (let alone Codebox) text, make the editor unusable, and to mark each and every bug report (as they ALREADY did for hundreds of them) as "Won't Fix" or "This is by design". I don't need fellow members to tell me how Opera is outdated, I know, thank you. jaclaz

Opera . 12.15 Checking again BOTH "Home" and "Unread Content" (or "All activity" if not logged in) don't work, i.e. everything in the gray bar on the left of the facebook/twitter/google+ don't work (but the facebook/twitter/google+ do work), i,e, I can see the " Home->The General Stuff->General Discussion->Site & Forum Issues->Forum upgrade to v4.2 at the top of the thread, but no item in it is clickable. Also, I am replying with a Chrome, sice the "+" and "Quote" below each post don't show at all in Opera. Usual mess by the guys at IPB but still not a major problem, at the most it simply further prevents to make proper quoting of previous posts. Readability/font/contrast IS a real issue. Besides being VERY VERY blurry (in Opera) it is a little crispier (though anyway FAR from being actually crisp) in Chrome (OK Iron actually) but here it is too d@mn small (and thus as well unreadable) jaclaz

This is IMHO serious and should be solved: Cannot say if it's the font, its stupid gray colour (and thus almost null contrast), some form of antialiasing or what, but it is almost unreadable, requiring an excessive effort to read anything, really, it makes my eyes tear, it is unbearable. These are minor things: The "Unread Content " link does nothing (it works *somehow* from the top dropdown menu Activity->Unread Content that actually leads to http://www.msfn.org/board/discover/unread/ For whatever reasons you have to hover the mouse on "Activity" then after a delay the dropdown opens and you can choose the items in the dropdown, The "Activity" itself if clicked leads directly to http://www.msfn.org/board/discover/ same as Activity->All activity There is also an item Search that leads (just like the magnifying icon on the right) to http://www.msfn.org/board/search/ You need to "approach" the manifying icon from the left, the right or the bottom with the mouse because if you do it from the top it get covered by the expansion of the Contacts dropdown. It's good to have to learn new UI usage conventions. The good news are that at least the user "avatar" on the top left doesn't grow anymore out of scale as it did before. jaclaz

Actually it is not that difficult. CD's were originally NOT designed to be bootable At a given point many, many years ago a way to make them bootable was devised, called "El-Torito" because seemingly a sketch of the specs were written on a napkin in a El Torito resataurant: https://en.wikipedia.org/wiki/El_Torito_(CD-ROM_standard) Basically it is an extension to the already existing CDFS (and to BIOS code) that allows three "modes": 1) floppy emulation mode 2) no emulation mode 3) hard disk emulation mode The first one is nothing but an image of a floppy disk "added" (hidden) to an otherwise "normal" CDFS filesystem. The second implies that a special bootloader is present that allows to chainload files on the otherwise "normal" CDFS filesystem. The third is more similar to #1 but exposing a hard disk like device instead of a floppy (and usually but not necessarily) there is not a "normal" CDFS filesystem as all the space on the media is filled by the hard disk image. Since the whole extension to the original ISO 9660 standard happened (1994/1995) while MS DOS (and similar) was the most common OS and DOS could boot from a floppy just fine, initially many BIOSes only managed the floppy emulation mode properly. The Windows NT 4.0 install CD, to give you an idea of the times, was NOT bootable and was accompanied by bootable floppy disks, the Windows 95 and Windows 98 CD's were bootable (using the floppy emulation method) and Windows 2000 was the first install CD bootable with "no emulation mode", while maintaining (for compatibility with BIOSes that couldn't yet boot properly from CD-ROM in no emulation mode the possibility of creating a set of bootable floppy disks. When you boot a floppy emulation mode TWO devices are available, one is a "viirtual" (emulated) floppy disk (that gets drive letter A:) and the actual CD-ROM (for which in DOS MSCDEX or SHSUCDX are needed). When you boot a no emulation mode ONE device is available (the CD-ROM). When you boot a hard disk emulation mode (normally) ONE device is available (the emulated hard disk). USB support in BIOS is related to only ONE "boot" device, and that is the reason why a floppy emulation CD is a problem, as the access to the "other" device (the CD-ROM) needs an OS driver being not supported by BIOS. jaclaz

The pwnative.exe makes me think it is a "native" executable. Then, likely it is in bootexecute in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager: https://conshell.net/wiki/Native_Executables_(Windows) Make sure that the default "autocheck autochk *" remains: http://www.thewindowsclub.com/bootexecute-autocheck-autochk-windows jaclaz

And still NOONE with suitable hardware had the guts to try this: http://www.msfn.org/board/topic/176480-2-tib-limit-size-in-mbr-hard-drives/?do=findComment&comment=1135913 which is also "mathematical" but that needs to be tested, as the way access to sectors is implemented may have some other limit beyond the 32-bit field sizes. jaclaz

The point is that IF (as nowadays all do) the BIOS has an option to boot from USB, then it provides some support for one (and one only) device. The iodd (or similar) normally work because they emulate a single device (the .iso as a CD-ROM device). BUT an El-Torito "floppy emulation" CD/.iso actually creates two devices, the floppy disc which is emulated AND the CD, so direct BIOS support for it is not possible. On some hardware (it has to be seen specifically) a newish grub4dos may be able to use its own internal USB stack to access the CD-ROM. Of course it is perfectly possible to install from files copied to internal hard disk, actually this is what everyone with some experience did, basically because it is much faster than CD-ROM (or of USB 1.1 or 2.0) AND because if you need some component that was not installed first time you already have it on hard disk without needing to dig up the installation CD. In the case of Windows 98 you just copy the \WIN98 folder on the hard disk and then you run setup from there. http://www.windowsreinstall.com/win98/install98stepbystep1/indexfullpage.htm If you boot from a USB stick, then you will have the drive letter C: given to the booted volume on the USB stick and a D: (or higher) letter assigned to the active partition on the internal hard disk. Make sure to be able to run smartdrive, as it will shorten the copy time noticeably, see also: http://novaonline.nvcc.edu/eli/itn107mb/installing_windows_95.htm I.e.adapt to Windows 98 this method (USB stick specific): https://web.archive.org/web/20160417164143/http://www.911cd.net/forums//index.php?showtopic=16713 jaclaz

Are you talking of the iodd (or similar)? But that would imply USB support at DOS level (besides and before any CD-ROM support). Most probably (but needs to be checked) you can still use a USB connected *something* as long as you make a "monolithic" .iso (such as a hard disk emulation image), but then you might have issues with drive letter assignments (and need Letter Assigner or similar). Otherwise you will need to go down the (actually a tad bit adventurous) path of the Panasonic (and similar) USB drivers for DOS, which might (or might not) work depending on chipset, BIOS, *whatever* of the specific machine. Usual resources: http://bretjohnson.us/ https://web.archive.org/web/20150602213331/http://johnson.tmfc.net/dos/usbdrv.html jaclaz

Well what you have heard is either incorrect or you haven't understood it fully. Minlogon is a component of Windows Embedded that allows to log in (log on) without providing User Name and Password, it is (was) designed for machines like POS and similar. Since it "bypasses" a number of logon related files it allows to build a smaller image/install and it provides for a faster startup. Once you get to the desktop there is no "advantage" whatsoever. Same goes for EWF, it is a specific Write Filter that has some use only in very specific "narrow" cases, and it is not suited for "general use" (and in any case won't change speed of responsiveness of the OS, actually in some cases it might slow it down). https://msdn.microsoft.com/en-us/library/ms838511(v=winembedded.5).aspx jaclaz

If you prefer Windows program development it is like if you were to create anything in plastics, instead of making injection moulds from a block of steel to later create the final plastic object, you are given a kit of Lego and they create the plastic object by assembling the little bricks. For the first chore you need to be a highly skilled professional and lots of time are needed, for the second even a kid can do it with a minimal knowledge of the Lego "rules". Now the whole point of Lego is that the bricks are always interlockable and exchangeable and the "rules" never change, while of course very UNlike Lego with Windows API/DLL's half of the bricks are undocumented or mis-documented and slightly different in size at each year of release and you can never find two kits with the exact same bricks inside, and the "rules" are in a perennial state of flux. jaclaz

Now it is MUCH better. jaclaz

Ok , that's fine , it is just myself then that believes that this sentence is NOT English : let alone the 3 patches to be reapplied in step 7 and that are NOT listed in step 5 : : ... clearly my bad, sorry . Now I have to go, I need to look for the some of the patches patches ... ... and it's not all, of course... jaclaz

Well, you asked for a "Windows 98" compatible utility, that is what was suggested, and yes, SIV provides LOTS of info but more is better when looking for hardware ID's . The fact that its x64 version doesn't work on your (crappy Asrock) hardware under another (unknown) 64 bit OS should be not relevant (though of course SIV normally works under *all* Windows OS, maybe it is really because of the peculiarities of your hardware). While it would probably be "too much" to ask the nice Ray Hinchliffe to modify/fix an issue on a today "rare" OS such as Windows 98, he might be interested to a report about the 64 bit error , as such bug reports are what have helped over the years into making SIV into such a complete/good tool. There are some instructions on the homepage on how/what to send him under "Issue Reporting" near the bottom of the page. jaclaz

Thanks! C:\>DLEdit.exe Adds, removes, queries drive letter assignments usage: DLEdit.exe <Drive Letter> <NT device name> add a drive letter DLEdit.exe -t <Drive Letter> <NT device name> add a temporary drive letter DLEdit.exe -r <Drive Letter> remove a drive letter DLEdit.exe <Drive Letter> show mapping for drive letter DLEdit.exe -a show all mappings example: DLEdit.exe e:\ \Device\CdRom0 DLEdit.exe -r e:\ C:\>DLEdit.exe -a Drive Device ----- ------ C: \Device\HarddiskVolume1 D: \Device\HarddiskVolume2 E: \Device\Harddisk2\DP(1)0-0+8 F: \Device\CdRom1 G: \Device\Harddisk3\DP(1)0-0+9 H: \Device\Harddisk4\DP(1)0-0+a I: \Device\CdRom0 J: \Device\Harddisk5\DP(1)0-0+b C:\>DLEdit.exe -r F: C:\>DLEdit.exe -a Drive Device ----- ------ C: \Device\HarddiskVolume1 D: \Device\HarddiskVolume2 E: \Device\Harddisk2\DP(1)0-0+8 G: \Device\Harddisk3\DP(1)0-0+9 H: \Device\Harddisk4\DP(1)0-0+a I: \Device\CdRom0 J: \Device\Harddisk5\DP(1)0-0+b C:\>DLEdit.exe -t F: \Device\CdRom1 C:\>DLEdit.exe -a Drive Device ----- ------ C: \Device\HarddiskVolume1 D: \Device\HarddiskVolume2 E: \Device\Harddisk2\DP(1)0-0+8 F: \Device\CdRom1 G: \Device\Harddisk3\DP(1)0-0+9 H: \Device\Harddisk4\DP(1)0-0+a I: \Device\CdRom0 J: \Device\Harddisk5\DP(1)0-0+b It needs to be used together with a tool capable of listing devices without a drive letter assignment, such as dd for wndows (with --list option). @ECHO OFF SETLOCAL ENABLEDELAYEDEXPANSION SET FLAG= FOR /F "tokens=* delims=" %%A IN ('dd.exe --list 2^>^&1') DO ( IF NOT DEFINED FLAG CALL :parsedevices %%A ) GOTO :EOF :parsedevices SET Line=%* SET PartLine=%Line:~0,7% IF "%Partline%"=="NT Bloc" SET FLAG=1&&GOTO :EOF IF "%Partline%"=="link to" SET Device=%Line:~11,50% IF "%Partline%"=="Mounted" SET Mount=%Line:~-2,2% &&ECHO !Mount!!Device! IF "%Partline%"=="Not mou" SET Mount=NO DL &&ECHO !Mount!!Device! GOTO :EOF jaclaz

SIV: http://rh-software.com/ remains the usual reference tool. jaclaz

More than ridiculous it seems (very) confusing. The step 3 talks of a "Fileformatconverters.exe" file without any references. The step 7 references 3 patches in step 5 that aren't. The step 8 makes no sense whatsoever. Maybe you could try re-checking the steps you listed and make them more clear. Ideally you should check if you actually can replicate your instructions/steps following ONLY what you have written and add at each step what you omitted (because you already know it). jaclaz

I see , thanks. More or less we need to find someone willing to compile a somewhat modified SDK DLEDIT: https://msdn.microsoft.com/en-us/library/windows/desktop/aa364014(v=vs.85).aspx https://github.com/pauldotknopf/WindowsSDK7-Samples/tree/master/winbase/io/dledit jaclaz

Good . You just won the contest. jaclaz

However, could you expand a little bit on?: "However it assigns the Z:\ as a dosdevice, so disk management or unelevated explorer will not show it." jaclaz

Maybe should be titled "Fake Screenshot Showoff v2". Out of curiosity what is the scope or usefulness (if any) of these? The "original" thread was started by a new user that posted only that initial post and never came back, and to be very, very kind to him, at the time it might have had some satirical purpose given the never-release of a Windows 9 and the doubts on the name of the next Windows versions. But yours? Show how clever you are in using paint.net? jaclaz

@JFX Only to keep things as together as possible and to give you some context to the otherwise seemingly unconnected question above, devdevadev has a particular ability in flip-flopping here and there without giving any hint about what he is after (the general idea). He is trying to put together a batch capable of automating the backup of some systems (that of course needs to be smart, automated and foolproof), the thread is here: http://reboot.pro/topic/21566-please-help-me-to-go-ahead/ the relevant part starts around here: http://reboot.pro/topic/21566-please-help-me-to-go-ahead/?p=204324 but starting reading from here will be enough: http://reboot.pro/topic/21566-please-help-me-to-go-ahead/?p=204348 (only a few posts) jaclaz

ONLY as a side note, this doesn't sound right. Maybe - before and outside the Windows Update issue, disassembling the CPU heatsink and fan, thoroughly clean them and apply some new thermal paste wouldn't be IMHO a bad idea. jaclaz

Is it a BOSE or a BOSS? https://community.bose.com/t5/Bluetooth-Only-Speakers/Soundlink-Color-II-will-not-power-up-or-charge/td-p/28487 jaclaz