shaddam

tested this some time ago... Rank 2: Heroes of Might and Magic 5 (windows version masq. for install + kernelx + patch 1.41 (i think)) Heroes of Might and Magic 5 - Hammers of Fate (windows version masq. for install + kernelx + patch 2.0) Rank 4: Heroes of Might and Magic 5 (with patch >= 1.5 - saving is not working anymore, no folder found) Heroes of Might and Magic 5 - Hammers of Fate (with patch 2.1 - saving is not working anymore, no folder found) Supreme Commander (numerous missing exports) Rank 3: BTAS: Zak McKracken - between time and space (http://www.zak2.org/zak2/cms/front_content.php?idart=33&idcat=1&changelang=2) (wxWidgets bug for windows9x systems, worked around by kernelx)

Warhammer: Dark Omen (1998), a HOTU - TopDog. A tactical realtime game, pretty hard but very realistic, with friendly fire, moral and physical correct artillery. I Loved it.

update on an alternative PDF Viewer (Opensource, slim+fast, multi-platform, PDF support >1.4), Sumatra PDF v0.8 http://blog.kowalczyk.info/software/sumatrapdf/ works on win98se but with smaller flaws (e.g. menubar is missing,... ) a win9x maintainer is needed for testing and providing smaller fixes (which seems to be welcome, see post http://blog.kowalczyk.info/forum_sumatra/t...77&Posts=1)

also try: http://blog.kowalczyk.info/software/sumatrapdf/

if you calculate it in percentage it is enormous increase... 1MB > 3.6MB -> astonishing increase by 260%! second reason for calling it bloated, they introduced features in the reader which are hardly be used even in an PDF editor ... so the taskbar gets also bloated, introduction of errors... etc. but you are right compared against the bloatware of acrobat... it pretty slim, but i don't like the direction of development it looks like they try to copy acrobat... i would like if foxitreader stays feature minimized like the first releases.

news from foxitreader version v2.1 is out. but (from my experience) not recommendable anymore for win9x users... to bloated, instablities , seems not testest at all for win9x systems :/ personally i stick on version 1.3 build 0930 http://us03.foxitsoftware.com/foxitreader/FoxitReader21.zip ...but there is hope! a new project, even opensource and based on two pdf render engines, sumatra pdf reader v0.7 very stable, very comptible, very small, support pdfversions > 1.4 & and not footstep in system (no install, no registry entries...) very promising! http://blog.kowalczyk.info/software/sumatrapdf/

hello, was also trying a agp 7600gt on win98se, amd64 4000+, 1GB ram, mobo gigabyte nforce3... exchanged my geforce 5700 against a 7600gt, was detected on bootup, drivers freshly installed , was able to change resolution and seems to work. but got some graphical 'glitches' in some games, then if found out that in the driver menu from nvidia the card was listed as 'unknown' but options were available. so i got the feeling this glithces maybe coming from the wrong expectation of the driver of hardware.... someoneelse got such behaviour? greetings

Hi,Please download again and install this 5-28-2007 revised driver [14.5 MB]: http://www.mdgx.com/files/NV8269.EXE Then please post in this forum: http://www.msfn.org/board/?showtopic=97140 any errors you may encounter during install [hopefully there won't be any ]. Thanks for your feedback. Best wishes. thanks, mdgx, problems are solved now! one question on your registrytweaks: your version: [HKEY_LOCAL_MACHINE\Software\NVIDIA Corporation\Global\Global\OpenGL] "ShaderObjects"=dword:00000001 from coolbits 2.0: [HKEY_LOCAL_MACHINE\SOFTWARE\NVIDIA Corporation\Global\OpenGL] [HKEY_LOCAL_MACHINE\SOFTWARE\NVIDIA Corporation\Global\OpenGL\Debug] "ShaderObjects"=dword:00000001 which version works, both? greets

hello MDGx, thanks for win9x version of the nvdia driver (NV8269.EXE), but got a installation problem. system: win98se german, 1gb ram, nforce 3 board, Geforce 5700 AGP, uSP2.1, nvidia driver 53.06 -> tried to install NV8269.EXE -> stops in process with message 'setup was unable to read the following registry value: system\currentcontrolset\services\class\display000\default\mode Installation will be terminated' -> failed installation DiD NOT remove all remainings, uninstall entry remains with a 'pci managment driver'??? (AGP driver? PCIEXPRess driver?) -> removed all GFX drivers per uninstall and remainings by hand, registrycleaner, set GFX to 'standard pci driver' -> tried again to install NV8269.EXE -> failed again , removed again all stuff and installed 53.06 :/

Download here: http://www.nandlstadt.com/beta.htm Thank you very much ! ... one question, in some sense it is a fork of gape's pack, because it includes newer available updates which were not included at all in the original pack. How these extensions are selected? because if we look here or at the autopatcher project there should be many more new updates available since gape's pack. http://www.msfn.org/board/complete_list_ho...8se_t84886.html

Heroes of Might and Magic 5. patch 1.5 - save behaviour changed, seems not to able to create save files under win9x anymore (but able to load old one), versions up to 1.41 work without problems Heroes of Might and Magic 5, extension hammer of fate patch 2.1 - save behaviour changed, seems not to able to create save files under win9x anymore (but able to load old one), versions up to 2.0 work without problems Supreme Commander, - way to much dependencies missing from winXP, but at least the XACT audio extension seems for win2000 to be implantable from XP maybe also true for win9x

hello thanks for this pack also available for german windows.... some reports after install everything (german win98se): - after install, movieMK.exe won't work, missing export 'die datei shell.new ist verknuepft mit export-shlwapi.dll:shrregisterValidatetemplate' - on almost every part of update there was an codepage conflict on qfecheck.exe flipping between german & englsih version (- not a bug: conflict between kernel update pack and WUPG, don't notice each other and installing conflicting backup mechanismns)

