Sfor

Well. I think I do understand what is going on, now. The error message comes from the Windows printout buffering routines. It appears only when the function of "starting the printing after the first page is ready" is selected. In case of a direct file print there is no buffering, so there is no error message. As for the direct file printout. Depending on a printer driver the file does have just a few hundred bytes, or is not created, at all. So, the 24bit image conversion routines could be the problem, indeed. I tried the Windows Epson Stylus Color ESC/P2 printer. The result is a file with just two bytes in size. So, the problem is not related to just HP printers.

The problematic images do have 24bit color depth. But if it is a case with the color conversion problem, why the printouts are saved to files without reporting en error. Such a condition should be reported in both cases, as the conversion happens when saving to a file, as well.

Well, the problem is present on multiple computers with different printers. This should be enough to exclude a simple printer driver related problem. The related printers I can remember at the moment are HP DeskJet 6122 on USB cable, and HP 2500C connected through LAN with JetDirect 400N. ----------------------------------- On the other hand, everything seems to be working fine, when printing to a file. ----------------------------------- I can add yet another printer to the list. With HP LaserJet 4100MFP there is no error message, but there is no printout, as well. This time it was printed through an other Windows 98 computer acting as print server. The printer was connected through an LPT port.

I do have a Polish language version of Windows 98 SE USP 2.1. Recently, I've noticed problems with printing certain bitmaps. The problem is visible in many applications (IE, Opera, Vallen JPegger,...). Others (Open Office, GIMP,... ) are printing fine. In most cases it is enough to change the color depth of a picture to be able to print it. Without such a trick an error message appears: "There was an error writing to xxxxxxx for the printer (yyyyyyyy) There was a problem printing to a printer due to an unknown system error. Restart Windows, and then try printing again." The same situation happens on multiple computers with different printers. I have no idea what could be causing such a phenomenon.

Windows 98 SE USP 2.1 PL Revolution pack: 9.6.0 KernelEX 4.5 Beta 2 The polish language translation is fine with just one exception. All the polish characters in the "Close Program" window are replaced with "_".

Further testing considering the UltraVNC file transfers revealed the issue is present in UltraVNC viewer working on the Windows 98 system, only. Everything works fine on Windows 2000. The problem was present, when testing the newest UltraVNC viewer with the KernelEX running, as well.

The video driver used in this project does not support DirectX. So, video playback abilities of this compilation are very limited.

Well. I've encountered some serious problems with the Ultra VNC file transfers. I was able to download a file with VNC viewer runnig on Windows 98 system without a problem. But an attempt to send a file destabilized the local system. I'm planning to revert back to the TightVNC. As, the Ultra VNC seems to be too troublesome.

I was able to get the desired result through the file association. But, there are several conditions to be met. Apparently, Windows does check the type of the target application. If the type is unknown, or it is a 16 bit application the file name is sent a a short one. So, it is necesary to direct the output to a Win32 application. The full file path to the EXE file is necesary as well. In order to meet these demands I've used the C:\WINDOWS\COMMANDS\START.EXE application. As command line parameters I've used something like that: c:\xxx\batfile.bat "%1" But, the same trick does not work in the Send To menu.

The whole thing gets more and more complicated. So, I've decided to write own utility to do the job. After a brief test I've confirmed the LFN DOS extension makes possible for a DOS application to find a LFN while searching for a short file name. So, using a "proxy" DOS application I shoud be able to convert the short filename to the LFN one.

I've found no way to get the LFN from the short name with the use of FOR command. If the searched file mask refers to a short name, the output is also a short file name. FOR %%A IN (%1) DO ECHO %%A The %%A will be a short file name if the %1 is a short file name.

You did put quotes around the filename, didn't you? The problem is not related to copying files. What I'm trying to do is to run a .BAT file with a LFN as a command line parameter. The Send To option using /Windows/SendTo folder does not seem to care for the command line arguments provided in a .PIF file. The result is the same in case of both .BAT and .EXE.

I've been trying to feed a .BAT script with Long File Names using Send To folder or file association. For some reason Windows 98 sends just the short names, always. Is there a way to force an LFN to be passed through command line parameters.

I've encountered a problem with the UltraVNC 1.0.2. The server part does not seem to be able to work on some Intel based GPU hardware. I was unable to make it work on: - Intel 82845G Graphics Controler (driver version: 4.13.01.3205) - Intel 82865G Graphics Controler (driver version: 4.14.10.3732) So far, I was able to observe the problem on just two different computers running Windows 98. Since I do not have a good access on those two I was unable to test for all possibilities. Still, it looks like some kind of a general video driver incompatibility, or something.

I've been experimenting with the newer GOM Player 2.1.24.5013. There were no changes to the way it handles the MKV subtitles, apparently. On the other hand, I've confirmed, the same .SRT subtitles are handled correctly, when provided in a separate file. So, the workaround is to extract the .SRT files from .MKV.

