Sfor

Yes, I've tested it. The OpenOffice 3 beta does not work in windows 98. I was unable to install it even with the KernelEx installed. There is still a chance to convince the OpenOffice development team, the decision to leave Windows 98/ME behind is not the right one. The feture request are made through the bug tracking system. Each registered member can vote for some issues. With a proper amount of votes we have a chance to defend our platform. I've submitted an isue, already: http://qa.openoffice.org/issues/show_bug.cgi?id=89930 Plese register at the OpenOffice.org bug tracking system at http://www.openoffice.org/servlets/Join, then vote on this issue.

All OpenOffice 2 versions are working in Windows 98. Windows 95 lets to run just the OpenOffice 1. The OpenOffice 3 is in the beta stage. I found nothing particular about changes in support for Windows systems, so far.

I was unable to find any confirmation of the fact the OO 3 does not supports Windows 98. On the other hand some download centers are telling it supports Windows 95 as well.???

My mistake was the installation of the KernelEx 0.3.3a. After installing 0.3.3e the AR installer works much better. The first window with a progress bar now shows much more informations. The missing part in the KernelEx 0.3.3a is the unicode translation, and not blocked platform check calls. But, another problem emerged. The AR installer downloads a Microsoft Installer 3 package and tries to update the system. The result of running the downloaded package is stopping of the installation procedure without any message. When I'm trying to run the downloaded WindowsInstaller-KB893803-v2-x86.exe file it just says there is an export routine missing NTDLL.DLL:NtOpenProcessToken. ------------------------------------------- I've removed the MSI update entry URL in the setup.ini file. The instaler does not download the MSI update any more. It displays "MSI version 3.0 is required, but update is not available", instead. So, I've removed the "RequireMSI=3.0" line from the setup.ini file. Now, the installation ends with a dialog saying there is no access to the windows installer. So, I've stuck on the MSI 3.0 service requirement.

The newest Polish goverment electronical tax declaration service requires Adobe Reader 8.1 to be used. I'm trying to explore the possibility of running it on the Windows 98 comuters. Has anyome run the Adobe Reader 8.1 with KernelEx? ----------------- I have installed the KernelEx. Now, I'm trying to install the Acrobat Reader 8.1.2. I was able to trick the installer with the KEXVER.INI setting. The installer runs, but there are nothing except for the progress bar in the window titled NOSSO® 1.0. Then a dialog is displayed: Luckily I've found the installation files extracted in the temporary folder. There is a AcroRead.msi file in it. I'll try to get around the problem, somehow. Oh, closing the error message dialog will delete the installation files, instantly. So, it is necesary to make a copy of them before terminating the installation. ---------------------------------------- The most funny thing is, I have a 6.0.2800.1106 IE version istalled. When I'm trying to run the AcroRead.msi file directly, it says I do not have a proper installer version in my system.

It would be good to confirm the problem first, I believe. I hope the problem is not Windows language version related.

I found Opera to be a very good internet browser. Still, there is a problem related with opening links using DDE with both Opera 9.2x and the newest 9.5x betas. While trying to open Opera through running .URL file or clicking on an Internet link in a third party application, Opera displays an error message saying "it can not locate the file or it's component" (translation from Polish), then the browser is starting without the clicked link oppened. If the Opera is running, the same action works as it should to. I found, the problem can be corrected through removing DDE from the file associations created by Opera: REGEDIT4 [HKEY_CLASSES_ROOT\http\shell\open\command] @="\"C:\\PROGRAM FILES\\OPERA\\OPERA.EXE\" \"%1\"" [-HKEY_CLASSES_ROOT\http\shell\open\ddeexec] [HKEY_CLASSES_ROOT\https\shell\open\command] @="\"C:\\PROGRAM FILES\\OPERA\\OPERA.EXE\" \"%1\"" [-HKEY_CLASSES_ROOT\https\shell\open\ddeexec] Still, the Opera will renew the bad registry settings every time it is selected as the default browser.

Well, dirtribution and translation to other languages is the last step indeed. It is not necesary to make any first step in the development, I believe.

I do believe the files to be checked should come from the database. As, it is not possible to be sure, what type of files it will be necesary to check. So, it will be the best to check according to the database entries. The database should contain more informations, as well. A quite important property is if the file should be localized for different language versions. Different database entries would be necesary for different language versions, in such a case.

Cannot say if it applies to your case, but FYI: http://www.boot-land.net/forums/?showtopic=2681&st=24 Tested on 2K/XP, but should work with DOS/9x/ME as well. jaclaz It can not work correctly in DOS and Windows 9x. The reason is the "if not exist echoo.com (...)" and "GOTO :EOF" statements are not supported there. Still, the main code seems to be correct, as the unsupported parts are just to protect from script calls without a file name argument. With a few correction it should work in all systems. @ECHO OFF if "%1"=="" GOTO END if exist echoo.com GOTO ESKIP echo Bj@jzh`0X-`/PPPPPPa(DE(DM(DO(Dh(Ls(Lu(LX(LeZRR]EEEUYRX2Dx=>echoo.com echo 0DxFP,0Xx.t0P,=XtGsB4o@$?PIyU WwX0GwUY Wv;ovBX2Gv0ExGIuht6>>echoo.com echo ?@xAyJHmH@=a?}VjuN?_LEkS?`w`s_{OCIvJDGEHtc{OCIKGMgELCI?GGg>>echoo.com echo EL?s?WL`LRBcx=k_K?AxVD?fCo?Cd?BLDs0>>echoo.com :ESKIP echoo.com $00>tempbin.$$$ copy /b %1 + tempbin.$$$ %1 del echoo.com del tempbin.$$$ PAUSE :END Also it is not possible to drag anything to .CMD in windows 9x, of course. The file has to be a .BAT in order to work in DOS or Windows 9x.

