Messages

1

Programming / Re: LX binary executable header - OS type

« on: August 23, 2019, 01:30:48 pm »

Yeh, I’m sure that they had an automatic license. However, the initial version of the LX spec is from 1993. It included both “Windows” and “Windows 386”. It’s entirely possible that Microsoft wanted the possibility of using LX, without actually using it. It’s also possible that IBM included the only versions of Windows that existed at the time when the spec was written up. I’d love the opportunity to explore the history of it all, but there’s just so little published about the “whys” of these types of decisions for OS/2 technology. Either way, I’ve gotten enough information to accomplish my task.

2

Programming / Re: LX binary executable header - OS type

« on: August 22, 2019, 07:32:49 pm »

So, I think I now have my answer.

3

Programming / Re: LX binary executable header - OS type

« on: August 22, 2019, 07:32:12 pm »

Doesn't 16-bit imply both, and 32-bit only Win 9x?

No, not necessarily. The LX format predates Win 9x. In fact, it's specifically for OS/2. However, it was designed in a way that would allow you to add definitions for later operating systems. At this point, these are the OSes that were defined for the initial version of the spec:

00H - Unknown (any "new-format" OS)
01H - OS/2 (default)
02H - Windows
03H - DOS 4.x
04H - Windows 386

This implies that "02H - Windows" is in reference to either Windows 1.0 or Windows 2.0, as I've now found out that Windows 386 was actually a version of Windows 2.1x. Also, if the LX format had been implemented on Win 9x, I'm sure that other defined values would have been implemented for this field of the LX header.

4

Programming / Re: LX binary executable header - OS type

« on: August 22, 2019, 08:10:57 am »

Unfortunately, neither the LX nor then LE specs clarify specifically which versions of Windows are being referred to for that particular part of the executable headers. Both formats have the same field & use the same values in relation to OS type.

5

Programming / LX binary executable header - OS type

« on: August 22, 2019, 05:10:29 am »

In the LX header, there is a field that's used to specify the OS type. Though OS/2 is the default, there are definitions for Windows & Windows 386. While these definitions were probably not used, the one for Windows doesn't go into detail about which version of Windows it's talking about. Does anyone know whether it's talking about Windows 1, Windows 2, or some early version of Windows 3?

6

General Discussion / Re: OS/2 application developers

« on: December 08, 2017, 11:02:12 pm »

Related to Neils post, it would be nice to have an up to date Posix layer including working full mmap, copy on write etc and better shared library support, no 8.3 limit, the capability of symlinking shared libraries and even versioned symbols. Using ELF would probably supply all this.

Thank you.

7

General Discussion / Re: OS/2 application developers

« on: December 08, 2017, 09:34:38 pm »

To answer the original poster's question, I want 64-bit OS/2 API to permit the implementation of libc and the rest of the netlabs RPM repository that would permit 64-bit compilation of newly ported open-source programs from other 64-bit platforms. Browsers, Office Suites, e-mail clients, image and movie editors all use too much 32-bit resources and need to be extended.

For most of the OS/2 32-bit API, I'd just want it to still work or be accessible through a 64-32 bit translation layer so existing code would recompile more easily.

Fair enough.

This is the type of feedback that I'm looking for!

8

General Discussion / Re: OS/2 application developers

« on: December 08, 2017, 09:33:20 pm »

There must be some sort of a misunderstanding here, OS/2 will not be developed in the future and has not been developed now for more than 20 years.

I've never said otherwise. My question was about OS/2's API potentially being implemented in 64-bit mode -I never said anything about OS/2 itself, nor what would actually run the API.

I was giving a rational alternative for those who want to move forward while still retaining their own software for the time being, rather than take on the mammoth task of emulating the (humongous and outdated) OS/2 API from the outset.

My question had absolutely nothing to do with emulation. In fact, my question was for application programmers, so obviously my attention was on future programs that will need to be written -this does not require emulation. In fact, I never brought up emulation.

And you are contradicting yourself on technical terms, your proposal was emulation, I proposed virtualisation instead, which is a completely different technology.

Your assumptions have caused you to read something into my original post that simply isn't there. If you're not a developer, then you probably have absolutely no idea of what I actually have in mind -and I'm not going to share it. For now, you'll have to just wait and see what (if anything) comes out of any of this.

Going forward, stop jumping to conclusions. It only serves to distract from the actual topic.

9

General Discussion / Re: OS/2 application developers

« on: December 08, 2017, 09:21:55 pm »

Strange idea. Is your plan to take a recent compiler (gcc I guess) and get it to produce 64-bit OS/2 code, you'll also have to create the specifications for? Do you plan after that, only some decades later, to revive an OS from the 80s with a compatibility mode for 32-bit and also for 16-bit applications? Who would be interested in that?

At this point, the plan is immaterial -which is why I've never mentioned what the plan is. I'm here asking application developers what they'd like to see in a potential 64 bit implementation of the OS/2 API. That's all.

The main problem is: Who should do that? What do you have to deal with to gather enough money to hire your divisions of developers?

This is also immaterial.

You are 10 ... 20 years late. But without having the source code from IBM, it makes no sense to start with something like this when OSS possibilities exist.

No, I'm not late. I'm right on time. However, other members of the community could have worked on a replacement for OS/2 long before things got to this point, but they didn't. So, they're late. As for source code from IBM, it's completely unnecessary. There's nothing that can be used from IBM's code that couldn't be better off made from scratch, when it comes to modern hardware. And if OSS possibilities were a solution, there'd already be a fully functional OS/2 replacement by now.

