Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Contact info
Forum
 
Other projects
   Altirra

Search

Archives

01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ Windows 95/98/ME and large amounts of memory

I still manage to find people that try running Windows 95/98/ME on modern systems. As a user, I understand that there is some software and hardware that only works on this OS series. As a programmer, I cannot wait for the day when users stop running it. The fortitude of Win9x as a protected-mode operating system ranks marginally higher than AmigaDOS and classic MacOS; it has process address space isolation, but the process databases are completely exposed at 64K-1MB and system DLLs and memory mapped files in the shared arena at 80000000-BFFFFFFF, so it's still easy to screw up the system by accident. In addition, there are a lot of useful features, such as full Unicode API support, that are only available on Windows NT based platforms. To be fair, the Windows 95 team had the Mission Impossiblesque task of bridging Win16 and Win32 on a 4MB 80386, and the success of Windows 95 had a great part in encouraging people to write Windows NT-compatible applications but there is only so much room for duct tape in a code base.

In case you haven't heard me mention it before, those of you who have large amounts of memory (>512MB) and are still running Windows 98, 98SE, or ME may be interested an article in Microsoft's Knowledge Base called "'Out of Memory' Error Messages with Large Amounts of RAM Installed." Basically, the problem is that on a system with a lot of memory and an AGP video card, the dynamic disk cache and the AGP aperture may consume an unreasonable amount of kernel address space. Since there is only 1MB of it under Win9x, this can cause kernel space to become critically crowded. The solution is to add entries to SYSTEM.INI to limit the size of the disk cache, thus preventing the problem.

I once fielded a bug reported by a QA tester for a commercial product, claiming weird instability on a particular Windows 98 system that turned out to have 1GB of RAM installed. While blaming bug reports on the tester's system is ordinarily bad form and a really lousy way to keep your bug count down, it happened to be the right decision in this case. Reducing VCACHE's limit not only made the application bugs disappear, but also fixed some strange issues the tester had been having with his Recycle Bin. Pulling 512MB from the system had the same effect. Also, limiting VCACHE also has another benefit in that it reduces the dynamic disk cache's tendency to swap everything out of memory when a lot of files are read, even if those files aren't going to be read more than once. I thus highly recommend applying the [VCache] MaxFileCache=n change.

As a side note, a poster on the forum recently helped me track down an irritating bug in VirtualDub's draggable video frames that was causing some instability on Win9x platforms. It happened because of a code fragment that I adapted from the MSDN Library documentation for WM_NCPAINT that supposedly helps you draw custom window frames. Well, the code fragment as given doesn't work, because it lacks an essential flag. GetDCEx() simply returns NULL and leaves the error code as NO_ERROR. You need to add 0x10000, called "an undocumented flag which can magically make GetDCEx call succeed" in Feng Yuan's GDI book, or DCX_USESTYLE by WINE, for the function to actually return a usable DC. It turns out that there is an even worse problem with the code as given because it causes window regions to be doubly freed! On Win9x, this results in an occasional crash in 16-bit GDI. (This particular problem with the WM_NCPAINT example is also colorfully documented in comments in the WINE source code.) After I fixed this issue, the poster's problem went away. So if you are using a Win9x platform, expect some stability improvements in edit mode in 1.6.4.

Comments

Comments posted:


The only reason we were still on W98 was because YOU didn't bring out WDM capturing until last month :-) :-) :-)

So it's not our fault is it? :-)

Since the release of 1.63 I've only been back on W98 for 30 mins!

regards
Simon

Simon Walters (link) - 08 02 05 - 06:27


Personally, since I managed to make Final Fantasy 7 run on my w2k (hard work, but I think you know about that...), I haven't touched a dos/win combo at all.
Now to make all my softwares run one way or another on Linux/WINE... That brings me to another matter: you mentioned once having written an OpenGL routine for Virtualdub that you deactivated due to gross incompatibilities, and since then you focus on DirectX support. Having been able to somewhat use your software on Linux in GDI mode due to huuuuge display bugs in accelerated mode (is it the wrapper? Is it DirectX itself? Is it your code?): do you have any intention of making a native Xfree version of Virtualdub (which would entail, for less forking, a common OpenGL development...)?

Just a thought...

Mitch 74 - 09 02 05 - 19:22


Final Fantasy VII is one of my favorite RPG games on PSX (Aerith... ~_~), but the PC port truly sucked. The biggest problem was that the NVIDIA TNT/TNT2 didn't support 8-bit paletted textures, and so Squaresoft's solution was to use OpenGL to convert textures in a Direct3D game. I was amused when a game with a 32MB RAM requirement needed you to have *300MB* of virtual memory available to avoid crashing on the world map, and asked you not to remove memory cards on a PC....

Not sure what's going on with the DirectX display mode on WINE, but given bug 829 in WineHQ's Bugzilla, I'm inclined to think there may be something goofy in WINE's DirectDraw support. Then again, I might have screwed up somewhere.

The OpenGL display mode is in 1.6.3 but isn't on by default because it is frequently slower than the DirectDraw driver. The long freeze bug that I was encountering seems to have since been solved by NVIDIA. However, the display code would be the least problems trying to make a native Linux port; matching video compression/decompression APIs and converting the UI would be a lot harder than finding a way to shove a bitmap to the screen.

Phaeron - 10 02 05 - 01:18


it needed 300mb virtual memory!?

chris (link) - 18 05 05 - 08:15


"To be fair, the Windows 95 team had the Mission Impossiblesque task of bridging Win16 and Win32 on a 4MB 80386"
And to do it with almost 100% compatiblity with Windows 3.x and DOS.

Yuhong Bao - 01 08 08 - 02:01


So true! While Windows 95 did some great things in retrospect, the poor thing needs to die already. You can run a Linux OS on the same hardware that has MUCH better stability and features, not to mention more compatibility. I'm trying to make a more user-friendly port for the poor folks still stuck with 95 an ME, got to get the word out there.

Mendel Potok (link) - 15 09 10 - 05:12

Comment form


Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
Name:  
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.



Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.