It depends on the purpose of the reverse engineering. - If a decompiled code is put in some other application, it is a theft. - If the decompilation is used to find and remove bugs, it is not a theft. I'm not good enough in english language to dig in the law related matters. Still, an action can both legal and not legal, depending on the purpose the action was taken for.

In other words, something like the Microsoft Windows Update system.

I readed the licence agreement the Polish Windows 98 displayed during install procedure. There was a clausule at the end of the text referring to the Polish law act. The conclusion is, it is legal to do reverse engineering, if it is necesary to find and remove bugs in the software. It is possible, other language versions of the licence agreement are very different from the Polish one.

A note: DOS needs to have the access to the command.com file. If the boot drive letter is to be lost, it is necesary to move the command.com to other drive and to notify DOS about it with COMSPEC enviroment variable.

Well. Open source can give results in a very long run, only. Since the amount of 98 users is going down, it should be more logical to focus on a more usable goal, I believe. Still, there is some room for open source, here. An open source installer, or package manager is a logical choice. As, every developer or update creator could be able to use the same software for package management. It can improve the ability to create and manage multiple language versions, as well. Still it is not necesary to create a new installer from the beginning. It should be enough to use some existing open source project. It will be possible to add some improvements or changes to the installer engine that way.

Looks like the atmosphere is getting more tense. I'll try to add my point of viev. There are a lot of patches and improvements available. Unluckily not many of them are ment for the Polish language Windows 98. I'm not much interested in further improvement of the system at the moment. I would like to get some benefits from the current solutions in my own language, first. Theare are a few improvements packs available. None of them comes in a Polish language version (exception for the old USP 2.1b). So, they are useless to me. My support comes towards translation. A good point is, the improvements are comming from many sources and we do not have to make our own, because of the fact they are available, already. Yet, the programmers are unable to take care of the translation and multi language support, because a community is needed for that. So, I do believe, a community should focus on the task a community could not be replaced in. In my opinion the best improvement pack will be the one with the best multi language support. It is not necesary to make a new package. An old one with more languages will be just right.

This is not correct. Two examples: 1) Linux: USB stack is loaded using first BIOS USB with initrd/kernel (less than 5MB). Then the USB stack uses protected-mode USB 2.0 to exploit the hardware in high USB 2.0 speed. 2) XP/Vista: as with Linux, but without RAM disk in normal booting. This explains also slow boot on some machines with BIOS USB 1.x booting (although with USB2.0-hardware capable). Then afterwards the loaded OS will exploit the USB2.0 through drivers. We are speaking about Windows 98, here. The boot drive letter will not be accessible after protected mode USB driver start. Also, Windows 98 will not let to use the same drive letter for the USB device as the boot drive has, as the boot drive is DOS compatible mode driven. The finall result is hang during boot, in any case.

As a matter of fact I did install Windows 95 by running the installer from a FreeDos boot disk.

When you are booting from an USB drive, you are limited to what the BIOS is providing. A driver change will not make any difference, I'm afraid.

http://www.msfn.org/board/Enable48BitLBA-B...ier-t78592.html Also, there was a thread with the test of a Windows 98 installation on a 500GB partition, somewhere. It worked surprisingly well (with exception of the automaticaly sized swap file), as far as I remember.

SlugFiller. What makes you sure the installed SATA driver does not use standard ESDI driver file. The simplest implementation of a compatible IDE driver is to switch SATA controller to IDE compatibility mode, and to use windows generic driver. There were numerous posts about Windows 98 working very well with partitions larger than 137GB.

It is not possible to do. In order to boot from USB device a BIOS or DOS support is necesary. Also, it is not possible to use Windows driver and DOS or BIOS in the same time. So, in the moment Windows start's it's USB driver the boot drive stops responding. The conclusion is: Windows has to have USB support disabled, in order to be able to boot from an USB drive. Or, it will be necesary to make a ram drive and to boot the Windows from it.

Well, acces rights, user controll. This is a "military base" language designed for a war with the world. On the other hand Windows 9x is a "home like" system. We do not like to enter passwords in order for being able to change something in our homes, or do we? That's why the minimal internal security system is so pleasant to live with. If the communication software used in Windows 9x will be safe enough, the system will have good enough safety for most. So, changing the security system means to leave the "heart" of the design and to move from a household to a military base. As for the whole opensourcing idea. Replacement of the most bugged components is the most logical point of action. The OpenOffice project has a quite interesting bug tracking system. It's quite unpleasant to use, but it has a possibility to vote on bugs. It is possible to determine what users whant to change, that way. Such a system could be quite a nice start for a project aimed in improvement of an existing OS. My pockets are empty at the moment, but these few cents can be of some use, I hope.

Unfortunatelly, the application I mentioned starts Dial-Up connections by itself. So, making a connection from a batch will not work in this particular case. Because, the user would have to do it, instead of the application.

The Windows 98 boot cd does incluge a bootable DOS FDD image it boots from. Unluckily the CD-ROM drivers present on the image do not support all available CD drives. In some cases vendor specific DOS driver is necesary. So, there is no "discover" system in the Windows boot CD, as the Linux has. As a matter of fact there is no plug and play support, as well.