eidenk

Those extensions are very common filetypes. They are not found in exes or dlls. png and gif are usually images. inf and ini are usually text files. mid is usually a midi sequence. mpg and asf are usually videos or sometimes audio. It is not clear what you exactly mean BTW.

I just grabbed the new D3D9 and D3D10 dlls from the official pack and copied them to the system dir in case I download a recent app needing one of them. Can anyone confirm that DirectX 9.0c in general breaks DirectMusic by removing the reference to the gm.dls sounfont in the registry ? Test Direct Music with the DXDiag tool to see if it is broken. I did download MS DirectMusic Producer and could not get it to run because it could not find the gm.dls soundfont in the registry. After a bit of googling I read that DirectMusic had been deprecated by MS and that DX 9.0c was breaking it on purpose. In case it is broken, the following reg file should fix it : REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectMusic] "GMFilePath"="C:\\WINDOWS\\SYSTEM32\\DRIVERS\\GM.DLS" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectMusic\SoftwareSynths] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectMusic\SoftwareSynths\{58C2B4D0-46E7-11D1-89AC-00A0C9054129}] "Description"="Microsoft Software Synthesizer" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectMusic\SoftwareSynths\{B37D67DC-9823-2300-D67D-0000320A608C}] @=hex:d7,07,02,00,00,00,12,00,03,00,30,00,08,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectMusic\Defaults] "DefaultOutputport"="{58C2B4D0-46E7-11D1-89AC-00A0C9054129}" I copied the entire DirectMusic key but I think I only found the GMFilePath missing. PS : On Windows ME, DX9.0c does not install if SFC.DLL, SFPDLL.DLL and SMGR.DLL are missing, which happens if System File Protection and/or System Restore is removed from the OS (not sure anymore which of them those files actually belong to).

On my machine DotNet hooks some dlls into windows explorer and they get loaded with it at startup. Those files are : mscoree.dll, mscorjit.dll, mscorlib.dll, mscorwks.dll, fusion.dll. C:\WINDOWS\SYSTEM\MSCOREE.DLL C:\WINDOWS\MICROSOFT.NET\FRAMEWORK\V2.0.50727\MSCORJIT.DLL C:\WINDOWS\MICROSOFT.NET\FRAMEWORK\V2.0.50727\MSCORWKS.DLL C:\WINDOWS\ASSEMBLY\GAC_32\MSCORLIB\2.0.0.0__B77A5C561934E089\MSCORLIB.DLL C:\WINDOWS\MICROSOFT.NET\FRAMEWORK\V2.0.50727\FUSION.DLL There is nothing dotnet related in the run keys and I don't know for sure where they load from as I can't find reference to them with advanced startup tools so far. Besides their CLSID keys (Fusion.dll has no CLSIDs, it apparently loads because it a dependency of MSCORWKS.DLL) they appear referenced in the registry under the following keys : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Components HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs So they maybe loading from one of those two keys unless they start from another location containing just a reference to one of their CLSIDs. If windows explorer is terminated and restarted all those files don't appear anymore as modules loaded by explorer because they are actually not needed by it (like many other modules who load with it at startup BTW). PS : MSCORLIB.DLL cannot be found on the disk with explorer or the windows search because it is in the GAC (Global Assembly Cache) folders and their contents are totally unavailable to them. Some third party file managers are able to browse through them thouh and perform standard file operations copy, move, delete on the files contained in them (I use MeeSoft Commander for that). To the best of my observation on my own machine whose setup may not be typical and is certainly not a fresh install. Edit : I found out why those dotnet files were getting loaded on startup. It is because I had not properly uninstalled a shell extension called FF COPY. Weirdly it was an executable but the dragdrophandler shellex key left was apparently calling upon mscoree.dll only. Now that I have deleted this entry from the registry, no dotnet file loads on startup anymore. Saying that I did not take into account the GAC folders and that some new file must well hook into the system permanently to create the fact that they are hidden from explorer but I cannot find a trace of that with any tool.

This fault certainly happens because of a bug in the software IMO. I am not aware of a generic bug in Windows 98 which creates problems when closing MDI windows.

Yeah, it's called Rainbow Folder. There is also FolderIco. Sorry that's for colorizing icons not labels. For colorizing labels there is Xentient Labels but this one is not free.

Kristal Audio Engine ? But you would probably need to play your media files inside it rather than in a media player. And maybe a DJing application would be more suited to what you want to do. Have a look at what's on offer there : http://www.hitsquad.com/smm/. It's pretty complete as far as audio apps goes. You could also register on KvR and ask on this subforum : http://www.kvraudio.com/forum/viewforum.ph...cc6ab52d62eb08f Peeps are quite knowledgeable, friendly and helpfull there.

