Jump to content

Windows 98SE create Unicode Libraries for XP-compatibility in programs


wizardofwindows

Recommended Posts

:yes: The future of modding Windows 98SE looks rather good, with people currently attempting to create Unicode Libraries for XP-compatibility in programs. Theres alot of people dreaming of this ,the abitity to run made for xp only programs that soon could run on 98se .Why because alot of folks like 9x simpicity no activation etc etc but are forced to upgrade simple because a new app like eg.msn7.5 doesnt work on 98se or cant find drivers etc. The 9x forum has seen great strides in making this possible tinhy attempted this is his last offering of RP4 but still experimental but theres others approaching this aswell what a boon for 98se users if someone suceeds but im sure alot of people just like 98se and are pi**ed off that they cant run new apps.I no what your saying buy xp go with 2000 get with the times .your partly right but why are we forced to do this every 2 or 3 years when we pay for our os and must pay again.In closing maybe this thread will spark some interest in such a project and feel free to post ideas solutions etc on making this a reality in whatever small way.Thx u may the force be with you... Edited by timeless
Link to comment
Share on other sites


miko,

That's a dll that developers need to refer to and to include in their installation package to make their software w98 compatible.

It's not an upgrade for w98 to be XP-only-software compliant.

(as I understand it)

All you need to do is compile your application as a Unicode component and include the unicows.lib file with the other libraries you use
Link to comment
Share on other sites

  • 3 weeks later...

It's trange we don't hear more about that topic here.

But the task of making w98 compatible with XP-only apps is immense:

1/ you will have to prevent installers from detecting w98. most installers would abort if they know you are using w98.

But this alone should allow (IMO) 75% of so-called XP-onlie's to run on w98.

2/ add .NET framework and the likes

3/ add libraries or replace them by thos used in XP. that may cause w98 versions not to run and app not able to run on XP won't run neither.

The best would be to add libraries without deleting the old ones or if impossible creating recompiled libraries but that's nearly impossible without the source.

4/ transplant all the files that can be possibly used by the app, maybe by testing and reading error message like "xyz.dll is missing".

Link to comment
Share on other sites

It's trange we don't hear more about that topic here.

But the task of making w98 compatible with XP-only apps is immense:

1/ you will have to prevent installers from detecting w98. most installers would abort if they know you are using w98.

But this alone should allow (IMO) 75% of so-called XP-onlie's to run on w98.

2/ add .NET framework and the likes

3/ add libraries or replace them by thos used in XP. that may cause w98 versions not to run and app not able to run on XP won't run neither.

The best would be to add libraries without deleting the old ones or if impossible creating recompiled libraries but that's nearly impossible without the source.

4/ transplant all the files that can be possibly used by the app, maybe by testing and reading error message like "xyz.dll is missing".

Bringing the terrifying amount of bloatware that litter a standard installation of XP, onto almost any other system does indeed appear to be a daunting task. The question is whether you'd have to, or perhaps more importantly, *want* to.

I think it would be far more desirable to find methods to accurately identify the essentials or "show stoppers" that keep XP-only apps from functioning adequately on alternative Win32 implementations. Tools that intercept operating system calls applications make seem to be the most plausible approach to that.

Once such information is available, a reasonable next step might be special program loaders (or patching existing ones) that implement, emulate, fake, etc. the expected XP interfaces.

Some of those concepts are demonstrated by the Linux DOSEMU and WINE environments, and by the *BSD emulation of Linux system calls. Also, the latter is an excellent example of how shared libraries (DLLs) of one operating system can be kept from interferring with native ones: when Linux apps ask for a particular file, FreeBSD first looks for it under the /usr/compat/linux directory tree, and only if that fails, the file is looked for in the regular tree.

Link to comment
Share on other sites

:no: no reply in there perhaps theres someone out there with a plan.

I don't have the full story, but some interesting hints regarding the file system:

Long filenames, whether on NT/2K/XP or 95/98/Me, are stored in 16-bit Unicode format. The IFSMGR VxD (kernel module) that implements 32-bit file access knows how to read them and how to convert them as needed to the format expected by DOS and Windows applications. Implementing APIs that omit the conversions ought to be easy enough. In fact, I plan to experiment with that from a DOS and or VxD point-of-view. The Win16/32 APIs are currently beyond me, I'm afraid.

Also, while the VMM (the true kernel), which implements registry access uses a regular character set for the purpose, it should be easy enough to implement hooks that provide Unicode to applications asking for it, and converting on the fly to the normal character set - perhaps URL %xx encoding might be useful or possibly UTF-8.

Edited by somewan
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...