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 - Andi B.

Pages: 1 ... 27 28 [29] 30 31 ... 34
421
Setup & Installation / Re: How to get ride of HPFS386
« on: August 27, 2014, 09:33:24 am »
Quote
Did you use SYSINSTX after swapping IFS's
I don't like to switch the FS of current installation which is JFS. But only want to REM out HPFS386 and after that enable HPFS. But the first part - reming out HPFS386 - leads to the problems booting my current main JFS boot partition.

422
Setup & Installation / Re: How to get ride of HPFS386
« on: August 26, 2014, 10:09:38 pm »
I've no processes in my config.sys which as mentioned here http://www.edm2.com/index.php/The_Config.sys_Documentation_Project/OS/2-eCS_Commands#PROCESSES should give the default of 256. OTOH Theseus says QSV_MAXPROCESSES = 1025.

Threads is currently set to 1024. More than 300 threads are running currently although the system does not have much to do now.

Will try with processes=256 and threads=512.

AOO / HPFS386 - I do not think they are related too. Only wanted to kick off HPFS386 to be sure before I create a ticket. But seems to be not that easy :(

423
Setup & Installation / Re: How to get ride of HPFS386
« on: August 26, 2014, 05:46:19 pm »
@Boris - Theseus during boot before it traps?

After booting with HPFS386 I've plenty of memory free. But latest AOO eats a lot and only partially frees them when closing with dlls are loaded high --> no more than 5 to 15 open/close cycles possible (depending on other running software).

OTOH it just comes to my mind that I can not increase Virtualaddresslimit above 15xx as bootup stops with AFAIR 'out of memory' too. Another mystery maybe not related.

424
Setup & Installation / Re: How to get ride of HPFS386
« on: August 26, 2014, 10:23:25 am »
I want to go back to HPFS cause I think I can save some memory. AOO and some Java apps needs a lot of them and I've no need any more for 50MB cache for HPFS (the only reason why I sticked to HPFS386 since years). Maybe I should only decrease the value in hpfs386.ini.

My problem seems to be a timing one. Even disabling HPFS completely or hiding HPFS partitions (removing drive letter) does not help. I get various 'out of memory errors' during boot in different places followed by TRAP 000e or TRAP 000d depending on sorting of config.sys. And/or dllbasing on/off and reming out netwstat.200 (?) or some other network related statements.

Only timing problem I'm aware of is Genmac and Helperw.sys which is _not_ installed on that system. Maybe the combination of switch.os2 (VirtualPC) and vbox.sys does make some trouble too as I remember it wasn't easy to get VPC and VBOX working together. But that's only a guess.

This system works fine since about 7 years (different harddisks, lan driver, kernels, ACPI version....). I think I've switched between HPFS386/HPFS previous without any troubles. But this time....

Maybe it's not worth to invest much time anymore as I plan to build a new system anyway. But for that I only want to copy over my current installation which will give me the same problems probably. :-( OTOH I do not like bugs I can not clearly identify and resolve or work around.

425
Setup & Installation / How to get ride of HPFS386
« on: August 24, 2014, 06:24:08 pm »
I've used HPFS386 in the past. But now my boot partition is JFS since a long time and the only HPFS partition is one for maintenance boot.

I was in the impression I only have to change in config.sys -
Code: [Select]
IFS=m:\IBM386FS\HPFS386.IFS /A:*
CALL=m:\OS2\CMD.EXE /Q /C m:\IBM386FS\CACHE386.EXE
to
Code: [Select]
IFS=M:\OS2\HPFS.IFS /CACHE:2048 /CRECL:4 /AUTOCHECK:*

But if I reboot I get strange errors. First in the middle of the screen between other drivers saying something there is not enough memory. Think it's after loading sddhelp.sys. After hitting Enter
Code: [Select]
SYS0613: Not enough memory is available for....and after hitting Enter again a Trap 000e.

Surely HPFS386 cache needs a lot more memory than the 2MB of HPFS. And even with HPFS386 I've >200MB shared memory left. So do not understand the complains about memory.

Any help?

426
Applications / Re: Apache OpenOffice 4.1.1 RC3
« on: August 23, 2014, 06:04:31 pm »
A few observations with 4.1.1rc3 -

Do not use too long paths.
Code: [Select]
T:\Temp\Apache_OpenOffice_4_os2gcci_install123\Apache_OpenOffice_4.1.1_os2gcci_install-arc_en-US\OpenOffice 4\program\soffice.exedoes not work but

Code: [Select]
T:\Temp\Apache_OpenOffice_4_os2gcci_install12\Apache_OpenOffice_4.1.1_os2gcci_install-arc_en-US\OpenOffice 4\program\soffice.exeworks. Seems there is some 128 char limit. I've created a ticket for that.

Memory -
I had all sort of memory leaks. Lower shared memory and higher shared memory run outs when using the dlls marked as HighMem or not. I could not start soffice.exe and immediately closing it more than 7 times before I had to reboot as there was no shared mem left.

But now after fresh reboot and fresh unzip an not loading dlls high it seems AOO gives all memory back when closing. I've successfully tried more than 12 times now. And Above512 still says
Code: [Select]
pm: 200256 sm: 127168  <---512---> pm: 917504 sm: 780552Starting soffice.exe and closing gives the same values.

I don't know why I had this terrible memory leaks before (about 85MB every start/close). Maybe it's because I loaded dlls high (will try soon) ore more likely cause I started different AOO and OO versions (3.3, 4.0, ) in parallel or one after each other. Maybe one of the 4.0 dlls was still loaded and leads to that problem, currently I don't know.

427
Applications / Re: Apache OpenOffice 4.1.1 RC3
« on: August 22, 2014, 04:25:14 pm »
Ivan
Quote
unless you have moved the required external DLLs in with the OO DLLs your method will not work
I do not really understand what you mean with this. AOO dlls are all in \program dir. If you drop a reference somewhere maybe it will be required to set the 'Start in directory' (?) setting in the object. Have to check.

Other required dlls (gcc... libc...) are up to date in \usr\lib by 'yum update' on my system which is of course in libpath.

428
Applications / Re: Apache OpenOffice 4.1.1 RC3
« on: August 22, 2014, 01:09:23 pm »
I start soffice.exe from cmd line in the \program directory. Or by clicking on the symbol in that folder or dragging a reference somewhere ...

No need to play with libpath.

429
Polls / Re: eComStation Retail Store?
« on: August 07, 2014, 06:01:10 pm »
Quote
especially the lack of a fully functional virtualbox in my opinion.

What is missing?
- working netbios support (list files in all directories not only in some)
- full network support (mulitcast, server support)
- running more than one instance
- USB

to name a few

430
Setup & Installation / Re: Is eComStation DEAD?
« on: August 03, 2014, 10:37:30 pm »
I memory serves me well Ian you're the guy who even read Austrian newspaper. I've got the feeling we share some quirks...

431
Setup & Installation / Re: Is eComStation DEAD?
« on: August 03, 2014, 08:26:25 pm »
Quote
Wouldn't it be more useful to find a Volvo driver who wants to drive it until it breaks apart and save the money for the Ferrari parts?
That's the way I do it although I fear I can not save enough money for the Ferrari during the rest of my lifetime :) But honestly the Volvo (eCS) isn't that bad...

Quote
(Car comparisons usually don't work.)
That's true as I can not see any OS which compares to the Ferrari.

432
Setup & Installation / Re: Is eComStation DEAD?
« on: August 03, 2014, 12:54:56 pm »
Quote
You can take a Ferrari's chassis, dash and seats, and stick them onto the innards of a Volvo... but what you end up with will not be a Ferrari. It might be a nice car, but neither Ferrari lovers nor Volvo lovers would likely be impressed.
I like this statement very much. :) Well done Alex.

Even if someone could find and pay the manpower to program a WPS like GUI on top of Linux nearly no one will use it. Cause even in 15 years it will be by far not as stable and bug free than all the other *nix frontends already available. Nor will it be able to transfer the look and feel of the *nix apps to OS/2.

I get the feeling most of the people here do not have any clue hwo the different parts of an OS works together to generate the typical 'feeling' of these system. It is a dream to only port some GUI on top of another kernel + drivers to continue working the way we did lets say the last 20 years.

If I ever came to the point where I've to use another base OS on my private systems the smallest part will be to learn to live with the different GUI. Users of other GUIs will ROFTL when knowing the restrictions and bugs of the WPS. Come on, we use OS/2 - eCS cause we are used to it as a whole. We like the stability (ahm, this is not true anymore, other systems are more stable now, only try to compile some stuff or heavy use the WPS or...), the lack of viruses, the antique look and feel, but mostly cause we are used to it and know every single config.sys line and os2.ini entry by heart. If you change the base there's only a small additional step to use another GUI.

Long term plan - IMHO Mensys (to be more specific Roderick cause who else has worked on eCS there?) did have sort of long term plan. But his plan was based on a little more realistic estimation of what can be done with the little to non existent developer and user base than on big dreams we read ever and ever again. If you ever have written some code or contributed to some open source project you would know who much effort it needs to only improve some small parts and bring it at least to a quality level users start to try it out and give feedback instead keep silent or even worse vague complaining about although they not even looked at the readmes. Moreover even if people work a long time on some stuff and get paid for it, there's no guarantee to get some useful output. Only think about the crappy ACPI before David took over.

What I want to say can be summed up as stop dreaming of 'warme Eislutscher' (maybe someone can translate this ;)) and get of the ground and support the few people who invest hours and hours of there private time and money to let you run your system on some new hardware still today. Even if it costs you a ridiculous amount of money like OpenOffice SS, Java/QT4 sponsoring units or Injoy/PMView/Mesa/.... license. If these few developers leave it's finally over. And trust me, if these few active developers decide rpm is a necessity today then start using it. Write articles how to use it for dummys or fill tickets instead endless discussing why you dislike this non native OS/2 way of doing things. Other options are to use some sort of rpm on *nix or get used to stupid WIn behavior not storing window size an position any more or....