Well erpdude, not wanting to go off topic in this thread, but I think MS had all my attention as I exchanged enough emails about that vuln with them and posted about it on the sysinternal forums (which is also MS) in addition to my posts about it on here. I have further been contacted, on here by PM, about it by a certain Don Jackson, security researcher : He further wrote to me : In that post he backs MS claims that XPSP2 is not vulnerable to the Javascript exploit which in my observation is not correct. And weirdly for someone who claims to track gangsters he was not interested by another more complex exploit I had fully captured with all the IP adresses and transactions with the various sites involved in spreading another malware from an ukrainian site via a complex exploit. He did not answer a line about my offer to forward him all details I had of that new one. When I finally pointed out those two things to this Scott Berinato (see above who he is) with whom I subsequently exchanged a phone call and several emails for my interview, asking him if he had any idea why Don Jackson was not interested in other exploits I had discovered, he stopped replying to me and I haven't heard about him since nor have I rteceived any copy of his mag with the interview I gave him. I can't be bothered to get in touch with woody erpdude but if you want to, please feel free to point him to that post.

Glad to see you are back Gape.

This one maybe ? http://www.wcoyote.org/pubaccess/apps/Hand...e/HFFRSetup.exe It has a nice GUI and can use regular expressions for searching.

I have installed this latest unnoficial windows script update by hand and it seems at first sight to work properly with IE 5.5. Unfortunately it does not seem to fix a javascript exploit about which I exchanged a few emails with the (very distasteful and dishonest IMO) MS Security people a few months ago. I had hoped it would. An example of the exploit is here : http://homepage.ntlworld.com/eidenk/exploit.chm By running the chm file (which contains only 1 html page which itself contains only the javascript exploit code), hh.exe tries to connect to a website in Russia and download and execute a file on your local machine. Actually it doesn't download anything if you allow it go with your firewall (I hope you have one) because the site in Russia is now empty (It was infecting machines with a trojan nicknamed Gozi). Point is that this vulnerability is big and affects apparently any application using the IE runtime to render javascript, ie, HH.exe, Outlook, IE clones, etc... Can someone test and confirm that systems other than mine are also vulnerable ? If so, then maybe the baby could be passed to anonymous or someone able to patch that.

+1 and AFAIK it does not replace any system files.

@submix8c Delusion, is that what you suffer from ? Shall I answer you point by point or shall I not ?

There is a download link in the first post of this thread. Maybe that's what you are after.

Now what does IO.SYS do? AFAIK it defines basic hardware, grabs and processes some parameters, runs Config.sys/Autoexec.BAT, then tosses you to the command PROMPT awaiting input (didn't even imply you needed command.com). So go on and boot, delete it from both the HDD and Memory. What now? Well you said that IO.SYS (in DOS/Winx.x) is the primary Hardware Interface in conjunction with Command.com. If you say that you imply it is needed. Besides IO.sys appears to be a 32bit file. DOS is exclusively 16bit AFAIK. So where is DOS in IO.SYS ? I repeat - THAT and every single bit of code inside is DOS and nothing else! Inside what ? In 32bit IO.SYS ? Without it, no Programs can access one whit of the hardware. Therefore, Windows is DOS-based. Programs access the hardware through VXDs under the supervision of VMM. See below. And in NT-type Windows, the NTLDR makes them OS-based. Without these, NOTHING runs, get the picture? I must assume NTLDR (not having looked inside it yet) does very similar processing. These two items prepare the remainder of Programs to do their job (eg the HAL which is a pain in the a@@ to change without reinstall because of other dependencies). NTLDR means NT (OS) LoaDeR. It loads the OS. Period. You are confusing things. IO.SYS on 9x anf NTDLR on NT INITIALLY interact with the hardware. They are not responsable for hardware access after the OS is fully loaded AFAIK. Can you point out to some docs or specs proving your point ? Especially for 9x. edit - just did the same in VPC on 98SE "Safe/Command Prompt" then rebooted "Normal" - "The Following File Is Missing Or Corrupt - Command.com - Type the name...". NO WINDOWS! Same message when "Safe/Command Prompt". So how DID you test that on the WinME, hmmmm??? Did you even reboot? Yes mister I did reboot. And I even searched "My Computer" to make sure it was not loading a copy of it from an obscure location. BTW, in safe mode Windows MAY BE running on top of DOS but have you noticed how poor it is with regards to supporting hardwre notably ? The normal behaviour of VMM in normal mode is as follows : It seems that overall you are very eager to prove multiple core support for Win9x cannot be done. Are you on a mission or something ? And forget modifying 9x to use dual-core! It's definitely not worth the effort (ref. IBM stuff; look it up...). The systems specs are too radically different... Still, all-in-all, seemingly not worth the effort. @ohmss006 - Give it up; ain't gonna happen. Be happy with a jet-engine Win9x PC using 1 core. Genuises many on MSFN, but unless there are any takers for such a vast project (ain't heard from any volunteers yet) forget it... Pipe dream... @ohms006 - no takers, too much hassle; guess you're on your own

