• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu
Menu

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.

Show posts Menu

Messages - mobybrick

#16
Quote from: warpcafe on 2010.03.05, 14:46:51
Hey all,

for me, the most interesting part here is not "is that Kernel legal or not". Because:
The thing is (and you can twist your mind as far as you want, it will not change anything): It is illegal.
If you disagree, simply think
a) would IBM allow you distribute a patched Kernel (even if it is free)?
b) would Mensys gladly support your bug tickets with a patched kernel?

Cheers,
Thomas

Good post Thomas, but there is a perfectly legal way around this - distribute the patch file and mechanism that allows users to patch their own copy of 14.104a into the OS/4 kernel. Thereby no copyright binary code is distributed.


With regard to Mensys, my worry is that they will want a working ACPI - which, I suspect, will only be acheivable with the patched kernel. ACPI, on 14.104a, is broke and hangs badly. Besides, Mensys already have a 'beta' eComstation kernel, with the 'patched' extra HLT parts in it - but I suspect that the whole licensing argument (as per your post) prevents even Mensys from distributing it properly. Although, of course, only really Mensys are able to comment on that authoritatively!

Moby.
#17
Here is where it will get interesting. I suspect Mensys/Serenity have been maneuvered into an impossible position.

ACPI was one of the mains goals of eCS 2.0, but now with the core ACPI developer also responsible for a hacked kernel, I can see the days possibly coming when something along the lines of...

'If you want ACPI to work (e.g. not hang on bootup) then you'll need the patched kernel from the OS/4 team. Oh, and this would need to be distributed with eCS for the eCS ACPI feature to work...'

Or maybe I am dreaming again. Time will tell.

Regards,
Moby.
#18
The point I am trying to make is that with the debug kernel, application exceptions are handled differently.

I'm not saying that SYS 3175s will happen more or less with the debug kernel - as these exceptions are ring 2/3 application exceptions - so supposed uptime availability should not change - but that the debug kernel will appear to 'hang', waiting for serial port input, instead of a SYS3175 popup being generated. Unless of course a debugging exception handler has been installed or configured via kdb.  Of course, I could be wrong....
#19
Er, wrong, IMHO.   :D

If you have a ring 3 debugger registered, then SYS3175s will be handled by the registered debugger. If you don't have one installed (and most people won't) then the kernel debugger will be called, resulting in either a trap screen (or, more likely) what resembles a system hang. The system won't actually have hung, it will be waiting for instructions on the serial port.

How many SYS3175 popups have you had *without* any debugging software running?
#20
From what I've heard, this is a patched version of the 14.104a *debug* kernel.

Because its a debug kernel, beware. Any ring 3 access violations will in fact call then IPE exception handler... meaning that you get a black 'Trap' screen (and system halt) even on application errors that would normally be handled by the OS. So, this kernel is not suitable for production use IMHO.

Regards,
Moby
#21
Applications / Re: OS/2 date issue
2010.02.26, 00:33:57
If you have another Dell Optiplex 740 available (or indeed another PC) then I'd be tempted to take your new OS/2 installation harddisk out of the current Dell PC and try another. It's not impossible (although unlikely) that you have simply chosen a defective PC for your new OS/2 machine. There could be some kind of RTC rollover problem. The Optiplex diagnostics downloadable ISO also check for this.
#22
Applications / Re: OS/2 date issue
2010.02.25, 17:07:52
You'll need to unzip it, plus a copy of the CSF fixtool.

This link might help

http://www-900.ibm.com/cn/support/library/sw/download/FIXHELP.HTM#kicker

#23
Applications / Re: OS/2 date issue
2010.02.25, 16:01:56
Can't see any significant differences.

FP38 has one minor Y2K fix - a problem with WIN-OS2. You have nothing to lose by trying FP42 tho - most apps that work on FP37 will work on FP42.

But...

Do you have any applications open whist making this check. Use CTRL-ESC to bring up the window list and make sure you have nothing running.

Also, can you post a copy of your CONFIG.SYS please - lets rule out any rubbish drivers such as SystemView or TME10.

Regards,
Moby
#24
Applications / Re: OS/2 date issue
2010.02.25, 15:04:09
You have fixpack 37 installed, which is Y2K compliant. Fixpack 42 was released, but I don't think this will make any difference.

Is this an application, or the OS itself that reports the date wrong? Very weird.
#25
This is going to sound daft, but I wonder... did your colleague pull out the wrong disk?  When disks go bad on the PERC, the orange failed light should flash. Was this the disk that he pulled? If he pulled it when the system was off, then he might have pulled the wrong one. If he did, then the container will have been destroyed and needing re-initializing.

On some of the dell chasis, the discs are labelled 1...8 from the right hand side... but of course, in the RAID bios the disks are labelled 0...7.

PERC2s sometimes flagged as disk as 'bad' inadvertantly, but this was fixed in the PERC3 which is based on a different family/manufacturer of chipset.

Regards,
Moby
#26
Applications / Re: OS/2 date issue
2010.02.25, 12:14:24
What fixpack do you have installed?  If you are not sure, run SYSLEVEL > LEVELS.TXT from the command prompt, and then use the E editor to view levels.txt.

Moby
#27
Can you be specific? Which scheduler? OS/2 Warp did not (AFAICR) have a scheduler out of the box - only the server versions did.

What version are you using, and which scheduler?

Moby
#28
AFAICR, the part of the code that would have to be removed wouldn't be GRADD (as I don't think it contains anything more than was available on the DDK) but... SciTech I believe had an NDA with ATI. I suspect that the ATI specific code would have to be removed... and as that is more than half of the supported chipsets, I'm afraid that renders most of the product far less useful.

MenSys, or whoever, would need to take on SNAP on a commercial basis - buy the IP - and ask ATI to be successors under the NDA. It would then need to remain closed-source.

So, IMHO, asking the new owners of SNAP to open-source it is counter-productive. Not only would it be expensive to get the code reworked to get the ATI stuff removed, it might actually be cheaper just to buy the rights to the code and IP - assuming MenSys would be intrested in doing so.

Moby.
#29
Hi,

I've sent it to you...

Moby.

Quote from: JHod on 2009.11.13, 00:53:27
If anyone has that tool that Mobybrick mentioned, I'd appreciate a copy.  Thanks!
#30
The only other product I know existed, but never made it to release, was the OS/2 Warp DSS product - the OS/2 Warp "Directory and Security Server"  A beefed up version of Warp Server 4.0, this supported kerberos authentication and provided an LDAP-based directory. A new version of the IBM LAN Server software (with many of the historic bugs removed) was produced.

But for some reason, the next version of Warp Server, WSeB, used the old code-base. I could never find out what happened to LAN Server DSS - despite IBM trying to sell it to me several times.

Moby.