In my case the non-profit use will not do, I'm afraid. I'm beginning the in field testing of the UltraVNC 1.0.2. If the reliability will follow the feature set UltraVNC will be a perfect tool. I've noticed, the TightVNC does not work with the standard VGA driver. It could be a problem in some video driver related situations. On the other hand RealVNC and UltraVNC are working fine in such circumstances.

I was able to compile a version with UltraVNC server. It looks like quite an useful tool for remote rapairs, but the english language version does not handle polish national characters in file names. So, for the moment, it's next to useless to me. Have anyone been able to compile a version with different than english language setting?

Well, I tried to install it on Windows 98, already. It says kindly: "This program requires Windows NT version 5.0.2195 or later."

I have encountered a problem with building the image after changing the Basic - Windows 98 Live CD Base settings. When Set Default Language or Set Default resolution settings were changed the script ends with a message: ExtractFile - Failed to expand file: [shell95.bat] to: [%BaseDir%\Temp\Win98LiveCD\APP_TMP\Win95Shell\] It happens also, after returning the settings to the previous values. The only solution is download the script, again. (The problem happens on Windows 98 PL with KernelEX.) Also, I'm quite interested in adding a VNC server application to the build. ------------------------------- Looks like the 01-WIN98_BASE.script file gets decreased to just 64Kb, after altering the script settings. Since it should be about 8MB in size, the difference is quite significant.

Updated Free VNC software list: TightVNC 1.3.10 - supports file transfers - supports clipboard operations - the client freezes on slow connections, when the whole desktop has to be updated - does not work with the generic VGA driver TightVNC 2.0.2 - supports file transfers - supports clipboard operations - server does not work with Windows 98 - client requires KernelEX to function with Windows 98 - the file transfer function is not compatible with TightVNC 1.3.10 - no proper support for the national characters - java client does not support file transfers - java client does not support capital national characters Real VNC (free edition) - does not support file transfers - does not support clipboard operations - works fine on slow connections (very reliable) Tiger VNC 1.0.1 - does not support file transfers - supports clipboard operations (I had no opportunity to test it in the field) Ultra VNC 1.0.2 - supports file transfers - supports clipboard operations - sending a file can lock Windows 98 - does not work on Windows 98 with Intel 845/865 graphics chipsets - Windows 98 hangs during reboot, if there is an active connection with VNC server. -------------------------------------- from the original post: The newest TightVNC 2 does not work in Windows 98. So, I've decided to look through the available free alternatives, again. Is there any other VNC software worth considering? I can not count on the TightVNC development team to remove the bugs, apparently.

Well, I do have a problem with USB devices drive letters on Asus Eee PC 900. But, It's a bit different story, as there are two drive letters for each USB drive. One letter is from BIOS USB support and the other comes from Windows. Everything seems to be working fine (I mean just one drive letter), when Windows works in APM mode. After enabling ACPI the Windows forces another drive letter to be assigned. Since the ACPI is quite useful on a mobile device, I have learned to live with the issue.

Well, I've been playing around with a few Windows 98 compatible players a while ago. As the result I've managed to obtain a sufficient h264 coded video playback efficiency (on a single core P4 without GPU h264 acceleration), with just one flaw. None of the players I'm using seems to be able to handle subtitles sufficiently. GOM Player (2.1.21.4846) - does not handle some of the subtitles formats available inside of mkv files. - during the time a secondary subtitle is visible the main subtitles are ignored - some of the mkv subtitles are displayed delayed and/or for too short time period. BS Player free (2.43) - problems with backrard rewind function. The first key press rewinds only to the last key frame. It is necesary to hit the key a few times to get the desired result. - problem with positioning of the subtitles. It is necesary to display subtitles on an overlay surface for the positionig to work at all. But the video playback is choppy in the moment a subtitle is displayed. - during the time a secondary subtitle is visible the main subtitles are ignored Media Player Classic - I have failed to get the subtitles function working, so far.

I was able to get flawless 1280x720 h264 coded video playback on P4 2.4Ghz, without addidional GPU hardware acceleration. However, a few tricks were required to get such a result. In my case the best combination were GOM Player + ffdshow + Haali Media Splitter. Still, the GOM Player does have some problems with mkv subtitle support. The BS Player handles the subtitles much better, but the playback is not flawless.

Well. I'm using the GOM Player in Windows 98. Unfortunatelly, I do not use DVD, so I have no experiences related to this source. But, the GOM Player does have a setting restricting video effects to the video resolution. The effects are used only when the resolution is low, that way. Preferences - Video - Video Effect - Condition setting is never set to "Always enable" with default setup. So if you want to get the video effect benefits in a high quality video it is necesary to set "Always enable" there.

I've changed the firmware to 10.06, but I did not do any network speed testing, so far. Surprisingly, I was able to hold over 100kb/s download rate for a quite long time, yesterday. So far, the download speed was always going down with time. I'm suspecting the new firmware is responsible for improved network card performance. Still, there are other factors to be considered as battery/AC and downloading application type. In any case WGET did a nice job, yesterday.