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 ... 18 19 [20] 21
Paul, the DLL was not fixed by the Phoenix project, that's just a DLL from one of the binary uniaud distributions, and actually I don't know from which one is it. I have to do further testing and figure out what releases posted on netlabs' Trac are broken, but the DLL in the latest release is reported to work just okay with OS/4, although I didn't test it myself.

The old broken DLL may still remain on some users' systems, for example, due to not updating uniaud on time, or due to other reasons, so updating uniaud manually may be a good thought.

Well, after a bit more testing, I found that using os4krnlr boots okay, but trying to use UNIMIX.EXE causes a strange problem. It works, as expected, with the base eCS 2.2 beta II install (IBM kernel). If I try it with os4krnlr, UNIMIX.EXE responds with "SYS0193: UNIAUD cannot be run in a OS/2 session." (yes, it does say "UNIAUD"). I am not sure what that is all about, but something is wrong.

I've (accidentally) reproduced this problem on my machine and I had to report it to OS/4 kernel developers. Fortunately, the problem entirely resides in the uniaud.dll: the bug in it was being compensated by the bug in the original kernel causing uniaud.dll to work without any problems. When the bug in the kernel was fixed by Phoenix people, uniaud.dll stopped to work properly on the OS/4 kernel.

You are welcome to download another version of uniaud.dll, which does not contain the bug in it and which works fine with the OS/4 kernel, as well as with the original one. Replace the existing one, which resides in the \MMOS2\DLL directory, with the downloaded one. To accomplish this, you may (or may not) need the UNLOCK.EXE utility from lxLite, the opensource utility package, to unlock and replace the DLL if it was locked by uniaud or someone else. After that, reboot your system.

I gave OS/4 a try on my Lenovo ThinkPad L530. It has a 2 core I5 Intel processor, with 4 GB of memory, and UEFI BIOS.

