Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Boris

Pages: 1 ... 19 20 [21]
Programming / Re: Closed source parts of eComStation
« on: January 15, 2014, 07:18:39 pm »
I've tried to be as polite, as I could, and, I hope, the argument is settled.

Programming / Re: Closed source parts of eComStation
« on: January 15, 2014, 07:10:48 pm »
The ball is in your court...
I won't argue anymore, but I'm gonna fix some mistakes.

Well, I think you are being  bit optimistic. We don't even have enough developers to get a Wireless NIC working (although that seems to be on the short list).
Four developers work on OS/4 kernel for years. Although removing the limit may cost some, because it is a lot of work, it can be accomplished.

Btw im writing this on a computer with 512 MB RAM
Me too. Although, that's how much memory in my laptop is installed right now, I'm gonna upgrade to 2 GiB (the maximum).

Very recently, the QSINIT project has demonstrated that using memory above the 32 bit addressing limit is possible. That is currently restricted to using it as a RAMDISK, but it has been demonstrated that it does work. More serious work is required to be able to use that memory more productively, and it is likely that programs would need to be modified to use it. Note that this is NOT the ideal solution, but, at the moment, it is the ONLY game in town.
It was obvious that using memory above the 32 bit addressing limit is possible, because you can use more than 4 GiB of memory on Windows 32-bit using ramdrive with PAE support by placing the swapfile on it.

Then, the first thing to do was to write a PAE supporting ramdrive, the hd4disk.add driver (which is acutally a standalone project, and it can be used without the Tetris bootloader).

Then, finally, to overcome the 4 GiB limit in the memory manager.

That is a very small cost comparing to rewriting the whole system on 64-bit, or comparing to implementing PAE directly in the memmanager, which would affect the drivers.

More limiting is the 500 meg memory space for each program (which includes shared memory space).
What limit?

Anyway, the memory management subsystem should be rewritten, and removing the 4 GiB barrier should be one of this task's subtargets.

Programming / Re: Closed source parts of eComStation
« on: January 14, 2014, 10:19:03 pm »

no reason to get angry. I don't talk about tactic. We have very small capacities of developers. So I'm talking about priorities.

To say os2 don't needs above 4GB RAM is no tactic - it is a fact. Because we don't have applications that use such an amount of RAM. Maybe it can be a problem in future. But today there are loads of things more important and that drops me back to high priorities.

And when you talk about running loads of virtual machines with more RAM: its a bad tactic to design a system, to perfectly run other systems - while the own identity is going down (and btw other systems do the visualization even better right now). So at first priority you need unique software and special use cases. If you want to sell a OS like eCS for 270 bucks  you need a unique reason. Something special. One of the good points of eCS or OS/2 is that it runs very smooth one small hardware. Its a very powerful system with very small system requirements.

So when we talk about "fundamental barriers" the first point should be to find a reason why to use this system and not another one.
Then the price is a "fundamental barrier" for new users. Then we come to installation and communication. E.g. it should be no problem to share data with USB sticks. It should be no need to fire up dfsee to make an USB stick running (if youre lucky enough). ACPI and basic drivers. And then we come to lack of standard software, which is a real fundamental barrier. We don't have real working video player nor a full featured bitmap editor nor a really good and stable office suite. To use your words: "ffs" Mensys doesn't even have reference system.

And, and, and ... and then after maybe we really need more than 4 GB.

Atm eCS lives because some people have been arranged with the situation, using old software and workarounds, or use the system in a very basic way.

When you talk about bitmap and video manipulation - stop me if I'm wrong but we don't have these applications  for OS2. I would be fine when I'm wrong. We don't even have decent working version of gimp. 4 GB limit might be a small part of the whole problem. When we get 100 GB RAM we don't solve this situation.

Stop for a minute. And follow the thread.
As to reimplementing the OS2KRNL. WHat features would you like to have of the kernel ?

Then me, talking about the 4 GiB limit. So, that's not offtopic. For example, talking about GIMP in the what-do-you-need-in-os2-kernel thread, would be offtopic.

While we have enough developers to solve the 4 GiB problem, we need to do this.

Because you can edit bitmaps in a virtual machine on OS/2, but you can't use virtual machine to allocate more than 4 GiB memory.
You can now transfer data from USB sticks, but you can't use more than 4 GiB of address space.
That's what I call a fundamental barrier.

You can rearrange priorities, and more, fixing a fundamental problem may have a lower priority than fixing the USB widget to write DLAT *: at a usb stick connect, but, sooner or later, you will end up with not enough virtual memory and perfectly working USB sticks, and no way to fix that, because there'll be no developers that are able to rewrite memory management.

