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 - Dave Yeo

Pages: [1] 2 3 ... 82
Applications / Re: Mouse Pointers
« on: January 11, 2018, 06:53:02 pm »
You probably should open an enhancement ticket. The ArcaOS people seem to be busy, without much time to read this and a ticket won't be so easily forgotten.

Applications / Re: SDL on the Netlabs RPM Repository
« on: January 11, 2018, 06:17:58 pm »
The problem with removing it is then certain packages such as FFmpeg can't be downgraded to an older version.
In the interests of chasing bugs and such, being able to downgrade packages is a good idea.

Applications / Re: SDL on the Netlabs RPM Repository
« on: January 11, 2018, 05:27:19 pm »
Dariuez, that asks the question,  why is there any RPM SDL there in the first place.

The impression given is that RPM is supposed to make everything easier yet there are several instances when it does the opposite.

It is there for FFmpeg, or rather FFplay, which uses SDL to display videos/audio. Once there are other packages that use other SDL components such as sdl-mixeer, I guess there will be packages for them. It's a reflection of the shortage of manpower running the RPM stuff.

SDL is a bit hard to deal with on OS/2 as it is usually built with OpenWatcom and needs some mickey mousing (import libs, sdl-config script and pkgconfig script) to use with GCC and the autotools.

Applications / Re: XWP v1.0.12 Beta 1
« on: January 11, 2018, 06:13:22 am »
Just what it says, your ini files have corruption and have lost your desktops handle. I've had that happen on Warp 4 but never seen that dialog. You could follow the directions are restore your ini files from a backup. IIRC, I've also used checkini to fix it.
Actually, one possibility is that they've grown too big and need something like checkini ran against them.

Applications / Re: SDL on the Netlabs RPM Repository
« on: January 10, 2018, 11:08:18 pm »
Didn't the sdl package get replaced by the SDL package? Here I have SDL-1.2.15-5 installed.
One problem is that this seems to be the minimal SDL package, without sdlimage, sdlsound, sdlnet and sdlmixer, which are often required for games. For lbreakout for example, I have all the dlls in the lbreakout directory though testing now by removing sdl12.dll, it seems to work.
Probably need more RPM packages covering the above dlls, also a sdl2 package.

Applications / Re: Dynamic Icons
« on: January 10, 2018, 08:53:03 pm »
I'm not sure how the WPS allocates the memory, whether as icons are opened or all at once. Hopefully as icons are opened and it is released when the icons are closed.
About the memory, or at least my imperfect understanding. On OS/2 systems before 4.5 (earlier with Warp Server), processes only get 512 MBs of shared address space, minus whatever DLLs are loaded and memory they use. eg Right now on a freshly booted system with SeaMonkey running, I seem to have 230 MBs of free lower shared memory. Making it even more complex is that the memory can be fragmented, program requests a bunch of 10MB chunks and then frees up every second one leaving a bunch of 10MB holes. Another program wants to allocate a 20MB chunk and fails even though there is lots of free memory.
Latest versions of OS/2 ca also use high memory if compiled to. So things like Mozilla mostly allocate high memory. Unluckily some of the OS/2 API (old 16 bit stuff) can only access low memory so a big memory hog like Firefox mostly uses high memory and even the DLLs themselves can be loaded high but still needs some low memory and when high memory gets full/fragmented falls back on low memory.
And understand we're talking virtual memory, not physical memory.
My description above might not be quite right but that is the general idea, namely that low memory is a scarce resource on OS/2.

Applications / Re: New Styler titlebar bitmaps
« on: January 08, 2018, 10:28:09 pm »
You could test under sh.exe and see if the shells wildcard support works. Otherwise write a script, perhaps to do all files in a directory.

Applications / Re: New Styler titlebar bitmaps
« on: January 08, 2018, 06:51:51 pm »
You could use eautil to split of the extended attributes into a separate file and rejoin them later.

