Zoinkity

Has anyone tried backporting the taskbar from win7, possibly from the RC/beta preview? That and the calculator are about the only features from win7 I care for. I suppose I could crack the version stamps on a retail win7 version, but no use reinventing the wheel, eh? Wonder if they were recycling the class from the start menu for that...

Thankfully never saw it before. Guess these people don't realize that people on these forums have found ways around the issue. Lament. Crazy that. You could always go out of your way to complain and explain the situation, but chances are that won't work out well. Haters gotta hate.

One problem with the debug builds versus the official one is that folders are not automatically refreshing. This does cause problems if you forget to Ctrl+R after renaming a file or directory, since it uses the old name to do the lookup. This happens both on my old box and under virtual console, and this doesn't happen when reverting to the old 4.5 release. Otherwise, the system thread concept is very good, and I like the increased compatibility.

Wasn't there a simple method to force a rebuild of VMM32.vxd?

The registry has an entry to the folder. Files are searched for in the directory. Some programs load dependancies based on a file name pattern, such as "NPSWF32*.DLL", then load the highest-ordered search result. Chances are rather high that the original NPSWF32.DLL is being overridden by the .dll with the most recent patch date and version. (That said, they could also use it for base shared functions, but it isn't likely.) This is all part of a program distribution model aimed at rapid, common patching. It's certainly wasteful, taking more disk space and bandwidth than simply patching files. That said, replacement is faster and more foolproof; they don't need to concider things like permissions, read-only access, running programs, or unloading resources. It just works the next time the program is loaded. Plus, if they do need a regression you probably already have the file.

On the subject, doesn't Microsoft use a namespace extension to mush together the many actual folders that compose the 'temporary internet files' virtual directory? If that were the case it could probably be hacked to permit any folder to do the same kind of thing in the case it reached filename capacity.

Thanks! Works great, and solves a stack of other annoyances.

I know in Vista you could get away with having multiple shell entries named "runas" so long as they were sequentially-numbered; i.e.: runas(2), runas(3), etc. However, when trying to merge this reg entry from Vista the runas(2) is ignored: [HKEY_CLASSES_ROOT\dllfile\shell\RunAs] @="&Uninstall" "HasLUAShield"="" [HKEY_CLASSES_ROOT\dllfile\shell\RunAs\command] @="regsvr32 /u \"%1\"" [HKEY_CLASSES_ROOT\dllfile\shell\RunAs(2)] @="&Install" "HasLUAShield"="" [HKEY_CLASSES_ROOT\dllfile\shell\RunAs(2)\command] @="regsvr32 \"%1\"" So, is there some other method to it, or is a workaround required?

I'd like to know if there's some existing capacity for different variations of formats already supported by Universal Extractor. In particular, say you have a file that's .z compressed. The two-byte header is altered slightly, and the CRC is not included. Is there a method to automate reading this type of file? For that matter, if only the compressed data was included (no filesize, CRC, org.name, etc.) is there a way to read such a file as well?

Finished up a port of the XP theme RVWoodwork. Its passable, but the window buttons are still bleh. http://two.xthost.info/zoinkity/Windows/Themes/Woodwork.rar Preview image is attached to this post. +_+ Oh, incidentally, there's a weird little glitch in the skinning engine. If you select the "help" button and hold or click on the window frame, the original unskinned buttons appear. It can also happen if you right-click a window caption, though it immediately corrects itself.

This may be useful for those people who use stuff cross-platform, like USB stick drives. Folder icons have stuck around from the win9x era all the way to Vista, but it seems no two versions expect the same thing. Here's the sure-fire way to ensure that your icon will be visible on every version. +_+ First, set both the "system" and "read-only" flags for the folder you're changing the icon from. To set the system flag you'll need to open a command window and type in something like this: attrib "FOLDERNAME" +s The system flag is required by win9x, but read-only is required by NT versions. Next, create a file inside the folder called "desktop.ini", traditionally set as system and hidden although this is questionably required. Here's a sample of what one should look like: [.ShellClassInfo] IconFile=notepad++.exe IconIndex=0 IconResource=notepad++.exe,0 "IconResource" is Vista's means of finding icons and doesn't work XP and below. They expect the "IconFile" + "IconIndex" lines. If there is only one icon in the file, you can use just the IconFile line. In both of these examples it is included anyway. You can also use relative paths. Remember the path is from the current folder, so if there was an icon PopEye.ico in the directory above, you would type this: [.ShellClassInfo] IconFile=..\PopEye.ico IconIndex=0 IconResource=..\PopEye.ico,0 =_= Like any desktop.ini, you can also tack in other features such as InfoTips, set shell extensions, and other such nonsense, with varying degrees of sucess depending on what version you're using.

JNES, a relatively-decent NES/Famicom emulator, installs and runs if you set to win2000 or higher. http://jabosoft.com/?articleid=96 Note, with the most recent release I had to select any language but english to avoid a fatal error. If you want english, use the ??? setting just above it, which is most likely default. +_+ Also, the newest GIMP (2.4.6 or something like that) does install but pops up a wonderful error screen filled with little square placeholder boxes. Maybe it doesn't like unicows?

!? Sure, Gimp 1.x works without the extension, but what's the lastest 2.x version that still works? Wasn't GTK+ an issue?

Ah, so that's it. Well, concidering my BIOS allows you to mash the ESC key to select the boot drive, it doesn't seem worth the effort to do anything intricate. Thanks for the explaination though.

Here's the original (aka boring) Microsoft Watercolor schemes. Just to warn, they are very minimalistic. Comes in Blue, darker blue, green, grey, red, yellowish, and purple. Watercolor.rar

Attached to this post are the Win XP Homestead and Metallic schemes. These are subthemes for the current Luna one and rely on some of its images, so be sure to dump them in there. If you unpack it to the Themes folder it should go where it belongs. Regs for the schemes are in the corresponding folders. Shouldn't be to difficult to muddle out. Windows_XP.rar

I have win XP on C:\ and 98 on D:\. After running bootpart it created D:\BOOTSECT.W98 and added the line: D:\BOOTSECT.W98="Windows 98 Second Edition" /win95 -to XP's boot.ini. However, if you select 98 from the startup menu, it displays that it either can't find <Windows Directory>\system32\Hal.dll or it is corrupt. I'm guessing this is not as simple as copying XP's Hal.dll to 98's system32 folder... So, what's wrong with it now?

It may sound odd, but did SP3 do anything that would affect LPT port support. I known Microsoft has gradually added more restrictions to port access, but was anything specific added in the newest service pack? I'm asking because since updating I haven't been able to get any programs that utilize the port to function correctly. They were designed to use userport, and in the past this was never a problem, but as of late it won't do a thing. Updating to the new service pack was the only thing that's happened between when this stuff worked and now, and I'd like to verify that the hardware didn't fail. Now, under a port monitor something odd is happening. LPT1 is set to use EPP+SPP 0x378 int 7 in both the device manager and CMOS. However, the port monitors claim that LPT1 is set to 0x3F8 -this isn't a selection in CMOS- and that 0x378 is LPT2. However, I can't redirect the port numbers either, and compiling the program to use LPT2 doesn't help at all. Probably a hardware error? What the heck is going on? (sorry if I don't reply immediately, but I'm borrowing internet for the time)

Wouldn't dropping said files into the EBD directory also produce boot floppies with the updated utilities on them? It does require changing the ones in the cabinet though as well, right? (crosses fingers and hopes that was the directory used to pull files for created boot floppies)

Out of curiosity, which GTK+ apps are working now? Do the newer GIMPs fall on the list?

I'm all for binary files, but I'm a bit partial to them. Text is easier for most to edit. Why not mirror windows own solutions to it? Set a path to the file containing the icon, then have an optional second line for libraries/executables/etc: IconIndex=# Conversely you could always use the old trick "filepathname.ext,#" or something like that. It'll get ugly quick though with long paths and a million entries. In the case of libraries it would be almost silly to have to give a full path each time you recall a single icon. Maybe use the last path listed and just change the index?

...yet software patenting and intellectual property, as well as implicit copyright, are the backbone of private development. This is the frontline defense against anyone - large or small - being able to outright steal another's work. In fact, its true of all publishing. Implicit copyright is held by all software developers. If, for instance, MS decided to 'borrow' uberskin, Tihiy could sue their pants off. They can make a facimile that does the same thing albeit using a different method (which incidentally you could say about uberskin, a skinning engine that hooks differently than XP's), but they can't pirate code.

