AngelsHolocaust
-
Content count
651 -
Joined
-
Last visited
Posts posted by AngelsHolocaust
-
-
That goes for an updated VP too.Which I won't use anyway, maybe I will merge some code but that's it. :)
(why update old targets)To have bugfixes and other improvements in the project propagate. And to react to changes in the OS and other
dependant parts (in our case: GDB, but also >32-bit filesupport, LFN, sharing etc, sockets) .
LFN is vital of course.
I am curious: what DOS supports working 2/4GB+ file support?
I now that there is FAT32+, but I don't know if it really works.
But there are serious management issues with non-trivial amounts of assembler.Don't believe me, read any software management book. If you don't agree, I'd like to see a ARM port of VP.
I am not talking about a total rewrite of a software largely written in assembler.
My point is that the argument of such software not being able to be maintained or
updated/improved is invalid, IMHO. There's always someone who can do it.
Anyway, your ARM-VP-port argument is unfair. :P
VP probably never was designed to be ported to other OS's or to support non-x86 CPUs.
Same reasons as with dos. Stopping of maintenance over several years is effective death in a fast moving project (14000 revisions since 2005). Tackling a problem when it occurs, and you can communicate with the person would did it, and influence the design maybe is way more productive.OS/2 is a bigger problem, because it was not even complete.
This is what I don't understand, especially concerning a compiler (sorry for repeating myself again):
Software does not need to change low level (OS) code constantly with new features or bugfixes.
If you have to do that then you probably have a code design problem.
Higher level abstractions should work with most new features independently of the target OS.
True. But in the professional work, those are often in minimal maintenance only mode. Professionals usually migrate when they are stuck in dead end with a codebase that is still actively maintenance and development.Yes, because there's no time to waste.
There's no good argument that explains to your boss or customers why you have
to "waste" quite some time just to use another development software.
Especially if there will be no "visible" improvment after the software switch.
-
Hi Dan,
include and exclude masks do only check the actual file name.
I have added this to my todo list (I should rename it to BOOK...).
Thanks for the hint on the wildcard options.
Stefan / AH
-
Added.
Stefan / AH
-
Thank you Dan.
Stefan / AH
-
Hi r00t.
True, this is still not implemented but on my long todo list
(search for "to do list" in whatsnew.txt...):
+ add Creation/LastAccess date/time to FilePanel display
Problem with the additional times/dates is that we are running out of
suitable character IDs (in file panel hit ALT-K and F1 to get an overview over
all the column identifiers).
Maybe it needs to be rewritten to support not only single characters but words.
I cannot promise anything, sorry.
DNOSP code is almost 100% incompatible to NDN by now.
And the source code is available for people who ask for it. :)
All the best,
Stefan / AH
-
I think in general the effect would be beneficial. You might be able to clean up a lot since the FPC rtl is simply richer, and designed for portability.But it might behave differently than what NDN requires, hence RTL modifications for NDN would maybe be required too.
If you plan expansion rather than mere maintenance, I'd look into FPC. It will expand with you, and surprise you occasionally. Like the complete DBF,CHM, various images support.I do plan expansion.
The possibility to use C libraries actually gives me enough possibilities.
If I cannot use existing code, I will write my own.
Please provide reasons. Moreover, FPC core didn't let it die, the Dos users did, by not participating in development enough. The FPC core kept it on life support for years, just in the hope that somebody would step up. But at some point attrophy sets in and the result is no longer shippable. That happened during 2.2.0What reasons are there to keep an older software/OS alive? Because...
- there are still users out there (esp. concerning DOS)
- it's entertaining to support all possible targets
- keeping it for historical interests and future references, not losing knowledge
The question here is, why does a *compiler* actually have to update it's older targets all the time?
From the language point of view there should be no need to change anything target specific
(btw, except for a few glitches the VP language support is good enough for me).
Of course, if the RTL is not complete, like missing LFN, then you might need to update it.
But at some point of development it should be possible to drop active development
without making the DOS port unusable in future releases.
What makes the FPC core devs having to update the DOS RTL constantly over years?
During 2003 or 2004 Alan offered us a copy of the VP sourcecode, to see if we could use parts. (But not yet the permission to actually do) However the full compiler is in assembler makes it essentially "don't touch". The IDE is hampered by years of workarounds and copyrighted code. The documentation needed commercial tools. Nothing was really directly reusable.I don't agree on the assembler statement, but don't let us start a discussion on that. ;)
While a minor disappointment, that was not that much of a problem for us, the main attractions were more in the OS/2 direction, where VP has been traditionally strong. However FPC OS/2 development slowed down during that same period due to responsible people graduating iirc (and hasn't recovered since), and new OS/2's are virtually non-existant, so there were simply no people to follow that up.FP DOS == OS/2:
Why should newer FP releases suddenly break/lose the OS/2 support?
So most of the VP code was quite totally unmaintainable and the rewrite to tackle that needed to restart VP development, would have alienated the extremely conservative users. (which were with VP and not FPC exactly because of that conservatism). I never have believed in a succesful restart of VP.An attempt would not survive the two years (or longer) to totally rewrite, cleanup and replace copyrighted parts. (It took FPC two years to just replace TV), and Pascal is not popular enough to survive that.
Yes, VP as NDN users are pretty conservative. But you get used to it and become careful with
changes and new features. In fact that is the real life situation in professional projects.
Personally I would have liked VP to have been put in maintenance mode in 2003-2004 and then direct all future efforts into making migrating to FPC possible. A merge of the projects at arms lengths so to say. I proposed that to Alan then, but he had doubts. Meanwhile heaps of indignant users pledged solemn allegiance on the maillist to start developing VP, and Alan kept VP alive. I (and anybody else who had done any work in large Pascal projects) had serious doubts, since clearly nobody of them had compiler experience, and most didn't even have experience enough to make bugfixes.I personally would have no problem with a maintenance mode, except for the possibility to add new compiler targets.
I didn't want to be a killjoy though, so I helped Noah Silva to backport FPC's sysutils to VP (to fix one of the copyrighted source problems), but that died out because Noah dropped out. Afaik he realised how much of Delphi compability was really missing in VP, and this wouldn't be a onetime effort.The only one who afaik really did something was Veit, who worked quite hard, but he is more a RTL/library maintainer like I am, not a compiler devel. At least not yet.
1 1/2 years later nothing had happened effectively, and Alan pulled the plug. He has once made a remark that I probably was right back then proposing to put VP in bugfix only mode in 2003 (roughly the state it is in now), and direct future users and efforst towards FPC.
FPC had less to gain than many people think. Essentially we hoped that Veit would cross over, at least partially, and that the understaffed "old" ports Dos and OS/2 would have given a gust of life. Maybe some of the stability freaks could have been used to maintain older FPC versions with bugfixes only to get very stable FPC releases too.
I totally understand you, if I would be maintainer/user of FP I would have hoped the same to happen as you did.
Fact is, it didn't happen.
But even if DOS users will send FP bug reports, who will fix them?
In fact you not only need the users, but users who can fix the problems too.
I have to repeat myself:
As long as VP is good enough for my future NDN plans, I will keep using it.
If I ever have to switch to FP, I will let you know! :)
All the best,
Stefan / AH
-
Hi Dan,
I've actually fixed this yesterday.
This only happens if NDN has to change the screen size twice on startup.
The default console window in XP has a window buffer of 80x300 or something.
So NDN changes to 80x25 and then to your configured window size.
The scrollback buffer is on my todo list for quite some time, but....
Well, you know what I want to say. :)
All the best,
Stefan / AH
-
Hi!
I tried to access NDN on Ubuntu from another PC using PuTTY - and all keys works perfectly! So the problem is thatNDN can't read movement keys from build-in Ubuntu terminal.
Ok, try this:
start xev from the command line. A new window should open and show all events on that window.
Please, try all the keys that don't work on that window and post their KeyCode values.
Probably these values are different from the oney NDN expects.
(Does NDN work with UTF-8 now? - I have some troubles with russian chars on Ubuntu)No, still no Unicode/UTF support.
I don't even know if it will be possible at all.
Bye,
Stefan / AH
-
Hi Basil & Dan (thanks for helping out),
I always fear those topics, since I am having a hard time to remember the Linux specifics...
A) Real LINUX terminals
NDN only really works like DOS/WINDOWS in a real LINUX terminal, and only when starting it with "sudo ndn ...".
With "real" terminal I mean the text window you see after pressing ALT+CTRL+1-6.
ALT-CTRL-7 shoud bring you to the X-Window system.
B) X-Window terminals
I have quite some problems with these terminals (emulators to be exact).
Please see the bottom of the NDN online help "Supported Operating Systems" for
a detailed list. I will soon try again to get all this fixed, but it's a mess (no, not the NDN code).
Also don't forget "sudo ndn ...".
Keys and mouse ONLY work here because I access the X-Window system, if I can...
C) Terminal emulators like Putty or without X-Window or without sudo
Here NDN only can access what the Linux kernel sends over the standard
communication pipes.
Simple example:
If your Linux system/distribution sends A where it should send B.
NDN will get an A, even if you want it to get a B.
In other words:
NDN (and ANY other standard Linux program) does not read the keyboard directly
but a stream of data which has to be interpreted / decoded.
If it doesn't get what it expects for left arrow, it cannot act accordingly.
I tryed NDN on Ubuntu (9.04) directly and reveal strange thing:Arrows don't work at all!
What of the above "terminal types" are you using?
Are all 4 arrows not working?
What about PgUp/PgDn?
If you give me more information I can help you maybe.
Stefan / AH
-
Hi Dan,
I can confirm a problem with highlighting this.
But for me it *does* start the second comment highlight.
Instead it doesn't stop anymore until the EOF.
I can only add this to the todo list since I haven't
done any highlight updates in a while and it will take
quite soem time to get into it again, so I plan to do it all
at once when I get there...
Hope you don't mind,
Stefan / AH
-
Hi Dan.
The standard file (un)selection features don't work on directories at all
(I have just checked this).
What you actually want is to include the path name in the selection process.
And I have already found this on my todo list:
+ add 'include directories' to (un)select dialogs (anbrx)So, I guess there's no problem to add options
'[x] Include directories''[x] Include path names'
to both of the selection dialogs.
We should also not limit ourselves to the FIND VFS only.
Does that sound ok?
Stefan / AH
-
Hi!
Filename only; I didn't answer too much time, I know :)No problem.
Now I see that NDN jumps between files which starts from pressed char - very good step to the feature requested ;)I took this feature this from Windows I think...
It's really a long time since I added this.
It is a very good tradeoff between time to implement it and usage of the requested feature.
As it is it works in all history like list windows, not only the history,
without need to touch the code again.
The file panel quick search is pretty complicated.
If there's really a need for a more complex search operation please post again.
Stefan / AH
-
Hello haman!
I want to pick up what you started.
I think it is time to check whether NDN should have some features enabled
by default that are now disabled.
I suggest these features to be enabed by default which are now turned off:
-> File Manager.Setup
Restore Temporary Files
[ALT-F~1~/F2] Show VFS
Show Driveline info window
-> Interface Setup
Allow multiple help windows
-> Mouse Setup
~T~rack in menus
-> Editor Setup
New file loading
Any comments on this?
Stefan / AH
-
Nice.
I have added the Twitter links to the homepage.
Stefan / AH
-
Hey Dan!
I published a screencast on Catalyst (the best Perl web application framework) and I used NDN to edit some Perl files.Then, someone noticed NDN in the screencast and tweeted about using NDN on Windows.
Interesting.
"Strange" how even the most up-to-date software still can be used from command line.
I remember doing all my Oracle DB stuff from out of NDN, even the final tests...
PS: would be nice if NDN got a Twitter account and published updates there. AH?Ha! Thank you for the idea, but... doing homepage updates already satisfies me more than enough. :P
I am no fan of Twitter, but if someone else wants to do this, it's ok with me.
Thank you!
Stefan / AH
PS: Maybe you want to check out the new release?
-
Partially yes, while the FPC RTL is much more battletested on non-dos (win32/64, *nix, OS X), it is much less aDos emulation like VP's is, due to the larger number of platforms, and a much,much higher percentage of
users whose current development efforts don't date back to Dos TP times.
Here's the first problem I see (if understand you correctly):
NDN *is* a DOS program. How many TP compatible RTL calls would I have to replace
with FP compatible ones?
Moreover, mutating the RTL too heavily would just move you from one island (VP) to the next ( a specific FPC version, frozen in time)I don't want to call it mutating. But from my point of view all RTL targets should behave the same
(if possible). So yes, the VP W32 and LNX RTL had to be modified, because they were not written
with that in mind.
I wonder what RTL comparison results I would get with FP.
Still it is a pity that nobody won't even try, because we ourselves don't know the exact situation of the older FPC ports. How much of it issimple some minor attrition, and how much is fundamental. For that you really need true users, that make detailed reports with narrowed down tests etc.
And to be honest, if no users wants to invest in Dos anymore, I'm having doubts investing in it as a FPC developer too. Maybe it is time to let it die.
Well, I asked myself the same all the time the past 6 years.
Who cares for NDN? Or how many?
There are some die hard and loyal users which stayed with me over the years.
But there's no really big community - at least not obviously.
Still I enjoy working on NDN because there are so many things I can
try out and I can add almost everything to NDN that makes using a
computer worthwhile. Like DOS FTP support.
I look forward to 2GB+ support and getting the LNX port back on track.
As soon as I hit plugins it will get really interesting.
Even if NDN is progressing slowly like the past few months,
I still don't have the feeling it's not worth investing more time into it.
I don't know all your reasons for working on FP.
If you don't feel it's worth your time then you have to stop it and
find something new.
It will be a mistake to let the DOS port die completely, maybe even
not supporting it anymore at all in future releases.
As much as it was a failure to drop the active VP development,
especially new targets...
All the best,
Stefan / AH
-
Hi friends,
after the first 3 months without a NDN release I feel really bad and I also feel
obliged to let everyone know what's going on.
First of all: NDN is not dead!
Having that said I want to give you a quick update on what has happened the past 3 months
and why there hasn't been any new release.
After returning from holidays around the 21st of January, I went back to my PC
with a lot of motivation. Before continuing any work on my PC I decided to do
some clean and back ups. I then realized that I had an unfinished DOS Network
configuration started long time ago and decided to give it another try.
After a few hours I got that working - unbelievable.
So, I started immediately working on adding NDN's FTP implementation
(and everything networking that might come in future) to the DPMI32 target.
And this is where it all began.
Of course, the DOS TCP/IP stack had to have a BSD compatible socket interface.
And, for the beginning, I decided to settle on the PC/FTP packet interface for network communication.
I have been looking for all possible stacks that can be used for internet networking in DOS,
and ported (or tried to) a lot of them to VP or BC.
Just to name a few in trying order:
wattcp, watt32 (forget these, also C only)
libtso (better, but also pretty unusable for non C targets)
tppktip http://www.klaus-hartnegg.de/pascal/ip/ (very good, he received my ported code, unfortunately doesn't include TCP)
lwip (very promising, but not easy to get running)
ipstack v1.2.2 by Diego De Marco (should have tried that earlier, it's my current choice)
So, with ipstack I now already can do DNS lookups and DHCP configuration in NDN.
I am having little problems getting the TCP code working, but I will get there. :)
TCP is what I need to implement NDNs FTP.
As a side effect, while facing some severe problems with the above process and the VP compiler,
there is now even a new VP release on the horizon - thank you Allan Mertner.
And I did quite some internal source code changes that I wanted to do long time ago.
I hope I can get all that working within the next 2 weeks.
Probably all W32/LNX users will think: WTF! Nothing else?
Yes, the next release will mainly focus on the above feature/issue.
It will remove quite some lines from my todo list.
And, I will do some FTP updates while I am at it.
But, fear not, I have to go to the hospital tomorrow and stay there for about 3 days without
internet connection, but with my notebook.
So, I maybe will be able to work on some issues not connected to the above.
Besides that I probably have to stay at home for about another 2 weeks which
should give me plenty of time for some more news or fixes.
Ok, I have to get ready and do some more preparations for tomorrow morning.
The past few days have been quite busy...
I hopefully forgot nothing important.
So, all the best and see you soon,
Stefan / AH
-
Hi Dan
thanks for this.
But, I am already busy enough with pages I have to update and care for here and there. :P
You are welcome to keep the page in your posession.
Let's see what happens, as it appears to be a pretty new service?!
I have linked to the page from the NDN HP.
All the best,
Stefan / AH
-
Hi!
It is true: NDN moves/renames every file separately.
Todo list:
* COPY/MOVE: moving dirs which exists on same drive: reads and writes all data
-> directories can be moved completely with files
-> should del file, and quick rename
But to be honest, I don't know how that could be *easily* fixed without messing the already
messed up copy code up even more. I would have to mark directories that can be moved
completely without the need of accessing each file inside of the directory and move these
separately.
On my todo list is already this:
! rewrite copy (FTP etc....)
This not only concerns the poblem above and the 2GB limit, but also the local disk only limitation of the current
implementation. I want all existing and future VFS also to be compatible with a new
copy/move code.
I am not sure if I should spend more time on the old code.
"OS-dependent disk access" is always on, this seems to be an old remain from
the old D32 direct disk access operations.
All disk operations of course are OS dependent right now.
As it is no real flaw I don't think this is of top priority,
especially because I am afraid of touching the copy code at the moment.
Hope this at least explains the current situation,
Stefan / AH
-
Hi everyone!
First of all (for those who are concerned):
I wish you all a happy new year and all the best for 2009!
Thank you all for your support and let's hope for good progress in 2009. :)
As you can tell from the release version there's nothing big in this release.
Additionally, I will be on holidays and away from any computer for the next 2 weeks.
So don't expect too much for the next release in 1 month. :)
Btw, thanks to Igor Kozin, I found that the PayPal donate button was gone. :P
I have readded it to the menu sidebar on the left side of the homepage!
@Garl:
Sorry mate, I once again was not able to add your code.
This will be the first thing I do when working on the next version!!!
Whatsnew:
─════┤ v2.31.2699 DPMI32/WINDOWS/LINUX 03.01.09 ├═══════════════════════════─ EDITOR [-] Block sort including the last line added a new line to the EOF [NC] (Slavik) -> micro_4.EdSortBlock(): not really a bug but an algorithm problem; lines are now directly accessed without deleting them from the file and reinsertion, which should be a little faster also [+] Block sort now also accepts horiz. blocks -> micro_4.EdSortBlock() now handles horizontal blocks [*] DeleteLine [CTRL-Y] didn't remove the last line but cleared it -> micro_1.EdDeleteLine() now handles the last line of file like all other lines [+] click on line number marks the line -> modified micro_3.EdHandleMouse() TURBOVISION: VIEWS/DIALOGS/MENUS/OBJECTS/MESSAGES [*] collect.TCollection.AtDelete() returns the deleted item pointer [*] replaced ForEach() usage with (First|Last)That() for a performance improvement on certain commands in: dnapp.(GlobalMessage|GlobalEvent|ViewPresent)() MOUSE [*] Event drivers.evMouseUp returns the last pressed buttons -> modified drivers.GetKeyMouseEvent() VIRTUAL FILE SYSTEMS (VFS) [-] FTP: no reread of FTP servers in drive:dir root path (C:/...) [A] -> fileio.RemovePathSep() didn't remove / of paths <= 3; added fileio.RemovePathSepX() which contains linux and windows code, switchable by a input variable [-] TEMP: drive did not reread [A] -> added vfs_find.pas.TTempDrive.Contains() FILE PANEL [-] UUEncoder: always mime output generated (Rugxulo) [A] -> uucode.UuEncode().DoIt() contained debug code, which always forced MIME output [-] Changing drive via driveline/mouse, modified the current panel even if now drive/dir change took place (Slavik) [A] -> flpanelx.TFilePanelRoot.CommandHandle()._ChangeDrv() checks for a directory change before making any changes [-] Drive selection [ALT-F1/F2]: right side, reread, dialog moves to the left [A] -> filescol.SelectDrive() didn't preserve the X and Y input values for reread [+] Show user screen with mouse (Eugeniusz Kosek): left click on position 0:0 on screen shows the user screen [ESC] -> modified dnapp.TProgram.GetEvent() to send [ALT-F5] on LMB [-] Maximized panels allowed hide/show of inactive panel (Goplat) [NC] -> dblwnd.TDoubleWindow.HandleCommand() checks for maximized windows before changing the inactive window [-] Bad display of column titles if the length of the title is smaller or equal to the width of the column (Goplat) [NC] -> stringsx.CenterStr1() always expected the string to be inserted < than the string to be inserted into -> vfs_driv.TDrive.MakeTop() didn't handle column sizes of 1 correctly FILE COPY/MOVE/OPEN/CREATE/DELETE [*] DELETE: now also directories are unselected when deleted -> improved eraser.EraseFiles() root erase code [-] COPY/MOVE: Display correct language in window title (Garl) [A] -> modified FilesCopy().MakeDirectories().CopyF() [-] DELETE: * ignore directory deletion errors (continue button) [NC] * better error feedback -> added eraser.EraseFiles().HandleSysError(), which uses drivers5.SystemError() (has ignore and retry buttons) and is now also used for directories -> fixed drivers5.SystemError(): ignoring all errors, and then selecting retry on a later error ignore the retry selection -> improved drivers5.SystemError(): uses OS resources for error display, added commands.ossaNewSysErrors and Options.Configuration.System Setup.New System Errors (now default), possible to show lower window to check what caused the error (CTRL-O, ALT-F5, ALT, CTRL, RIGHT MOUSE BUTTON, LEFT MOUSE BUTTON at 0,0) Screen grabber (ALT-SHIFT-INS) -> added System error help (hcSysErrors), dnutil.TDnApplication.HandleCommand().cmHelp can also take help contexts via the Message() command -> LNX: added libc.strerror() usage to the VP RTL (OS_SYS_ERRORS) ARCHIVES [-] RAR: correctly show large (>2GB) files inside archive [DNC] -> improved naming of several RAR data defined in NDN according to the latest unrar C source 3.80.0 / 16.09.2008 -> archiver.TFInfo.(P|U)Size was extended to 64-bit, handled in vfs_arcv.TArcDrive.ReadArchive() and vfs_find.FindFiles() -> arc_rar.TRARArchive.GetFile() now correctly handles the optional size data before the filenames [-] extracting multiple files with "" didn't work [A] -> archiver.UnarchiveFiles() now handles ""
Homepage: http://ndn.muxe.com/
Download: http://ndn.muxe.com/download/
Have fun,
Stefan / AH
-
Hi!
Put to the todo list.
PLease note that I plan on rewriting the copy code for a long time already.
All the changes (except for +2GB support) will be on hold until I start this.
All the best,
Stefan / AH
PS: I added the copying fix...
-
Hi!
I have found and uploaded 2 different NDN addition archives.
One is from 1999, the other one from 2004.
I hope these contain the lost data.
Stefan / AH
-
Hi!
I just realized that the Linux ELF executable is not working, due to a conversion error from PE -> ELF.
I will upload a fixed version when I am home from work.
Sorry for this,
Stefan / AH
EDIT: Linux archive has been updated and should work now!
-
Hi!
Sorry, I don't want to set myself a time limit.
Unfortunately I did that already with the 2GB+ file support. :P
Bye,
Stefan / AH
[request] Lastaccess/lastwrite Columns
in NDN BETA
Posted · Report reply
Hi!
This sounds ok on first read, but I can only find out if this is "future" proof when I
actually start working on this...
But even worse, it's not compatible to existing configurations:
- we can not change any of the currently used character combinations because
it will break all user's configurations
- the remaining 14 characters are probably future proof, they just don't
match their meaning anymore:
T = Time, D = Date
c = Creation Time, X = Creation Date
So yes, we can use case sensitivity here, if we don't change the existing combinations.
If I have to think more about this I must start implementing it right away,
and I don't want to do that right now, since there are more important things to do.
No problem, if you want the sources email me.
I will send you the sources from the next release (I have already changed too much
files for the nexzt release).
There are a few other todo's that need to be done concerning the column handling...
Even if it's easy to implement (it is), I must carefully test it etc, even if you do the actual coding.
I have to update the help etc.
And, when I merge in your code I probably will find this or that detail that needs to be
touched too then.
So, it will be quite some work for me anyway.
Please note what I wrote here:
http://forums.muxe.com/index.php?showtopic=3226
Maybe this will be added with the next release...
Stefan / AH