AngelsHolocaust

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

Which I won't use anyway, maybe I will merge some code but that's it. :) 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. 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. 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. 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

But it might behave differently than what NDN requires, hence RTL modifications for NDN would maybe be required too. 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. What 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? I don't agree on the assembler statement, but don't let us start a discussion on that. ;) FP DOS == OS/2: Why should newer FP releases suddenly break/lose the OS/2 support? 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. I personally would have no problem with a maintenance mode, except for the possibility to add new compiler targets. 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! 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. 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. 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: So, I guess there's no problem to add options to both of the selection dialogs. We should also not limit ourselves to the FIND VFS only. Does that sound ok? Stefan / AH

Hi! No problem. 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! 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... 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? http://forums.muxe.com/index.php?showtopic=3226

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? 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. 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. http://ndn.muxe.com/download/ Stefan / AH

Hi! Not much to say, except that I am late again. :) Whatsnew: ─════┤ v2.31.2305 DPMI32/WINDOWS/LINUX 23.11.08 ├═══════════════════════════─ [*] renamed readme.1st to readmeen.1st, added russian translation readmeru.1st {G} [*] updated the russian dialog translation {G} [-] system.Float2Str() added a leading space in case of positive numbers [V] [*] improved *.dnr in ndn.hgl: added BracketPairs TVHC / HELP [*] RegEx: fixed some layout/spacing errors KEYBOARD [-] W32: locking the current windows session and returning to NDN didn't reset/update the shift keys, although not pressed anymore -> resetting vpkbdw32.ShiftState on FOCUS_EVENT DBF VIEWER [-] correct show in not odd Quote's '"' count {G} RCP / RESOURCES [*] modified statuslines of several dialogs (mostly english only, if required): removed "10Menu" (Slavik), cm(Next|Prev)*, cmQuit added " 4Close", " 5Resize", " 5UsrScr", "12ScrSav", F11/F12 removed all ~F?~ (english) -> modified language resources, filescol.SelectDrive().EventCallbackHandler() -> Resources: numbers of first StatusDef 1, 1 were renamed to hcDragging -> updated help on some missing hotkeys CALCULATOR [-] octal number parsing didn't work [A] -> calc.GetValue().GetValueBase().CheckString() checked for base 7 not 8 COLORS / PALETTES [+] added apometrn.pal (Rodrigo Cesar) EDITOR [*] rearranged the editor menu: added Search.Bookmarks and Misc.Goto [*] Line duplication: partially marked line didn't duplicate anything [A] -> modified microed6.EditorHandleEvent().cmDuplicateLine [+] find previous/next number: [CTRL-ALT-LEFT/RIGHT] -> added stringsx.FindWord(), used in micro_1.EdWord(Left|Right)() and micro_1.EdFindNumber() -> added commands.cmNumber(Left|Right), macro commands Number(Left|Right) -> find prev/next paragraph now uses [CTRL-ALT-UP/DOWN], modified microed6.EditorHandleEvent() [*] "Find previous" paragraph now behaves like "Find previous word": if inside a paragraph that paragraph will be found -> changed the behaviour of micro_3.FindParagraph().fpPrevious if inside a paragraph [+] added a "Swap paragraphs" operation -> added commands.cmSwapParagraphs, hotkey [ALT-F9], menu entry Misc.Swap.Paragraphs, macro command 'SwapParagraphs' -> modified microed6.EditorHandleEvent(), micro_3.EdSwapCode() [-] files loaded on startup always set BlockVisible to TRUE [DNC] -> now checks microed.TFileEditor.Mark, modified microed.TFileEditor.Awaken() -> modified microed6.HandleEvent().cmDuplicateLine by adding micro_1.EdBlockOff() [-] unident by DEL stored wrong undo information: always only one char [A] -> micro_4.EdMakeDel() now uses udSubDel instead of udDelChar VIRTUAL FILE SYSTEMS (VFS) [-] FTP: crash while login on ftp://ru54.com [A] (Diman88) -> vfs_ftp.TFTPConnected.GetResponse() didn't handle "bad" replies like empty strings, therefore added checks for string length -> improved FTP error output in vfs_ftp.TFTPConnected.Error() by using vpsyslow.SysGetSystemError() [-] FTP: Changing directories via "cd" didn't reread the directory content, several commandline commands didn't reread data in multiple open connections [A] -> vfs_ftp.TFTPConnected.HandleCmdLine() didn't provide a directory pointer with the command cmRereadDir, now complete URL information -> flpanelx.TFilePanelRoot.CommandHandle()._DoRereadDir() uses vfs_driv.TDrive.CurDir if no directory is provided explicitly -> vfs_ftp.TFTPConnected.Contains() prepended a '/' to dir comparisons and allowed directory match only even if host was provided (every FTP has / or /pub) [*] removed several functions identical to vfs_driv.TDrive.RereadDirectory() from: vfs_arcv.TArcDrive, vfs_ftp.(TFTPConnected|TFTPDrive), [-] FTP: vfs_ftp.TFTPConnected functions reread all FTP drives: [A] CopyFilesInto(), MakeDir(), EraseFiles() -> added vfs_ftp.TFTPConnected.RereadFtp(), used in functions above [-] FTP: CopyingTo, 2*same FTP opened, file copied to last panel, not first [A] -> dnapp.GlobalMessage() overwrote the very first (topmost) match, with following matches, therefore pointing to the last match (FTP drive); now always returns the very first match COMMANDLINE [-] changing into a network dir (z:\) gave a bad dir display (Crimso) [A] -> lfn.lGetDir() did not upcase drive chars when looking into CurrentPaths Download: http://ndn.muxe.com/download/ All the best, 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!