Okay, first, there are no problems reading or any when bringing up properties. As far as writing, I can use pure DOS, a DOS window, or directly saving to the floppy (ie. Save As... to a:\ from a program). The trouble occurs if I try to copy or move a file to the floppy from explorer. Floppy drivers don't appear corrupt. After doing a little testing (and getting a rewritable CD), it turns out that copy/move/sendto doesn't work for any removable drive, be it 5.25, 3.5, or CD - but only when writting to the disk. However, the same operations work fine between the hard drives, so maybe it is something driver-related. This is really quite odd since it suddenly, out of the blue stopped working properly after years of being completely fine. Hmm... Never had that problem with 5.25 floppies. I've been sending stuff to an Atari 800XL (using an external floppy drive, obviously) for years now. It's certainly much more stable than the audio cassette drives ever were...

This is a weird one. The floppy drive works fine under DOS. In windows, you can copy from the drive to a hard disk, open files, create them, etc., but the system hangs (no BSOD) whenever a file is moved to the floppy drive using the copy, move, sendto, or drag-and-drop features. It must be some kind of software issue, but not sure how to fix it. Any ideas what's causing this?

I'd say the biggest reason I won't switch is because my hardware is so incredibly old nobody would ever bother writting drivers for it ;*) I'd be stuck with some annoying VGA screen with at most 256 colors. One thing Microsoft doesn't bet enough credit for is that they at least attempt to keep programs running across different versions of windows, even when they were coded badly. Most people would say have a registry filled with crazy fixes for old and never to be used again software (turbotax95 comes to mind) in XP is just silly. However, that's one fewer bug reports they get from that one guy out in Boofoo who still uses it for some incredible reason or another. A major oversight of all current developers is the notion that all users have direct internet access. Another is that they have a fast enough connection that a few dozen MBs is a 'short' download. If you've ever been on the receiving end of that, you know how blasted annoying it can be.