again, no success.... :/ someone asked me for tihiy's windows 9x version masquerading tool... seems difficult to find in the deepness of this forum so here the link: http://www.msfn.org/board/index.php?showtopic=37738 download: http://simplestas.nm.ru/w98hack/

another (well know?) partition resizer, freeware, DOS-based, support up to 2TB download: http://www.zeleps.com/Files/PRESZ134.ZIP beside... someone got (positive) experience on 'mixed' environments, (newer) parts from freedos + win9x ? e.g. the emm386 substitute which seems to use less low memory... good for old games & MS emm386 seems to have for my new hardware an problem in detection upper memory blocks... :/ freedos base tools http://www.freedos.org/cgi-bin/freedos-lsm...?q=d&a=base

thank you mdgx, but didn't work for me... same problem... 'cannot load...'

Older Orca 1.x + 2.x versions run ok on all 9x OSes, as far as I am aware.Please see this post to learn how: http://www.msfn.org/board/?s=&showtopi...st&p=568281 HTH hmmm... installed KUP v0.27 with unicode support, removed .msi checks for win9x with orca on finereader 8... installation started but breaks later with 'unable to load unicows.dll' which is available in windows/system and also part of the finereade package.... some ideas someone?

sysinternal seems to wrap the ndll also to win98... maybe this is one of the used functions http://www.sysinternals.com/Utilities/NtfsWindows98.html

