OS/2, eCS & ArcaOS - Technical > Programming
Closed source parts of eComStation
dbanet:
--- Quote from: Doug Bissett on January 15, 2014, 10:37:30 pm ---Yes, and they are 4 developers who are wasting their time, if the more basic problems are not fixed soon.
--- End quote ---
Ok, that's enough for me. Didn't read more.
Dave Yeo:
As far as I know, the 4 GB barrier is built into X86. We use 32 bit pointers which are limited to 4Gbs and while most CPU's are now capable of using 64 bit pointers the CPU has to be put into a different state where 16 bit code no longer works and OS/2 still has too much 16 bit code to ignore, especially as much of the 16 bit code is device drivers.
All 64 bit capable CPUs also do PAE and as has recently been shown, os2ldr can be rewritten to access that extra 60GBs but it is kinda like bank switching (actually if I understand it, it's back to segments). You can access different 4 GBs banks or segments, great for a ramdisk but not really extending the address space visible to a program. Perhaps it is possible to give different programs their own address space so eg Firefox has access to 4GBs of real ram minus whatever the kernel needs along with what the hardware needs and this would be an improvement. How hard this would be I don't know. I do know that MS gave up on the idea for client versions of Windows as too many device drivers were not happy with it.
As far as I know the swap file is also limited by 32 bit types, probably signed so limited to 2 GBs which means putting the swap file on the ram disk can only help so far.
If someone is really dealing with large bitmaps, video files etc, they really have to move to a 64 bit operating system and purchase more memory
dbanet:
--- Quote from: Dave Yeo on January 15, 2014, 11:38:55 pm ---As far as I know, the 4 GB barrier is built into X86. We use 32 bit pointers which are limited to 4Gbs and while most CPU's are now capable of using 64 bit pointers the CPU has to be put into a different state where 16 bit code no longer works and OS/2 still has too much 16 bit code to ignore, especially as much of the 16 bit code is device drivers.
All 64 bit capable CPUs also do PAE and as has recently been shown, os2ldr can be rewritten to access that extra 60GBs but it is kinda like bank switching (actually if I understand it, it's back to segments). You can access different 4 GBs banks or segments, great for a ramdisk but not really extending the address space visible to a program. Perhaps it is possible to give different programs their own address space so eg Firefox has access to 4GBs of real ram minus whatever the kernel needs along with what the hardware needs and this would be an improvement. How hard this would be I don't know. I do know that MS gave up on the idea for client versions of Windows as too many device drivers were not happy with it.
As far as I know the swap file is also limited by 32 bit types, probably signed so limited to 2 GBs which means putting the swap file on the ram disk can only help so far.
If someone is really dealing with large bitmaps, video files etc, they really have to move to a 64 bit operating system and purchase more memory
--- End quote ---
The whole address space, on OS/2, that you can use with A LOT of processes (programs), is limited to 4 GiB.
So, even if you have the swapping feature enabled and large enough hard disk, you cannot run 500 programs to allocate 500 GiB (one GiB per process).
While on Windows 32-bit, one program still cannot allocate more than 4 GiB, but you can swap on your hard disk and allocate 500 GiB with a lot of processes.
So, the trick is to put the swapfile not on the harddisk, but on the ramdrive, which would be able to map the memory above the 4 GiB limit using PAE without affecting the rest of the system.
So, that is the limit I am talking about. It could be overcomed by reimplementing the memory management subsystem in the OS/2 kernel.
By the way, the hd4disk.add driver, which actually jumps into PAE and provides the ramdrive (not the loader or, especially, QSINIT), works pretty fast (with the words of the developer) -- you can test it by yourself, or ask me to measure the r/w speed and report the results.
Martin Iturbide:
--- Quote from: Doug Bissett on January 15, 2014, 10:37:30 pm ---
More important, are things like support for the majority of NICs that exist today, and in the future. Without communication (especially wireless), nobody will be able to continue using eCS. It just won't do the job. It can't always do the job today, without wireless communications. There are keyboard problems, there are video problems, there are printer problems. Somebody had better start fixing all of them, or eCS will be as dead as IBM, and Microsoft, wishes it was.
--- End quote ---
Doug, let's do something about it.
Do you know any NICs developer we can hire, or can set a quote to create a Wireless open source driver? on which drivers should we start? Can you talk to him and try to set a fund, bounty, whatever to help out?
Doug Bissett:
--- Quote ---Doug, let's do something about it.
Do you know any NICs developer we can hire, or can set a quote to create a Wireless open source driver? on which drivers should we start? Can you talk to him and try to set a fund, bounty, whatever to help out?
--- End quote ---
I would love to have the time to mess with that. Do you know any place where I can get some 48 hour days? :(
The only qualified programmers, that I know about, are all working overtime, trying to get eCS 2.2 out the door, or get Firefox updated. There are probably many others who could do the job, if they were interested.
I have heard that it is not all that difficult to find an appropriate Linux driver, and plug it into the template that Mensys has provided. I started to look into doing it (wired NICs) myself, more than once, but never had the time to follow up (I do work on other projects, I do have a life, and I already don't get enough sleep without taking on more projects).
David A. is apparently scheduled to start on Intel wireless NICs, once eCS 2.2 is finished. He will probably follow that with Realtek wireless NICs (although he may not be interested after his bad experiences with Realtek wired NICs). After that, it is likely to be up to the users to provide drivers for the rest of the hardware that is out there. Somebody, with a little knowledge of software, and hardware, could make a nice hobby of making the drivers, once they figure out how to do it (apparently documented, in some detail). Of course, we can't expect anyone to run out and buy all of the possible devices (which is likely not possible anyway), so others need to provide testing, and semi-intelligent feedback, when something works, or doesn't work.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version