Applications / Re: Desktop Backgrounds
« on: January 08, 2018, 05:45:47 pm »
I'm not an expert but it seems that both jpgs and pngs have their own advantages. Jpeg might be better for things like landscapes.
One thing to consider is different resolutions of the desktop and how many resolutions of backgrounds you want to create compared to re-scaling.

Storage / Re: Extended Attributes - OS/2 only thing?
« on: January 07, 2018, 08:47:59 pm »
There are Linux filesystems that support 64KBs of EAs or more, the obvious example being JFS, which is what I usually use on Linux (except /boot where I stick with ext3 as grub has had problems reading JFS) as it is considered one of the best all around file systems.
EAs do have to be enabled in the kernel and mounted correctly to support them.
On Win NT, EAs have always been supported by some file systems, first HPFS and then NTFS, which has one stream purposely to support EAs (uses codepages rather then unicode IIRC). I'd assume the support is still there in the latest versions but don't really know.

Applications / Re: Dynamic Icons
« on: January 07, 2018, 08:27:12 am »
Looks good.
About performance, I think the problem is actually losing address space in the lower arena causing programs to fail quicker. This could be tested with Theseus by measuring memory with and without the dynamic icons.

It is unsupported, to quote from the latest beta,
1. There is no current way to apply some of these changes to an installed system. is a standalone full install.

Never the less there are scripts and programs out there that will attempt to back up your OS/2 desktop and restore it to a new install. Config.sys and %HOME% would also need to be backed up and restored/merged and there may be other stuff. You are free to experiment.
Currently the latest is just an incremental update, but eventually there may be a large update with enough changes that this will not work.

There is also the option of just using Warpin and ANPM to update the parts that have changed, either from the ISO or your subscription. As many of the changes are to the installer and don't matter once installed, this should work.

Programming / Re: OS/2 kernel requiring speculative execution patch!!!!
« on: January 07, 2018, 03:16:45 am »

I'd need to see citations or a source test to confirm, because as far as I can tell, it is exploitable on x86 on any OS.

Well you can some ideas about proofs of concept code here,

But think about it. What are you trying to protect? You're browsing history? Any process can read files on the disk and history is not encrypted. Your logins? They are encrypted on the disk and in the kernels disk cache memory, other then that they aren't in kernel memory. they may be in the browsers memory, in which case any JavaScript flaw can be used to read them as they're all in the same process. Another program could use Spectre to read a different processes memory.
So a malignant program could in theory read the browsers memory, it is going to have to be an OS/2 program that you run, possibly through trickery. Who is going to go to the trouble to write a malignant program and target you? Quite likely due to timing problems, the code will have to target your exact CPU, which I believe you've mentioned is an old one.
If you're really worried about security, there are easier flaws in our discontinued browser to exploit, often using cross platform code such as JavaScript. Much easier but even then you often get code trying to run C:\Windows\cmd.exe and failing on OS/2.
If you're really worried about security, you should run one of the BSD's and even then there is a risk of a zero day exploit.
The real worry is someone targeting your bank, a much richer target.

Programming / Re: OS/2 kernel requiring speculative execution patch!!!!
« on: January 05, 2018, 07:27:34 pm »
Yea, my understanding is that the way OS/2 manages its memory, getting access to kernel memory isn't that big of a deal as we don't have permissions or sandboxes so just need to read a different tabs memory or even the swap file if one exists.
As for the code, it seems to have to be tight assembler, which, as you say, has to target OS/2 and be delivered.
There is a proof of concept using Chromes JavaScript JIT but even that would have to be targeted as there are many code paths in the JIT depending on CPU etc.
The real problem is in data centres and such as this allows escaping from a virtual machine or/and getting roots password.

Hardware / Re: PCIE Wide Screen video
« on: January 05, 2018, 06:29:49 pm »
Any with enough memory (128KB?) should be able to do it. The problem is having it listed in the video BIOS. With Panorama, you can force it to use the wide screen resolution and with SNAP, you can patch the BIOS and replace a resolution with 1920x1200.
For SNAP this worked here to force 1680x1050. Forget where I got it.

Pages: [1] 2 3 ... 82