Good luck. I've bashed my head against this while for quite some time, and every time I think I have it figured out some new and seemingly completely random problem pops up. winset.exe was may latest desperate attempt, but even that fails. Well, do you know AutoIt? I really don't have much time to work on this at the moment, but if you can figure it out yourself I'll be more than happy to include the fix in the next release. Search through UniExtract.au3 for references to WIN32. These are the places where I'm doing different things depending on the version of Windows. I'm sure there has to be SOME magic combination of enget, envset, and winset that would make this work, but I sure haven't been able to find it. If not, I'll continue working on this later on when I get some more free time. ok... do some tries with the UniExtract.au3 script... introduced that... but not sure if it was helpful...but shouldn't do harm ; Parse filename ;$filedir = stringleft($file, stringinstr($file, '\', 0, -1)-1) ;$fileext = stringtrimleft($file, stringinstr($file, '.', 0, -1)) ;$filename = stringtrimright(stringtrimleft($file, stringlen($filedir)+1), stringlen($fileext)+1) if @OSType == "WIN32_NT" then FilenameParse($file) else FilenameParse(filegetshortname($file)) endif changed to more ENV Var. based oldpath buffering ; Set environment options for appropriate version of Windows if stringright($debugdir, 1) <> '\' then $debugdir &= '\' $debugfile = filegetshortname($debugdir) & 'uniextract.txt' if @OSType == "WIN32_NT" then $cmd = @comspec & ' /d /c ' $output = ' 2>&1 | tee.exe ' & $debugfile envset("path", @scriptdir & "\bin" & ';' & envget("path")) else $cmd = @comspec & ' /c ' $output = ' | tee.exe ' & $debugfile ;$oldpath = envget("path") ;envset("path", filegetshortname(@scriptdir & "\bin") & ';' & $oldpath) envset("path", filegetshortname(@scriptdir & "\bin")) runwait($cmd & filegetshortname(@scriptdir & '\bin\winset.exe') & ' oldpath=%path%', @windowsdir, @SW_HIDE) runwait($cmd & filegetshortname(@scriptdir & '\bin\winset.exe') & ' path=' & filegetshortname(@scriptdir & '\bin'), @windowsdir, @SW_HIDE) endif ; Cleanup Win9x path due to AutoIt EnvSet() bug if @OSType == "WIN32_WINDOWS" then $cmd = @comspec & ' /c ' runwait($cmd & filegetshortname(@scriptdir & '\bin\winset.exe') & ' path=%oldpath%', @windowsdir, @SW_HIDE) ;clear oldpath, if later on (second) startup exist path can be recovered runwait($cmd & filegetshortname(@scriptdir & '\bin\winset.exe') & ' oldpath=', @windowsdir, @SW_HIDE) endif but one problem seems also to be the Not calling of this cleanup code in Error/problem case... then i got problems with the run of decompressors... runs with the removal of the $CMD part...but introduce the problem sometimes with missing the end of this programm call... uniextract window stays forever... tried to fix it with an processwaitclose ...but seems also not to work in all cases splashtexton($title, t('TERM_TESTING') & ' NSIS ' & t('TERM_INSTALLER'), 300, 25, -1, $height, 16) if @OSType == 'WIN32_WINDOWS' then runwait($7z & ' l "' & $file & '"' & $output, $filedir, @SW_HIDE) ProcessWaitClose($7z,600) else runwait($cmd & $7z & ' l "' & $file & '"' & $output, $filedir, @SW_HIDE) endif but overall... i can exctract with this code ... but uniextract wont finish and therefore destroys my PATH Var.... Thoughts?

Unfortunately, this is somewhat of a known issue. AutoIt and Windows 9x seem to have a whole lot of difficulty agreeing on the PATH, so I've been hacking awaay at various workarounds for the last few versions. You can read through this thread for some of my frustrations with this issue (also look for some of drugwash's previous posts - it sounds like he had the same issues). I'm going to continue to work on that when I have time, but Windows 9x is not officially supported, so this is a "when I have the time" kind of issue. thanks nitro for further investigating this topic.... i also tried to pindown the problem.... 'winset.exe' works... for instance, if start uniextractor with this bat: start.bat ''winset path2=%path%;c:\uniextractor;c:\uniextractor\bin uniextractor.exe winset path=%path2%'' ... the path variable is recovered succesful & not destroyed (but uniextractor is also not working.... :/) found also your topic on autoit forum... bug is known but no progress here.... http://www.autoitscript.com/forum/index.php?showtopic=15053 i'm highly intrested in helping solving this bug because your tool is extremely uselful especially for older OS because strange installation packages are often the only reason for the not-working of software on win9x.... so if can help in some way testing autoit scripts or other stuff??

hello got a bug report: i'm using win98se(german) +usp2 and version 1.4.1, 1.4.2, 1.5 of uniextractor (with and without installer) simply not working... after some detection of type of installer it always stated ' ... seems to be supported but someting went wrong...' ... this time i find maybe one or teh reason: even the zipversion seems to delete my whole PATH variable! after the execution of the executable the variable was overriden (not appened!) by the path of installation of uniextractor, and nothing moreinside! to verify i reboot, after an reboot of teh system PATH was correctly set by autoexec.bat and afterward destroyed on execution of uniextractor.... :/ hope this helps...

thank your for fast creation of the german version. ....and of course maximum-decim & and all other distributing guys!

hmmm... another (russian) site with the topic new drivers & win98se http://bust.narod.ru/win98.html translation maybe with this... http://webtranslation.imtranslator.net/ ... besides, can recommend the new realtek v3.97 ac97 driver... since v3.95 it runs like charm again on win98se (they fixed an looong ageing install problem)!

hello <snip> IEXPLORE executed an invalid instruction in module FLASH9B.OCX at 016f:300512e8. Registers: EAX=02994b60 CS=016f EIP=300512e8 EFLGS=00010246 EBX=00000002 SS=0177 ESP=00649dec EBP=00649e20 ECX=029c6060 DS=0177 ESI=029c6100 FS=22af EDX=30206708 ES=0177 EDI=00000005 GS=0000 Bytes at CS:EIP: 0f 77 8b 46 38 db 80 88 00 00 00 51 db 40 64 51 Stack dump: 0064a32c 029c6100 029c5780 00000000 00649eec 029c6100 0064a32c 3e800000 fe6fb8d8 00000000 <snip> i'm not totally sure but... the instruction pointer points to the hex-code "0f 77" which is the mmx instruction 'emms' (clear mmx register -> ready for FPU instructions) ... but mmx is not supported by pentium pros. so it is a REAL bug which should be reported to the flash developers and fixed by them because their program detected CPU capabilities wrong which is dangerous also for newer hardware. pentium pro capabilities http://www.pcguide.com/ref/cpu/fam/g6PPro-c.html cpu instruction list: (search for "0f 77") http://nasm.sourceforge.net/doc/html/nasmdocb.html hope this helps...

fastvid enables some pentium pro/2/celeren specific functions like write combing for the framebuffer memeory range of the videocard... this means memeory writes in thsi regions are always done in larger chunks. example: writing of 4 32bit values to 0x40000000- 0x4000000f (video frame buffer) ... normally 4 memory transfers are done which is slow because the natural width of memory transfers is 64bit. write combining waits until 64bit are together to do an 'combined write' -> leads to double transfer speed. but why not doing this for all memory? because of the 'weak ordering' ... if we do this for normal memory ranges (normal code, normal data) in some circumstances this can lead to errors. example: writing 32 bit to 0x30000000, reading 32 bit from 0x30000000, writing 32 bit to 0x30000004 without writecombing the read value is the correct one (the first written) with it is wrong (the value before writting). so this technique can only be done to memeory ranges which don't rely on correct ordering of reads & writes, like video memory. for k6 processors the same featuring tool (CTU) http://www.k6plus.com/index.php?name=Downl...getit&lid=9

http://www.intel.com/design/pentium4/manuals/index_new.htm maybe i don't understand your point but i can't find references for automatic memory shifting of virtual memory... wikipedia explanation of virtual memory managment... as you can see the virtual memory chunks are contiguous (so don't seems to mapped again to another space) and alos fragmented... spaces between kernel32.dll and user32.dll http://en.wikipedia.org/wiki/Virtual_address_space From microsoft article: "...Virtual memory fragmentation is a condition where virtual memory is available for a process, but none of the virtual memory blocks that are available are of a significant size." From: http://support.microsoft.com/kb/325044 so...at least MS Windows can't reshape the virtual memory outfit of an running process. if the virtual addresspace is fragmented neither MMU or OS can do anything (without breaking a application which needs the granted addresses)