Programming / Re: OS/4 ? QSINIT ?
« on: January 14, 2014, 10:07:13 pm »
What you need to do, is contract with Mensys, to include QSINIT (perhaps just a subset to load the OS/2 kernel), for all of their customers (including business customers), and pay you a small royalty for each one sold. They would probably put it on their store too, for those who need it for other purposes (like a RAMDISK, use with older versions of OS/2, or to play Tetris   ;)  ). I know that other programs have been done that way, and some closed source has been turned over to Mensys, to be released under certain conditions (like the death of the author, or if Mensys quits doing eCS). It is all in the contract that you make with Mensys. Another option would be to just sell the source to Mensys, and make a contract to maintain the source as part of the deal. There are many options, and most of them will work to your advantage, but trying to restrict what it can be used for, is really not a good idea. I would suggest that doing any of this will not make you rich, but it would probably cover your costs, plus a bit.

W-w-w-wait a minute.
Do you mean then I will be unable to get QSINIT for free?

Then, if I find a bug, who then should I contact with bugreport? Mensys?

I think that is unacceptable, and the current situation with QSINIT is way better.
The loader is regulary updated, the author is easily available for contact with bugreports or wishes.

Also consider that I can use the Tetris bootloader even with Warp 3, and I don't need to buy eComStation to use the bootloader. I don't really want to mess with Mensys this way.

OS/4 kernel does not support the TRACE and TRACEBUF statements. It displays that these statements are not valid and continues to boot (the same holds true for VIRTUALADDRESSLIMIT but I guess that was intentional).
This is even true with the OS/4 debug as well as retail kernels.
This is a serious limitation because for example it's the only way for David's / my USB drivers to log operational info on a user's end machine. Without any tracing, it's impossible to determine why a driver won't work on a user's machine (except for flat HW traps which can be located by other means).
Again, this renders the OS/4 kernel incompatible with the existing OS/2 kernels.


STRACE support is discontinued in Phoenix kernel.

