Sfor

Why I need Adobr Reader 8.1? Because, I have to open some PDF files designed to work in the Adobe Reader 8.1. I was unable to open those files in Adobe Reader 6, Foxit Reader and Sumatra PDF.

Please save the following data as a .REG file and import it to the registry: 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] It will switch off the DDE by removing the DDE registry entries, and the Opera should start with the proper link opened. According to my experiment results, the situation does not have anything to do with the speed of the Opera application.

Another misunderstanding happened. My HTTP and HTTPS registry keys are exactly the same as yours. The registry file I've posted was made to remove the problem. So, it remowes the DDE related keys from the registy. Another problem is, why you do not experience the same effects as I do. Could you explain your testing procedure? As far as I understand the problem, links oppened through Explorer (system shell) are causing the problem. It's quite possible, other system shells or file managers are not affected.

In my case the regisrty key you have posted is the same as yours: REGEDIT4 [HKEY_CLASSES_ROOT\Opera.HTML\shell\open\command] @="\"C:\\PROGRAM FILES\\OPERA\\OPERA.EXE\" \"%1\"" I found the problem to be depandant on a different registry keys: HKEY_CLASSES_ROOT\http\shell\open\command HKEY_CLASSES_ROOT\https\shell\open\command So, you did compared wrong registry keys, I'm afraid.

I've tested the bug with the newest Opera 9.5 beta build 10024. I found the bug still present, so I sent a bug report.

It is possible to move the hdd to the other computer. Windows 98 will just need drivers for the new hardware. No reinstallation is necesary. It possible to copy or move the system to the new hdd, as well. Still, such a transfer can be problematic. Some drivers or software can make it difficult. Yet, basic functions should be working quite well. ------------- Apparently I was not the first to finish the post. The safest routine would be to make a copy of the current system to the new HDD. If something bad happens during the transfer it will be possible to start over from the copy on the old hdd.

The OpenOffice bug tracking system is a bit complicated. So, posting some sort of a voting guide could be a help. 1) If you do not have the OpenOffice.org account, you have to register in order to be able to vote: http://www.openoffice.org/servlets/Join 2) The next step is logging in to the OpenOffice.org. So please go to the http://www.openoffice.org then click "Log in" link at the right top of the page. After entering user name and password the "My start page" opens. 3) Now how to go to our issue page. At the top of the right column there is an "Issue" field. Please enter the issue number there (this particular issue has a number of 89930) then click "Jump to Issue No." button right under the field. 4) The issue screen is opened, now. There is a line described as "Votes for issue 89930:". The current amount of votes is printed there, and there is the "Vote for this issue" link as well. Click the link, please. 5) You are on "Show votes" screen now. It is possible to put just 2 votes on an issue. The maximum amount of votes for multiple issues in the same component is 5. Please scroll down to the porting component (porting is not a component but it is listed as one). Then enter 2 points for the issue 89930. Then click the "Submit" button at the bottom of the list. Your votes should appear on the issue page, now.

Well. Not exactly. I've just updated my knowledge in this matter. I've been using Windows 95 boot disks mostly and I did not pay attention to the differences between Windows 95 and 98. The Windows 95 IO.SYS does not support the JO.SYS, while the Windows 98 IO.SYS calls JO.SYS if available. Also Windows 95 always checks for registry files if the MSDOS.SYS file has some settings in it. Windows 98 acts differently in this matter.

I think I got lost somewhere in this thread. Windows 98 boot DOS files are IO.SYS MSDOS.SYS and COMMAND.COM. I have not heard about JO.SYS, so far. Without IO.SYS there is no Windows 98 boot possible, so there will be no F8 function, for sure. So, what particular OS version are we speaking about?

First of all, the MSDOS.SYS file in DOS 6.22 is a binary file, while in Windows 9x it's just a text file. So, editing of the DOS 6.22 MSDOS.SYS file is not a very good idea. In case of the Windows 9x MSDOS.SYS file there are some other problems related to removable media. The boot menu is always displayed, when there are no certain Windows files on the media and the MSDOS.SYS file does not contain just the ";SYS" line. This option tells IO.SYS to not to look for the windows files, and not to check registry files on boot. Adding any other line with settings will force the registry checks, back again. (Perhaps there is some way to prevent it, but I do not know how to do it).

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.