That's what MS says :

ME seems to boot significantly faster than 98SE.

You can upgrade from anything to anything if a proper installer/setup is written. Please avoid that kind of nonsense arguments. IO.SYS is the OS loader, after that it is not there/in use anymore AFAIK. As for command.com, it is not needed to either boot or for the operation of the OS (not even for running DOS programs). At least not on WinME. I have deleted all instances of command.com (as well as the C:\Windows\Command folder) from an install of ME in a virtual machine and I can boot it and run it normally, I can even run DOS programs except of course for command.com because it is not there anymore. So you'll have to find something else because it obviously does not work as you say. The DOS programs seem to be running thanks to DOSMGR.VXD, the MS-DOS Emulation Manager and V86MMGR.VXD, the MS-DOS Memory Manager. Here is a bit of information about them from the Windows 95 Device Driver Kit Virtual Machine Manager (VMM) Reference Manual : So ?

Try to merge this reg file : http://stashbox.org/29676/filelistdir.reg It does work here. I have just tested it.

infact, Windows 98 is more or less the GUI that runs on a DOS-based layer, so assuming now correctly i assume, Windows 98 does run on top of DOS. No, I don't think Win9x does run on top of a DOS layer. http://win32assembly.online.fr/vxd-tut1.html DOS is apparently used in the boot sequence of Win 95 and 98 (but not ME which is why it boots faster) but that's it. Once Windows is running there is no DOS layer running underneath it. Unless I am wrong but in this case you'll have to show where is this DOS layer that runs underneath the 9x GUI.

I think this is irrelevant as Windows does not run on top of DOS. As far as I understand, and I might be wrong, it is the virtual machine manager that is at the heart of windows and it provides an emulated layer of all the hardware (a virtual machine) to Windows. When a DOS program is run, it is provided a separate virtual machine by the virtual machine manager. So that implementing support for dual-core in Windows has got nothing to see with DOS IMO.

Thanks, I have just tried this build and it does not have the blur issue at all indeed it seems. It is actually a pleasure to use this one, versus a PITA, as you said, with the more recent builds.

Could you pack the 4.0.2091 folder you have and upload it on Rapidshare ?

Yeah I experience this issue as well, it's quite annoying.

OK, I had to hex another function in googleearth.dll and it seems to work now in a virtual machine without KernelEx installed so hopefully it is now working on any 98/ME system. http://rapidshare.com/files/43381739/Googl...n98-ME.zip.html (previous links updated) Edit : I have noticed a little problem with opening kml and kmz by double clicking them in explorer. It launches the installer instead of opening the files. Merging the registry file below should fix it. I'll include it in the zip if you have the same problems as well. REGEDIT4 REGEDIT4 [-HKEY_CLASSES_ROOT\Google Earth.kmlfile] [HKEY_CLASSES_ROOT\Google Earth.kmlfile\shell\Open\command] @ = "\"C:\\Program Files\\Google\\Google Earth\\googleearth.exe\" \"%1\"" [HKEY_CLASSES_ROOT\Google Earth.kmlfile\DefaultIcon] @ = "C:\\WINDOWS\\Application Data\\Microsoft\\Installer\\{407B9B5C-DAC5-4F44-A756-B57CAB4E6A8B}\\_2B2C7EB3_CABE_4D93_A602_E713B4B70BF9,0" REGEDIT4 [-HKEY_CLASSES_ROOT\Google Earth.kmzfile] [HKEY_CLASSES_ROOT\Google Earth.kmzfile\shell\Open\command] @ = "\"C:\\Program Files\\Google\\Google Earth\\googleearth.exe\" \"%1\"" [HKEY_CLASSES_ROOT\Google Earth.kmzfile\DefaultIcon] @ = "C:\\WINDOWS\\Application Data\\Microsoft\\Installer\\{407B9B5C-DAC5-4F44-A756-B57CAB4E6A8B}\\_4D974FE5_6550_4B16_A023_891582A344B2,0"

OK, thanks for feedback. I'll look into it tommorow and see if I can get it to work in a virtual machine on an OS that has not KernelEx installed.