Programming / Re: OS/4 kernel - my first impressions
« on: January 14, 2014, 09:32:10 pm »
1) When I use the debug kernel, I always use ICAT via UDP (I don't have the need to debug INIT or INIT_COMPLETE). Unfortunately my host machine does not have a serial interface (only the MUT does). I am thinking about buying a USB to serial converter cable.

I already replied in the other thread about strace. Better would be a com card as nobody can be sure that the usb serial adapter will work, esp in boot stage 1 & 2.

I think the test machine does have the com port, but Lars is unable to get the log, because his main machine does not have the com port, so buying a usbserial adapter will help.

Programming / OS/4 kernel -- my own impressions
« on: January 14, 2014, 05:02:37 pm »
OS/4 kernel runs on my Intel Xeon server with two CPUs with OS4APIC.PSD /APIC driver very well.
Also it runs here on my laptop.

I also have an another non-SMP system running ACP2 and native non-SMP kernel -- I don't think I need to migrate to OS/4 or the latest kernel from Mensys, because both are SMP kernels.

Also I run the kernel from Mensys on my main SMP desktop, because I don't really need to migrate to OS/4 there, and I am too lazy to do it.

The primary goal of OS/4 kernel is to make OS/2 run on PCs that it does not run with the native kernel.
Actually you can get support from the Phoenix team and report bugs that are likely to be corrected, while no one develops the native kernel now.

The OS/4 kernel is rewritten in a lot of places, and its modernized source code is a good start to finally resolve the most well-known OS/2 issues.

Programming / Re: Closed source parts of eComStation
« on: January 14, 2014, 04:45:28 pm »
We as eCS-users don't even have the possibility to use tools like dos-extenders to utilize all the available memory on our hardware.

Actually we do have the possibility.
The PAE ramdrive acts just like a dos-extender.
The hd4disk.add driver first turns off normal paging, then sets PAE paging, reads/writes from the upper memory, then turns off PAE and restores the normal paging.

For example, you can use the latest Windows XP 32-bit with no PAE support to access all the memory by putting the swapper file on a ramdrive, that supports PAE. And that really do work.

While on OS/2 it won't work, because of very poor memory manager.

Programming / Re: Closed source parts of eComStation
« on: January 14, 2014, 04:39:51 pm »
Could you please name one OS/2 application or one use case where we need more than 4 GB RAM?
I run virtual machines and console java applications on a server with two CPUs and 4 GiB of RAM running OS/2.
Firefox could easily take more than 4 GiB of RAM (if not the crashes).
I would like to run virtual machines on my main PC (eComStation 2.1) and don't look on the memory indicator.

Of course it would be nice to have but there is no priority for this from a point of a user. I understand that people buying windows machines and then wonder if they eCS work on it. But for me as an real user (I'm working 8h each day with eCS) there are about 100 things more important than >4GB RAM. As the fairy said: don't waste wishes if you have only three. ;)
As far as you can see, I am a real OS/2 user. There are about four machines at my home that run OS/2. I am writing you from my laptop that runs eCS 2.1. I think I use OS/2 for about six (or more on weekand/holidays) hours per day.
I have participated in OS/4 kernel testing with success.
Also I've ported two small Qt utilities to OS/2.

For the *ucks sake, the "OS/2 does not need that" tactic IS A BAD TACTIC.
That's why we don't have skype, for example.

4 GiB per all processes is a fundamental barrier not because it is the most annoying defect, (maybe you need to reread me, huh?) it's because in 2020 you can write another video or audio driver, port another videoplayer or write USB 5.0 host controller driver, but the 4 GiB limitation still remains, and that's the limtation that prevents OS/2 from running on current, big servers. Symmetric multiprocessing support is good enough. Multitasking is good enough too. But nobody will even think to run OS/2 on a server with 64 GiB of RAM.

Don't wait 'til the 4 GiB limit will be the most annoying one, because it needs a lot of work, and we need to start as soon as possible.
If we are rewriting the memory manager, it will be too silly not to remove the 4 GiB/all processes limit.

Programming / Re: Closed source parts of eComStation
« on: January 14, 2014, 02:14:30 am »
As to reimplementing the OS2KRNL. WHat features would you like to have of the kernel ?


For sure, the very huge and very important part that really needs to be reimplemented is the stuff that do memory management.
Memmanagement is known to be very poor (two arenas, continous troubles with shrmem) on OS/2. Also the 4 GiB for all the processes limit surely should be overcamed.
With the latest development of Phoenix team -- PAE ramdrive, you can use up to 64 GiB of memory on OS/2 (with any kernel, any version of OS/2 from Warp 3 to eCS *nextVersion), but even with swapfile placed on the ramdrive, the limit of 4 GiB/all processes still remains.

This will not remove the limit of 4 GiB per ONE process, but for sure will be a great move forward for OS/2, because you, of course, can just "write another videodriver", but the 4 GiB of RAM limitation for all the system is now a fundamental barrier, which SHOULD be overcamed as soon as possible.

Another big trouble, a bottleneck of Operating System/2, is the graphics subsystem and some parts of WPS.
While the most annoying defect of WPS -- instability -- really needs attention, the Presentation Manager and the graphics subsystem itself inhibits the development of eComStation very much.

PM and the graphics subsystem is a huge bunch of code, and its reverse-engineering and (preferably) opensourcing should became the next long-term goal of the whole eComStation community in general and Mensys in particular.
While WPS improvement (making it usable as a light filemanager -- copy/move dialog replacement, file open container (opensource it!), etc) may be performed relatively easy, in view of XWP, which is a very good start (or even the half of a distance), PM and the graphics subsystem need a lot more work, and should became the primary target.
Its defects are: inability of on-the-fly resolution change, no support of multidisplay configurations (one stretched desktop (!) on many monitors with different resolutions (!!) connected to a number (!!!) of different (!!!!) videocards ran by different videodrivers (!!!!!) -- this is fully possible on Microsoft Windows and impossible on OS/2), and no support of transparency (=>non-square windows, shadows).
Consider, that Windows, GNU/Linux, Mac OS X do support all these features.

Also, if I started to whine here, I am also gonna note a few problems, no one of which are also encountered on other OSes, and which are easy to fix.

First. USBCOM driver. It just is not suitable for anything. USBCOM devices should be plug and playable (no need to preconfigure the amount of usbcom devices in the config.sys), three or five more chips support should be added.
Ubuntu 12 supports USBCOM hardware very well -- I've tryied three devices which didn't work with OS/2, on Ubuntu -- worked well out-of-the-box, no additional drivers needed.
The problem may be easily fixed (look at the usbserial module sources of the linux kernel).
There is no attention paid to this problem.

Second. USBMSD with SCSI-Transparent command set support should be implemented. Chris Wohlgemut once did this, but his driver does not work for my device, the driver's source code is not opensourced.
Windows XP with no service packs support these hardware w/o any additional drivers needed, out-of-the-box.
The problem may be easily fixed (look at the usbmsd module sources of the linux kernel).
There is no attention paid to this problem.

I suppose, that's all :)

Pages: 1 ... 19 20 [21]