10

General Discussion / Re: OS/2 application developers

« on: December 08, 2017, 05:54:30 pm »

Why?

Microsoft implemented a full software emulation of 32 bit x86 Windows  (WOW64) because they developed the 64bit version on Compaq Alpha servers that had no virtualisation support of any kind and similarly were not x86 compatible in any way. It was not until the AMD64 architecture (Which Intel licences from AMD as well) that they released it and then utilised the x86 hardware emulation available in the AMD64 architecture (they had been using Windows Server Alpha 64 in-house since 2000).

This made perfect sense 20 years ago but today we have AMD64 compatible chips with shedloads of cores, fairly reasonable virtualisation features and memory is cheap to boot. Why not implement a container based mechanism where a real instance of OS/2 lives that can communicate with other containers, and develop a 64 bit OS/2 workalike in another container. This would alleviate the need for developing any sort of OS/2 compatibility or x86 emulation in the beginning allowing developers to focus on the new OS or new shell on top of an existing OS. Already existing open source virtualisation software may actually be up to the task with some modifications.

The plus would also be the possibility of running other OS's in containers and of developing and debugging the system on the same PC using different containers.

Because being satisfied with the virtualization of a platform that's no longer being developed only ensures that the platform continues to NOT be developed. It's time to move forward. It's time for OS/2 environments to exist as first class citizens & run natively on current hardware. It's also time for the pool of programmers that're familiar with the platform to expand. We're not going to get new developers to write software for platforms that they consider to be dead. It's time to breath new life into this community. Otherwise, it dies with it's current users -as they eventually die.

11

General Discussion / Re: OS/2 application developers

« on: December 08, 2017, 04:39:16 pm »

The point is to push the community forward, not to stay mired in the past. And if we MUST go forward (& yes, we MUST), then we might as well do it with an updated API.

12

General Discussion / Re: OS/2 application developers

« on: December 08, 2017, 04:37:16 pm »

We may need 64-bit for a 64-bit browser. That's it. And maybe for a 64-bit compiler for at least one user, to compile such a browser.

That's already covered. Though, in the future, those things will have to be converted to the 64-bit implementation of OS/2's API in order to be native.

If you'd expect that people want to throw away 20+ years of investements, if anything of time, to browse, then they may as well throw away their software now and start using a 64-bit browser for your 64-bit Windows.

Who said anything about throwing away anything?

I don't really care what your private focus is, but then I'd suggest to throw away "the older programs", i.e. everything for 16- and 32-bit OS/2, and start using whatever already existing 64-bit OS with a 64-bit browser software. So it's not the best point of view ever.

Ok, so now YOU want to throw away 20+ years of work? No, that's not the best point of view ever -which is why it's not my point of view.

I don't need nor mind 64-bit APIs, but I'd prefer an inclusive strategy instead of yet another lazy it-works-for-me strategy to reduce the size a small community. If someone likes your approach, then delete all "older programs" you've got now, start using any 64-bit OS, and pretend to be happy while browsing with a 64-bit browser.

Your own assumptions are causing you to argue against something that I've never said nor implied. At this point, your arguing with yourself -which is why you seem to be having a hard time simply answering the question as it was asked.

Regarding 64-bit-APIs, I have no huge files myself, is that it would be nice if it was easier to always support huge files with "older programs", without having to write onesr own LONGLONG-code. Now 2 GiB often is the implied limit, just because it's too hard to support DosOpenL() for a few files of a few users. But we don't have to discuss this here, because "old programs", including but not limited to some older compilers, is not your focus.

Look, at the end of the day, those old programs will NEVER support huge files. Those programs were written based on certain assumptions that were perfectly valid for the OS/2 API of that timeframe. Now, that time has passed. Obviously, support for running those programs is something that's deliverable -albeit in a very limited way. However, this post isn't about programs that were written in the past, it's about programs that will be written for future implementations of the OS/2 API. And that's precisely why I posed the question to APPLICATION PROGRAMMERS. If you are not such a programmer, or if you're someone who has no idea of what goes on behind the APIs, then this post obviously was NOT for you. Your temper tantrums have no place here.

13

General Discussion / Re: OS/2 application developers

« on: December 06, 2017, 02:09:03 pm »

Hi Demetrius

That is a difficult question because a developer will request to have the same experience on a clone implementation, so you will get the "all" answer. Implementing or cloning all is a very difficult task. I would recommend you to stick on the main APIs of OS/2 (CPI, PM). Maybe the first step will be try to replicate the CPI API  maybe trying to reuse some things from the OS2Linux project.

After you got some of the CPI API working it may lead to continue with the rest that it is on top, like PM.

Regards

Most likely, there would be additional changes as the API becomes 64-bit. Sure, compatibility for a lot of older programs may be achievable, but I'm not really focused on the older programs -I'm looking at 64-bit OS/2 the way Microsoft looked at 64-bit Windows.

14

General Discussion / Re: OS/2 application developers

« on: December 06, 2017, 02:04:49 pm »

I know you will not like my answer but you've asked -

If so, what API features would you like to see present if there were a 64-bit implementation of the OS/2 API?

All.

What features would you like to see removed from the OS/2 API?

None.

:-)

Fair enough lol

15

General Discussion / OS/2 application developers

« on: December 06, 2017, 03:23:29 am »

Hello all,

Are there many application developers still active in the OS/2 community? If so, what API features would you like to see present if there were a 64-bit implementation of the OS/2 API? What features would you like to see removed from the OS/2 API?