If I try to use the os4krnl file, it always hangs hard (the mouse won't even move) when the blue screen first appears. The next thing that I expect to see, is the STARTUP.CMD window. The only way out is to hold the power switch for 5 seconds.

If I try using the os4krnlr file, it seems to boot okay, but I haven't tried everything yet.

The good news is that it gives me 3170 MB, where the IBM kernel gives me 512 MB.

I find the documentation to be somewhat confusing, and the OS2LDR.INI file is not all that helpful, but experimenting with it doesn't seem to do any damage.   :-\

os2krnl is the debug version, and os2krnlr is the release version. When the debug version hangs, try hitting Control-Alt-Shift-Scroll Lock-Scroll Lock, then if it prompts you to insert a diskette, then it is possible that it just falls into kernel debugger over a COM port (that looks like a hang) because of some not very important thing failing. The release version does not do that because lacks the kernel debugger feature. Also that may be just a bug in the non-release version. The thing is the release version of the kernel is not the master one, so it may lack some features and/or bugfixes, and/or, bugs.

Anyway, to avoid the debug version from falling into KDB, you may try writing this:
Code: [Select]
.b 115200t
into \KDB.INI file on your boot drive. That helped me once.

It seems that your laptop does not have a hardware COM port, so I'm not actually sure how can one get a log if there is no COM port in a PC, and that is impossible to insert one.

So far ------Soooo Good! and many, many thanks for you're efforts Boris!

Hi klipp,

I'm not a member of the OS/4 kernel development team, and I don't unfortunately have sufficient skills to participate in kernel development. I use and test the kernel on my OS/2 machines. You are welcome to the #os2russian channel to thank the OS/4 developers directly, and participate in testing.

The reason I take part in discussion here at os2world forums, is that I find a significant part of OS/2 community being not enough informed about the progress of the Phoenix project.


I was wondering if this kernel can make use of Hyperthreading? Also, what does the new screen03.sys driver add? It would be good

Yes, it can. For better performance turn on the ExtraKernelHlt key in the ACPID.CFG file.

Programming / USBMSD
« on: February 01, 2014, 02:20:18 pm »
USB drivers

So, did you see my email about usbmsd?

Programming / New OS/4 kernel :: SVN4227
« on: January 31, 2014, 01:09:50 pm »
Hi OS/2World,

The Phoenix project proudly presents the new release of the OS/4 kernel that just has been made available at site.
Whatsnew list includes the new SCREEN03.SYS and SDDHELP.SYS drivers, bugfixes, enhancements and new features.

Due to the technical problems that will be fixed ASAP the new kernel releases are not available on Russian Underground/2 server.

They are posted at server in the /os4 directory. For example, the current latest release, SVN4227, is available here as a zip file.

I will also update this topic for every new release to keep the OS/2World community up to date with the Phoenix project.

To help new OS/4 users, I've created a page on OS/2World Wiki, which consists of
Even if you are an experienced user (OS/2, or both OS/2 and OS/4), you are recommended to read it anyway, because there are lots of changes in the recent releases.
Also help on the page, especially if you are a native English speaker, is needed and appreciated.

20 Feb 2014.
SVN4168 released.
Don't know about changes in this release.

QSINIT loader full source code has just been made available -->

06 Mar 2014.
SVN4169 released.
Whatsnew list from 4166 to 4169 is as follows:
  • Interrupt router enhancements.
  • Some bugs fixed, thanks to [joseph] for testing.

10 Mar 2014.
SVN4171 released.
  • A bug in recent OS/4 versions was fixed, that caused VirtualPC/2 to crash on start with OS4APIC.PSD driver loaded.
  • A bug related to DLL loading was fixed.

12 Mar 2014.
SVN4172 released.
  • Another bug in the system init was fixed.

25 Mar 2014.
SVN4173 released.
  • More diagnostics of PSD driver loading added.

19 Apr 2014.
SVN4177 released.
  • The boot process now stops if the kernel is unable to load CLOCK03B.SYS or SCREEN03.SYS.

26 Apr 2014.
SVN4180 released.

03 May 2014.
SVN4182 released.
  • Just a build with more information outputted for testing purposes.

04 May 2014.
SVN4183 released.
  • Small optimization and reorganization changes.

23 May 2014.
SVN4188 released.
  • More parts (device and file system drivers loading) are rewritten in C.

24 May 2014.
SVN4189 released.
  • Unknown changes.

03 June 2014 -- 04 June 2014
SVN4191, SVN4192, SVN4193, SVN4194 released.

These are test builds.

04 June 2014.
SVN4195 released.
  • Reverted changes made in 4189 that caused bugs with HPFS boot, NETBIND and Presentation Manager
  • Reverted changes made in 3167 that caused bugs with process signals (SIGINT, SIGBREAK, etc).

06 June 2014.
SVN4198 released.
  • VIRTUALADDRESSLIMIT statement now works again in retail (non-debug) kernel only (the old init code was returned back probably).

08 June 2014.
SVN4200 released.
  • Virtual adresses limit now may be set with VALIMIT keyword in the [CONFIG] section of OS2LDR.INI.

15 June 2014 — 14 July 2014.
SVN revisions from 4202 to 4219 released.
  • No information about changes in these revisions had been provided.

04 Aug 2014.
SVN4221 released.

06 Aug 2014 — 22 Aug 2014.
SVN revisions from 4222 to 4224 released.
  • No information about changes in these revisions had been provided.

22 Aug 2014.
SVN4225 released.

24 Aug 2014.
SVN revisions from 4226 to 4227 released.
  • No information about changes in these revisions had been provided.


Programming / Re: Closed source parts of eComStation
« on: January 17, 2014, 12:19:56 pm »
(in fact you don't need to install, you can clone the whole thing)

Actually it's not a problem to unrar and sysinstx any OS/2 version.

Programming / Re: Closed source parts of eComStation
« on: January 16, 2014, 08:28:36 pm »
I have to agree, especially on the wireless and wired network drivers I'd put higher priority on this then I would on the 4GB barrier.


Admittedly part of my challenge was that I decided to use a spare OS/2 Warp Connect license that I had unused sitting on my shelf for this test setup.  I have no expectation to ever get Wifi working on Warp Connect, so this might seem like an insignificant example to use as an argument for good Wifi and NIC drivers.  However in this case networking and being able to find a way to connect to a Wifi network was absolutely necessary for the setup.  The 4 GB limit played no role in my decision to set up an OS/2 system.
Okay, if we're posting our (IM)NSHOpinons here, then I will share my experience.

I had never had a networking trouble with OS/2 that I could not resolve.

I'm putting the 4 GiB barrier resolving task the upper priority than the NIC drivers thingy, because the lack of the drivers for the newest NICs never had played a role in my decision to set up OS/2 systems.

To explain this I'll say that if we cannot substantively argue on the tasks' priorities, and we rollback to the stinky democracy, I will just give my vote to the 4 GiB task, and see what'll happen.

Programming / Re: OS/4 kernel - my first impressions
« on: January 16, 2014, 07:55:18 pm »
1) both, the OS/4 debug and also retail kernel trapped when they encountered valid CONFIG.SYS statements. In my case, that was the STRACE statement.
The latest (SVN revision 4163) version of the Phoenix kernel now does not trap because of the STRACE statement in the CONFIG.SYS, although the tracing support is still discontinued and will never (or soon) be implemented again.

Programming / Re: Closed source parts of eComStation
« on: January 16, 2014, 01:17:53 am »
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

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.

Programming / Re: OS/4 ? QSINIT ?
« on: January 15, 2014, 11:22:25 pm »
As with Air-Boot, QSINIT could go on for years, as it is, but there is currently no guarantee that it won't disappear tomorrow. Mensys is the "go to" organization for future OS/2 development, in the form of eCS, so it only makes sense that they should be the ones who walking_x makes a deal with, for a way to keep his work alive, even if he is unable to continue, for any number of reasons.

Don't worry, the project won't disappear. The developer is easily available on the IRC channel, I think, for about ten years, if not more.
You'd better talk to him directly, but please, don't make it worse.

1) STRACE is something different than TRACE. STRACE performance tracing is not all that important. But ordinary tracing via TRACE is important.

2) getting COM output via serial port is not a viable replacement for tracing. How will I get output from an end customer's system ? Asking the customer to create a COM port log ? He is just going to show me the stiff little finger ...

Why do you think did I add tracing to the USB drivers ?

Well, I think, TRACE support is dicountinued too.

You may talk to the OS/4 developers on the #os2russian channel of the efnet IRC network.

Programming / Re: Closed source parts of eComStation
« on: January 15, 2014, 11:07:49 pm »
Yes, and they are 4 developers who are wasting their time, if the more basic problems are not fixed soon.
Ok, that's enough for me. Didn't read more.

Programming / Re: Where do I find hd4disk.add, acpi4.sys ?
« on: January 15, 2014, 07:39:11 pm »
acpi4.sys also will not have suspend feature, so I am not sure you'll be interested in it...

Pages: 1 ... 18 19 [20] 21