Czerno

I am fully aware of this. But as said in the initial post, apps which I don't want to have a taskbar "witness" are ones whose main window will be always on top, and never minimized anyway. For this kind of applications, a taskbar entry is not needed and is but a nuisance. This particular question is nothing to do with the tweaks that capture and send minimized windows to the notification. It is nothing to do with minimizing altogether ! I wish to have a particular app launched with its main window but altogether without a taskbar witness, or alternatively a means to have Windows remove the witness after its created. I promise I won't ever minimze the main window :=) O.K., you seem dubitative, so I'll provide the emblematic example which hopefully will make full sense : app is a desktop clock. I use the round "clock.exe" that Microsoft provided with Windows 95 to show off (then new) non-rectangular windows. With some transparency and always-on style added by a separate "tweaker" (excellent "winroll" freeware by Will Palma), this round clock which can run on 2000/XP is a superior substitute for the Vista/7 clock "gadget" here ! You wrote it should be - which I agree it must. Question is whether there exist tweakers to this end (or why not ?). Note : the mentionned "round clock" accessory was written by MS guys as a Win16 application, which may pose a specific problem as NTVDM is a very special and quirky beast...

Indeed, the regular taskbar entry.

Hi ! Posted to the "Windows XP" forum section for lack of a better suited one, although really the question would possibly apply to other versions of the Windows (4, and later) GUI : Given a running Windows application, having its main window restored (non-minimized), can someone provide help, a tool or method, that either will remove the application's "witness" from the standard Windows "task bar" (without closing the owner app, of course) - or alternatively a tool or method to prevent Windows from even creating said "witness" the moment the app is launched ? I'm especially in want of such a tool or method which would work for "Win16" apps also (running in "NTVDM"). Now to make things absolutely clear, I'm not asking to hide or remove the task bar itself nor to close its owning "explorer" process/thread. Neither for the "witness" to just become "hidden and/or "inactive"! ! I want a specific window NOT TO have a respective taskbar witness at all ! How come neither Microsoft nor, it seems, authors of tweak-all-things type of desktop utilities seem to provide for this simple wish ?

@HarryTri :«In my both Windows XP computers (desktop and laptop) I can't open Windows Explorer with administrator's rights if I am in a restricted user account. Is it normal and if yes what can I do to change it? » This would need to be in the Windows XP section, but briefly - Yes it is expected behaviour : you are in effect launching "explorer.exe" as your administrative account, but explorer has special coding that it immediately relaunches itself as the owner of the shell explorer process (that which "owns" the desktop window,i.e. you "restricted user" self). As you correctly noted, a workaround to this windows explorer "feature" had been to run "iexplore.exe" (ie6) instead of explorer, but the workaround does not work in IE7-IE8. You guess there are several ways to double-smart Microsoft. Simplest method, imho : runas /user:your_admin "explorer.exe /n,." HTH

What about Pale Moon (specifically the older version, built from FF 3.6 code base) ? Will that run on 98 SE using Kernel ex ? If so, Is it worth going from FF 3.6.x to PM ? As in, will it be visibly faster/lighter than plain FF (Athlon XP, no SSE2). Any return of experience will be greatly appreciated...

Sure, always be sure to keep good old netcat at hand's reach, aka the "Swiss army knife" of networking ! Application to quickly shuting down Tor : first create a text file named "StopTor.bat" containing : authenticate "" signal shutdown quit Then create one (lor more) shortcuts to the StopTor bat, on the Desktop or the Start menu (for convenience). Double-click shortcut whenever you need to shut down your server! The example assumed a blank Tor control password (not a vulnerability if the control port isn't open to the internet, which it is not by default, and local users of the computer are trusted). If you set a password though, insert it between the double quotes (authenticate line). Process monitor and other Sysinternals tools are what come to mind (now owned by Microsoft, download from MS).

IIRC some resource leaks are known problems with Tor/Windows, not just win 9x. You might want to browse the Tor flyspray. Of course in addition, windows 98 is not known to be the best platform for supporting heavy-duty servers of any kind. How much Tor traffic are you routing ? If your goal were to run a Tor server stably for long periods unattended, Linux would be the obvious choice. Regarding ordered server shutdown, if that is the only reason you run a controller you might consider instead sending Tor the termination signal "manually", using netcat for instance. This is how I do it, KISS :=) You could shutdown even by just typing a Control-C in Tor's window, it's not the "clean" way but it works, too ... you don't shutdown often anyway (otherwise you wouldn't experience the resource leaks). Good luck with your Tor

