andreww@uniwa.uwa.oz (Andrew John Williams) (04/13/91)
Hi- I have been converting gifs to .BMP files to use as wallpaper, hoping to have a large (1024x768x256c) file as a backdrop. Unfortunately, Windows seems to crash if I try to install a file larger than around 260k or so as a wallpaper. (257894 bytes workes, 262000 doesnt). At first I thought it was the type of file, but it definitely seems to be the size. (I was trying OS2 .BMPs, and Windows compressed and uncompressed formats, to see which gave the smallest file size. Why did microsoft support an image compression standard so much worse than GIF???????). If I select a large BMP from the desktop section of the control panel, it grinds the disk for a while and thinks, then exits with an unrecoverable application error, and the program manager crashes soon after. If I edit win.ini and make the wallpaper field point to a large BMP file, then windows never gets as far as putting it on screen. (It shows the logo, blanks the screen, displays the cursor, then exits with no error message). What can I do to try and solve this problem? I have seen posts from people using 1024x768x256 bitmaps as wallpaper- it must be possible! My system is a 386/25, with AMI bios, C&T chipset, Tseng ET4000 card (from Tseng), Tsengs 1024x768x256 windows driver, 4Mb of ram, using himem.sys. I can display all of the images ok, even full screen, using Windows image viewers, but I can't install them as desktops! Andrew Williams Physics Department, University of Western Australia. andrew@earwax.pd.uwa.oz.au OR andreww@uniwa.uwa.oz.au (note the extra 'w')
cwang@copper.ucs.indiana.edu (Ted Wang) (04/14/91)
andreww@uniwa.uwa.oz (Andrew John Williams) writes: >Hi- I have been converting gifs to .BMP files to use as wallpaper, >hoping to have a large (1024x768x256c) file as a backdrop. >Unfortunately, Windows seems to crash if I try to install a file larger >than around 260k or so as a wallpaper. (257894 bytes workes, 262000 >doesnt) (stuff deleted) I have no problem when using BMP files as large as 417K for my windows desktop background. However, it crashed in enhenced mode when the BMP file is larger than 470K. In standard mode, I can even use files as large as 750K for my windows desktop background. I've posted a news to this group yesterday and got a response from another person who has the same problem as I have. Our hardware configuration is: cpu: 80386-25 with 64K cache memory: 4MB monitor: SONY 1304 video card: Orchid PROII with 1MB RAM And I've installed a Cyrix 80387-25 math-coprocessor. > Andrew Williams > Physics Department, > University of Western Australia. > andrew@earwax.pd.uwa.oz.au OR > andreww@uniwa.uwa.oz.au (note the extra 'w') Ted cwang@copper.ucs.indiana.edu -- Ted Wang <cwang@copper.ucs.indiana.edu> Department of Computer Science Phone #: 812-339-4701 Indiana University Address: 928 S. Henderson Bloomington, Indiana Bloomington, IN 47401
smsmith@hpuxa.acs.ohio-state.edu (Stephen M. Smith) (04/14/91)
andreww@uniwa.uwa.oz (Andrew John Williams) writes: > >Hi- I have been converting gifs to .BMP files to use as wallpaper, >hoping to have a large (1024x768x256c) file as a backdrop. >Unfortunately, Windows seems to crash if I try to install a file larger >than around 260k or so as a wallpaper. (257894 bytes workes, 262000 >doesnt)... > If I select a large BMP from the desktop section of the control >panel, it grinds the disk for a while and thinks, then exits with an >unrecoverable application error, and the program manager crashes soon >after. If I edit win.ini and make the wallpaper field point to a large >BMP file, then windows never gets as far as putting it on screen. (It >shows the logo, blanks the screen, displays the cursor, then exits with >no error message). > What can I do to try and solve this problem? I have seen posts >from people using 1024x768x256 bitmaps as wallpaper- it must be >possible! > My system is a 386/25, with AMI bios, C&T chipset, Tseng ET4000 >card (from Tseng), Tsengs 1024x768x256 windows driver, 4Mb of ram, using >himem.sys. I can display all of the images ok, even full screen, using >Windows image viewers, but I can't install them as desktops! > andrew@earwax.pd.uwa.oz.au OR > andreww@uniwa.uwa.oz.au (note the extra 'w') Hi Andrew: Funny that you ask this question now--another person on the net asked this same question a couple days ago. Since he had the same monitor and card as I do (Orchid Pro II, Sony 1304), I was also curious if it failed on my machine. So I converted a large .gif file to .bmp and tried to display it in enhanced mode. It didn't work; in fact, EXACTLY the same thing happened to me as happened to you. BUT, you can display large .bmp files in standard mode. You just can't do it in enhanced mode. I tried a 787k .bmp file (1024x768x256) as wallpaper in standard mode and had NO problem. But I also get an "unrecoverable application error...terminating current application" if I try the same thing in enhanced mode. I also tried to do it with a 590k .bmp file (768x768x256) with the same results. So it's not your hardware--for some reason you just can't display large .bmp files as wallpaper in enhanced mode. Steve Smith smsmith@hupxa.ircc.ohio-state.edu
tneff@bfmny0.BFM.COM (Tom Neff) (04/15/91)
I can verify the problem with big BMP's in enhanced mode. I have a 486 under DOS 4.0, and a Boca SuperVGA+ (another Tseng ET4000 chipset card, like the Orchid II). My monitor is an NEC 4D but *really* fellas, you ought to know that's got nothing to do with the problem! :-) I was crestfallen after spending nearly a meg on a gorgeous Yosemite bitmap (you don't think I'm gonna leave one of those OTHER kinds of GIFs sitting around as my desktop, do ya???!) and having WIN /3 croak while loading it. I can only assume that Windows manages its Enhanced mode memory in such a way as to leave only ~500k for the desktop bitmap. Perhaps MS will fix this in a future release.
gb7@prism.gatech.EDU (Joe Bradley) (04/15/91)
One thing that works for me is to make my BMP just a little smaller than full size; i.e. I have an Orchid Pro II which I run at 1024x768x256. I scale my BMP images to 1020x764x256. This leaves a small border around the image which actually looks kind of nice, and will load in enhanced mode. I have a machine at work with a 1280x1024x256 display system. I do the same thing there, making the BMP 4 pixels smaller in each direction. It still works in enhanced mode. Joe -- G. Joe Bradley | INTERNET: gb7@prism.gatech.edu Georgia Tech Research Institute | COMPUSERVE: 76064,1673 Modeling and Analysis Laboratory | PHONE: 404-894-3548 Atlanta, Georgia, 30332 | FAX: 404-894-7227
harold@wam.umd.edu (James B. Harold) (04/15/91)
I'm not graced with 1024x768x256 mode, but I had the same problem
with 1024x768x16 mode on my ATI VGAWonder+. I also solved the
problem by making the BMP slightly smaller (e.g.,1020x760). When
that worked I assumed that the problem was with the driver. It
looked as though the BMP wasn't being placed correctly--that it
was appearing a few pixels below the top edge of the screen. I
thought that if that were the case, maybe the bottom edge of the
BMP was overwriting another section of memory, causing the UAE.
This all makes me a bit suspicious of the memory
limitation diagnosis. And yes, I'm running in Enhanced mode.
Comments? Who out there hasn't had these problems?
James Harold
harold@lpf.umd.edutimur@seas.gwu.edu (The Time Traveler) (04/16/91)
>I tried a 787k .bmp file (1024x768x256) as wallpaper in standard >mode and had NO problem. But I also get an "unrecoverable application >error...terminating current application" if I try the same thing >in enhanced mode. I also tried to do it with a 590k .bmp file >(768x768x256) with the same results. > >So it's not your hardware--for some reason you just can't display >large .bmp files as wallpaper in enhanced mode. > Not true. It's your driver, not Windows. My roommate has a Nec 4D with a Hercules Graphics Station (1024x768x256) plugged into a 386/33 machine with 4MB. He can do it no problem. ----------------------------------------------------------- The Time Traveler I used to love her a.k.a. Timur Tabi But I had to kill her Internet: timur@seas.gwu.edu I had to put her six feet under Bitnet: HE891C@GWUVM And I can still hear her complain - Guns 'n Roses
brent@well.sf.ca.us (Brent Southard) (04/17/91)
There seems to be a bug in Windows which prevents the use of 1024x768x256 bitmaps as wallpaper. However, I've found that if you edit your bitmap using Paint Shop (or something similar) to have one less line (767), it will display and not crash your system. I am also using a Tseng 4000 type board, so I don't know if this is driver specific, but the fix works for now... Brent -- brent southard (313) 643-1971 | usenet: ...!well!brent ImageTech Corp (313) 353-7900 | bix: brent "When frog licking is outlawed, only outlaws will lick frogs."
07790@tanus.oz.au (Brant Campbell) (04/21/91)
Basically, this topic of large bitmaps as desktops is really not an issue - it
is crap that large bitmaps can't be used - cause they can - and I know that
problems are sometimes caused by the memory on the video card, so it can be
hardware related! At work one guy is using a converted GIF to BMP that is
almost 900K - it works fine looks bloddy brilliant - he also has a Compaq with
an approximately $3000 priced video system. (Buy the good hardware and get
results!)
Brant Campbell
Microsoft Product Support - Australia
UUCP: {munnari}!jabaru!anthos!tanus!07790
INET: 07790@tanus.oz.aubcw@rti.rti.org (Bruce Wright) (04/22/91)
In article <1991Apr13.125238.17769@uniwa.uwa.oz>, andreww@uniwa.uwa.oz (Andrew John Williams) writes: > > Hi- I have been converting gifs to .BMP files to use as wallpaper, > hoping to have a large (1024x768x256c) file as a backdrop. > Unfortunately, Windows seems to crash if I try to install a file larger > than around 260k or so as a wallpaper. (257894 bytes workes, 262000 > doesnt). At first I thought it was the type of file, but it definitely > seems to be the size. (I was trying OS2 .BMPs, and Windows compressed > and uncompressed formats, to see which gave the smallest file size. Why > did microsoft support an image compression standard so much worse than > GIF???????). I can't add much to what's already been said about your specific problem, but I can understand why Microsoft didn't support GIFs in Windows. The GIF format is computationally inefficient - it is designed to be _small_, not _fast_. It's the classic tradeoff of time vs space. The idea of the GIF format was to reduce modem time for sending files over a phone line, and to reduce disk space at both ends - not to be a fast display format. In a GUI environment, you don't want things to be slow - GUIs tend to slow things down enough already. So you certainly don't want the _default_ compression format to be GIF - if you have any compression format at all you want it real simple and _fast_. Now why Microsoft didn't make GIF as an _option_ is another question; perhaps they thought that the reduction in speed would give people a bad impression of Windows when they used GIFs as wallpaper, etc. There are also some technical problems: I have done a fair amount of tinkering with low-level code to interpret GIF formats on various sorts of hardware, and the format introduces some problems for a GUI environment, of which the following list is a sample: 1) The GIF format does not have an easy way to find "scan line n" in an image without reading through the entire image until you find the beginning of that line - in other words, there's no way to index to a position, or to jump into the middle and find the proper reading frame and find the beginning of the desired line. Even if you find the proper reading frame you still have no way to know what line number you're looking at without having interpreted the entire image preceeding it. 2) Interpreting GIF format is somewhat tricky; many programs out there for doing this don't really do it properly (they may work with many GIF images but choke for some of them). You'd either have to build this code into every display and printer driver (imagine the possibilities for incompatible implementations given the plethora of problems with different GIF viewers that are out there), or you'd have to have the code to crack the GIF format embedded in Windows itself and feed a real BMP type structure to the device driver. This could be done in pieces so that you didn't have to make a copy of the entire GIF (which would sorta negate the purpose of having a GIF format), but because of problem #1 and the general efficiency hit of dealing with GIFs in the first place it wouldn't be very nice. 3) Many GIFs have more than 16 colors, which is all that Windows supports for many purposes anyway - programs that want to use more must do quite a bit of palette manipulation. Putting a 256-color .GIF as background would require a 256 color VGA driver (obviously), but it would also make it either impossible or ugly for another app to manipulate the 256-color palette for its own purposes (remember that the palette is a system- wide resource). Many pictures with 16 colors or fewer don't take that much different space using GIF or a compressed BMP format (yes, I know there are pathological cases, especially with some huge files), so that the incentive to use GIF for these simpler pictures isn't as big as it is for the more complex pictures. I suspect it's one of those things that would be sort of nice to have, but that you'd hardly ever use because of the penalties in performance and palette use that you'd have to live with. Maybe Microsoft will put it in, but (IMHO) it's sort of a marginal feature. It might be more useful for them to make it easier to generate the compressed forms of BMPs using the standard user-level software distributed with Windows, and maybe distribute a GIF <-> compressed BMP converter so that anyone who doesn't know about any of the PD/shareware converters out there can still convert images. Bruce C. Wright
bcw@rti.rti.org (Bruce Wright) (04/22/91)
I think I ought to clarify something in my previous article about GIF format. In article <1991Apr21.183828.9406@rti.rti.org>, bcw@rti.rti.org (Bruce Wright) writes: > 1) The GIF format does not have an easy way to find "scan line > n" in an image without reading through the entire image until > you find the beginning of that line - in other words, there's > no way to index to a position, or to jump into the middle and > find the proper reading frame and find the beginning of the > desired line. Even if you find the proper reading frame you > still have no way to know what line number you're looking at > without having interpreted the entire image preceeding it. Before anyone unfamiliar with GIF internals jumps in with the suggestion that Windows could simply keep a table of indices into the GIF which pointed to the beginning of each line, I should hasten to point out that you need more context than just the scan line number. The additional context is sufficiently large that this strategy would require significant amounts of RAM - largely offsetting the benefit of using GIF in the first place. Bruce C. Wright