433
Setup & Installation / Re: eCS 2.1 yum update urlgrabber problem
« on: July 30, 2014, 09:43:31 pm »
Quote
Got any other ideas?
Append your findings to the ticket. As the 2 other who run into this problem has solved it and Yuri changed the packet and thinks now he has solved the issue, he probably never look into it again if no one else reports the problem.

434
Applications / Re: A-Oo 4
« on: July 28, 2014, 12:04:52 pm »
Quote
This issue has been solved by a tool called highmem (a derivative of January June's above512 made by Paperino), and it is safe to use it since kernel version 14.106_SMP.

Tho not all DLLs can be marked as "loadable above 512", but the majority of them.
The issue is not 'solved' and never will be I fear. Loading dlls into highmem is a workaround for this shortcoming but no solution. I like the concept of shared dlls in contrary to 'every app loads a huge amount of code into memory which does nearly the same as other app does'. Moreover even highmem is limited to a few GBytes which isn't that much nowadays if you're forced to run multiple virtual machines as the main OS misses necessary pieces of software.

AOO410 with dlls in highmem runs flawless here. But load Seamonkey and OO310 which is necessary to open old .sdx files and you see nearly no low mem left till next reboot. 1152 currently here only after some minutes after booting and OO31 even closed.

435
Applications / Re: A-Oo 4
« on: July 27, 2014, 12:38:07 pm »
Quote
Yum/rpm sucks, belongs to a system with a very bad management in files and directories. We have a fine object oriented system, lets make use of it.
So start rewriting all these ported stuff to native OS/2 apps. Mozilla, OpenOffice, QPDFview, VLC, SMplayer to name only a few of them. Yoop I think you're dreaming of times where we could use OS/2 the way it was designed and neglect this times are over more than 15 years now. If you want use ported stuff you've to live with their annoyances to some extend.

Quote
DLL's which belong to the program should be installed within the directory structure of that program ..... Only DLL's for general usage by every program should go there.
That's the usual approach for ported stuff too. But sometimes it's not easy to decide which dll will not be used by another program. Moreover often some dlls will be reused by another program afterwards what the initial developers could not foresee in the first place. Just to give some ideas that the whole dll issue is way more complicated as some people think off.

Additionally we do have this very bad shared mem problem on our platform. So we have to reuse (share) dlls as much as possible. Building matching dlls for each program and distribute it in the programs directory and let every program use the special version of the dll would work for other system where these shared mem problem do not exist. But unlikely not for us.

Quote
Moreover, if I install it I know were what is put down, if YUM/RPM does it for you just say some prays.
If you're the one who do not forget anything you're the lucky one. But numerous complaints, tickets and threads prove that the majority of people do not remember that they f.i. installed gcc442.dll in some program directory years ago. They do not even fire up pmdll or similar tools to find out which dlls are necessary nor do the make a search with f.i. 'which -lasu xxxxdll' to find which dll will be used. They do not understand when which copy of a dll is loaded and unloaded nor the consequences of libpathstrict. They only complain that program x 'does not work' or 'does only work sometimes' or simply 'sucks'.

I've installed yum/rpm on my programs partition p: and 'SET UNIXROOT=P:'. So I've no problem with my system partitions. I can use my programs from different eCS partitions without problems with this setup. yum/rpm works for me most of the time flawless. There where some problems which where repaired after I opened a ticket at netlabs or discussed directly at irc channel. Like all our currents software yum/rpm lacks of development and test time AND users who are willing to work with it and give FEEDBACK and create tickets if necessary.

Pages: 1 ... 27 28 [29] 30 31 ... 34