Tor itself - server and client[ - is and always has been running perfectly in Windows 98 (no kernelX needed). My own installation of Tor runs indifferently in Windows XP, 2000 or 98SE - executables and data files being shared between the 3 OSes. (I also ran Tor under Linux with much success) If you met problems, they must be traceable exclusively to the FF Browser, Vidalia controller and/or other cr@p, I mean additional components, included in the so-called "bundles" (which are nothing but a trial at a Tor-made-easy-for-dummies) I've never felt the need to run a "bundle", netiher do /you/ need or want one IMNSHO. And yes I've been running (teeny) servers / relays, off and on for many, many years, without ever using more than basic Tor and ini files customised "by hand". Tor runs correctly out of the box in Win 98, although for good operation of a relay, or a bridge, some tweaking of the TCP/IP stack params in the Windows registry is recommended (as explained on the Tor wiki.) Such tweaking in not even necessary if you only run Tor as a client. In no case is KernelX required for running Tor. Good luck and HTH. -- Czerno

Makes sense now. The MS init module checks sector size inside the PBR and marks the partition invalid if other than 512 bytes. How many pigs did Gates have to hire to produce that kind of code ? Thanks for this and the other heads-up (or should it be heads-ups ?). I'll make limited efforts, while I hope to persuade the FreeDOS types to get their kernel right. Can you (anyone) tell if DR/Open DOS -especially versions which recognise FAT32 - can cope with 4K sectors ?

With all due respect, this assertion makes little sense. The MS driver does use the bytes per sector value from the BPB copy made at sysinit time (part of what some DOS leaked source code calls BDSs). I believe unpatched MS-DOS will access and mount an internal disk (anything that doesn't require a special Config.sys driver) w/ big sectors properly.. Does it not in your experience ? While you were developing your TB+ pack, did your tests include a (real or simulated) internal fixed HD with 4k sectors ? OTOH a drive that requires a (Config.sys or later) driver, there is a (small) problem with unpatched MS-DOS, because the max_bytes_per_sec_of_any_block_device is fixed before config.sys is executed. Is this what you had in mind above and what your patch addresses ? I'm not considering booting at this stage of the little project, only the mount of an external (USB) disk using as little supplementary code as possible...

Ah, you meant Windows, not DOS. This would be your VFAT.VXD mod, right ? Are we back to DOS ? Are you referring to the standard driver in IO.SYS / MSDOS.SYS ? ISTM the standard dos disk driver utilises whatever sector size is specified in the BPB, unit per unit. My computer BIOSes won't do that either, unsurprisingly ... Thought you said you had. Well, the USBASPI.SYS version I use handles 4k sectors properly through the USB (using SCSI commands of course). I'll now try to modify - or rewrite - the block device (DIDD1000.SYS) as soon as I'm fully confident that DOS 7.10 kernel does work properly with 4 kibyte sectors. On another note, there may be renewed efforts by the FreeDOS team to make large sectors "happen" there too... I'll keep you all updated. -- Czerno

Dear RLoew, are you saying that the MS-DOS kernel (without those patches of yours) doesn't work properly with a max_sector_size (in list-of-lists) of 4 Kibytes ? Would you care to explain where the problem is, exactly ? I tried and ran with max_sector_size increased up to 4096, both MSDOS 6.22 and 7.10, work buffer as well as regular buffers in HMA were indeed 4k and, behold, the system seemed to work properly - at least I coumdn't crash it in an admittedly short test session. How is one supposed to expose the bug, assuming there is a bug in the kernel which manifests itself with 4k sectors (this is what you've been telling us, right?) - I'm not talking of the utilities, format, defrag and the rest.... Regards -- Czerno

accidental double post, text deleted. Sorry!

Wish list ? First thing, a happy and peaceful year for everybody ! As for Windows 9x (and DOS) enhancements : support for hard disks with 4 kilobyte native sectors, whether ATA, SATA, USB or otherwise connected. I have got such a USB disk appliance - that I can't use in our beloved "older" OS I am aware of Mr Loew's commercial patches - do they include support for USB attached 4k-sectored disks (or cooperate with third party USB mass storage support ?) But - this is wish time isn' it - can't we work towards a free/libre solution ? And why not hope R. Loew could generously release his big sector patches - or otherwise contribute his knowledge of undocumented DOS 7 / Windows 9x disk structures.

GrofLuigi & Jaclaz : thanks! Merry Christmas you all !

Hi ya ! Among the worst annoyments since I "upgraded" from 2k to XP pro is this one : When I double-click a file whose extension is not associated to any application, or a shortcut to such a file, I intend Windows to let me choose the program I wish to open the file with - like pre-XP windozes did - but instead the idiots at MS thought it was a good idea at this point to insert a window, seeking permission to go look for a random program on the Web (yeah, sure!) - which window I have to click out each time before getting the real thing ! I'm sure there is a procedure for removing that worthless interstitial prompt, but how ? TweakUI doesn't seem to offer this customisation.

For my personal edification if nothing else I'm trying to follow the logic of the Microsoft code . Although possibly a little off-topic, may I ask the techie types on this thread where you find the layout of the drive data table in FAT-32 enabled versions of DOS 7 (8) ? In Ralf's interrupt list we have got the previous format (for DOS without FAT 32) as table #2603 at int 2F/0803, but I can't locate the newer expanded table layout (96h bytes per drive IIRC) :=( Of course I'm not exactly young any longer and my glasses surely need adjustment ... If it is in RBL, pray tell under which table and/or interrupt number; else any on-line reference ? It is not practical for me to acquire printed books from oversea (and as much as I hate to admit I'm near to being broke) Thanks

I was not all that clear while posting around 3 am : that Phantom thing appeared, even though the last partition that IO.SYS found in the extended 0F chain would be a recognisable FAT type, one or more levels "below" the Ext2 and Linux swap. Oh, well, I'm not so sure any more if I've hit a "new" bug or a "new case" of an old bug, or nothing new at all. Sorry ! It doesn't matter if everybody observes : Will heed... Many thanks (edit): Ooooh! With your Patch applied I am unable to bring back Phantoms, however hard I try :-) Very nice, indeed it should be obligatory!

I think so, too, as I have been using this sytem to multiboot many OSes for many months without problems, including running several OSes concurrently in virtual machines using the raw disk. Your confirmation that I should be safe is appreciated none the less :=) I never looked into this issue until just now. Using Type 0FH Extended Chain Records doesn't produce Ghost Partitions. These are the actual Partition(s), just with unexpected Letter(s). MS DOS 7 does not appear to follow the Type 0FH Chain Records, so the Partitions are not mounted in DOS. Windows 9x rescans and does mount them. If you have multiple Primary Partitions or more than one Hard Drive, Windows is likely to mount them in a different order than DOS should have. I assure you I have one phantom drive - I can actually see the erroneous parameters in a debugger, fortunately DOS refuses to read/write from the phantom - and MS DOS stopping enumerating partitions, as soon as the extended partition which contains my first Linux extended is changed to type 0F instead of 05. It may be dependent on the particular layout of the disk in unspecified ways which you did not reproduce but it is completely reproducible.(Untested Hypothesis : might it be related to my primary type 0C FAT32 partition overlapping cylinder 1023 ?) Sure Windows 9x later does attempt its own reenumeration but 1: it does not remove the fake or phantom entry from the volumes table, and 2. it still fails to find all the partitions afterwards, though it does add one of the primaries that DOS missed. Bizarre, but that is Micros?ft ! Anyway the bug is totally absent IFF interior extended partitions are all marked type 05. Hence my above suggestion, which I am reiterating.

Hi! Although this thread is old, the findings in it cannot imho be considered 100% accurate or definitive. My experience FWIW is reported here, trying to make it short but as accurate & to the point as possible I have Win 98 SE w/ 80 GBytes hard disk (PATA) and a reasonably modern BIOS (i.e. LBA32 capable). I'm using the MS IO.SYS version from 2001 that is mentioned in the thread. Have many partitions, including 3 primaries (FAT12, FAT16 and FAT32, the last one has the "boot" flag - usually- and is the "system" partition for Windows 98 - and Win 2k Pro as well. This part crosses the so-called 8 Gig limit. Then an extended-LBA (type 0), containing a second FAT 32, followed by a Linux Ext2, then Linux Swap, followed by several of each Ext2, NTFS and DOS FAT partitions - not counting Ranish part manager 2.43 at the very end of the disk which is not covered by the extended partitions chain. I used to experience the phantom drive symptom in MS-DOS and Wiindows 98. What I found over years of experimenting (on and off...) in relation with this thread's subj To start I always make sure the last partition in the chain of extended ones is a FAT-type known to MS-DOS. This in itself however has never prevented the bug. The only method which cures (not just works around) the IO.SYS volume enumeration bug for this system is making sure all extended "container" partitions (except for the most exterior one) are type 05 (NOT type 0F ! ) - Changing the type of any interior extended to 05 from 0Fh immediately and repeatably restores the bug. - Steven "Phelum" 's patches have had NO effect whatsoever on this bug within my system (neither the three of them together, nor the "206C" patch in isolation). I'm not saying Steven's patch(es) are useless for everybody, just that they're not needed or helpful on my system Sincerely hoping this feedback can help anybody who wished to have another look at this bug (I haven't even tried to disassemble IO.SYS). I would appreciate R.Loew's comment in particular, whether he thinks I am secure from the unspecified (other?) bug(s) he is aware of (and considering I have no use for LBA 48). As a final note, other DOSes (i.e. non-MS) which are FAT32 and LBA-aware have no problems enumerating and mounting all my FAT partitions, whatever combination of 05/0F types internal extended partitions are given. Nor have Linux or even MS Windows 2000 SP4 any problems! However for MS-DOS (and Windows 9x) compatibility my advice based on this experience is to have all extended containers typed 05 except of course the priamry extended LBA which must be type 0Fh