China DOS Union

Originally posted by namejm at 2007-1-20 04:18 PM:

Originally posted by pengfei at 2007-1-20 15:22:
2. When browsing posts in the prompt interface, if you want to copy good content, using the mouse to operate in the prompt interface will make the DOS prompt unresponsive.

　　Although it appears to be a character interface, it is actually simulated using a graphical interface. Essentially, this is still a web interface. You can position the mouse over the command prompt.

This problem itself is quite good. To better achieve the simulation, I have now added that when the command prompt loses focus, pressing any key (except Ctrl/Alt combination keys and keyboard indicator keys to allow special function keys like Ctrl+A/Ctrl+C/Ctrl+V for editing and other operations) will automatically restore the focus of the command prompt, and the effect is usually the same as pressing the key without losing focus before.

------

Originally posted by qzwqzw at 2007-1-20 04:34 PM:
The word "贴子" frequently appears in the command line prompt.
Actually, it should be "帖子".
We often mix up the two words "转帖" and "转贴".
Although the two words have the same meaning, it does not mean that the two characters have the same meaning.
Because reposting can...

I have changed all "贴" characters to "帖" characters.

Now the /A and /V switches of DIR have been officially added with various options! The currently supported options include:

/A switch options:
A Attachment C Close/Lock D Drive/Directory
F Normal file G Essence H Hot
L Highlight P Vote T Sticky

/V switch options:
D Date/Time I ID P Poster/Moderator
R Record S Name/Title T Type

For example:

DIR /A:HT will display all hot posts or sticky posts
DIR /A /VDIRTS will display all posts and show their date/time, type, ID, reply/view count, name/title.

If these options are not added, it means all items are displayed, the same as the previous version's function. The option letters come from their official English names, and the colon between the switch and the option can be present or absent. Additionally, the /C switch has been added to display the creation date/time, and now the type of the DIR command will display hot posts and posts with attachments.

The new dir modification is quite good, only the following problems are reported:

1. When the dir item is a directory or board area, it will only display. one directory.
2. The option T (type) of /V is suggested to be changed to A (attribute). The two concepts are combined into one later, which is more convenient for understanding. Moreover, according to my understanding, the types are mutually exclusive and single-choice, and the attributes are compatible and multi-choice.
3. The option F (ordinary file) of /A is suggested to be modified to N (ordinary) or canceled. Understand from the perspective of "attribute". A file without any attributes is an ordinary file. For example, in CMD, a file without AHSR attributes is an ordinary file. But for the convenience of filtering, an ordinary attribute needs a mark. But at this time, it is using "ordinary" as an attribute, not using "ordinary file" as an attribute.
4. The compatibility of file attributes brings a problem of layout space. A file can have at most the following 7 attributes: A (attachment)/C (closed)/G (essence)/H (popular)/L (highlight)/P (vote)/T (sticky). Obviously, there is not enough space reserved in the attribute column of dir output to display all the attribute identification characters.

-----------------------------------------------------

It is suggested to load autoexec.bat immediately after net logon in the command line interface.

-----------------------------------------------------

When using Opera, it is found that the buffer width increases, and it can be fully displayed when zoomed to 50%, while using IE is still the original width.

-----------------------------------------------------

The edit editor exits with Ctrl+C, resulting in an exit prompt when copying text according to the habit of using Ctrl+C. And when the input method is turned on, it is very troublesome to press the C key to cancel. And the current temporary way for me to copy text is: select - Ctrl+X - Ctrl+V - move to the new location - Ctrl+V. It is very troublesome. In addition, Ctrl+C is often used for abnormal termination. It is suggested to change the exit to Ctrl+Z or Ctrl+Q.

Originally posted by qzwqzw at 2007-1-22 11:43 AM:
The new dir modification is quite good, only the following issues are reported

1. When the dir item is a directory or board area, it will only display the . as a directory

2. The option T (type) for /V is suggested to be changed to A (attribute)

The following two concepts are combined ...

The problem that the DIR displays only . when showing a directory was a typo from the last time, and it has been corrected.

All "types" in DIR have been changed to "attributes", and F in /A has been changed to N, which is normal.

Regarding the layout issue. When using code page 437, each attribute will be represented by a letter (consistent with the /A option), and when using code page 936, each attribute will be a Chinese character. The current approach is that if it exceeds the width, the exceeded part will be automatically truncated. However, since there are almost no files with so many attributes at the same time, this situation usually does not occur. On the contrary, most files have no attributes. If more positions are left by default, it may cause more screen space to be tight.

Regarding net logon, sometimes autoexec.bat has already run once, and the user just logs out and logs in again temporarily, and may not necessarily want to run it again. If you really want to run it, it is recommended to directly enter cmd/p, so that the autoexec.bat file will run automatically again.

I didn't find that the Opera buffer increased. Maybe it's due to the font or version? My Opera is version 9.10.

Regarding Ctrl+C under EDIT, in fact, I have thought about this for a long time. Originally, you can exit by pressing the ESC key directly, which is fine in browsers such as IE, Firefox, Opera, etc., but some people use the Maxthon browser which has a bug that is, the ESC key is not recognized in the web page, so I had to allow adding another key that can achieve the same effect as a backup. For the paged display of MORE or DIR/P commands, pressing ESC, Q, Ctrl+C keys can all interrupt. But in EDIT, the Q key obviously cannot be used as the exit key, otherwise you can't enter this letter. Ctrl+Z and Ctrl+Q and other keys were originally good, but they are also special keys. For example, Ctrl+Z can be used for undo, and it cannot be directly controlled on some browsers, so I had to use the Ctrl+C key. However, it is also the same as the copy operation key, causing some troubles. I have to decide to handle it like this temporarily: when BREAK is ON, allow pressing Ctrl+C key to exit, to take care of the Maxthon browser; when BREAK is OFF, cannot press Ctrl+C key to exit, to facilitate copy operation. If you need to perform copy operations frequently, it is recommended to add a line of BREAK OFF in AUTOEXEC.BAT. This may be a solution.

Problems with the screen buffer

I have encountered it in both Opera 9.01 and Opera 9.10

But strangely, it's not every time like this

This should be related to Opera

I'll wait until I observe the pattern

--------------------------------------------

Recalling

The command-line interface has actually done too much work to be compatible with browsers

Added Ctrl+C

Forcibly added </code> code at the end of the post

Modified full-width spaces, etc.

Now there's also the problem that the Quote block in Opera is centered by default

But I actually think

It's not worth it to affect the simplicity of the code for the sake of being compatible with non-mainstream browsers

Let's put this problem aside for now

---------------------------------------------

I'll handle the net logon issue according to your opinion

---------------------------------------------

Just now I found that the output of dir a: has a slight adjustment

It seems you are worrying about the coexistence output of drives and files

I think it's better to put autoexec.bat into the default forum

On one hand, it solves many troubles of coexistence output

On the other hand, it also lays the foundation for future functional expansion

There are approximately two directions for expansion

One is that it can support more scripts

In addition to the script at startup

It can also include scripts executed manually, and scripts triggered by events

The other direction is user functions

Short messages, my topics, topic subscriptions, editing personal information, etc. are all relatively practical functions

It is suggested to include them in the development schedule as soon as possible

Now the quoted part is only the outer frame without the colored display, so centering it might be more eye-catching and consistent with the GUI interface.

The default forum (that is, drive B) is actually a special section, which is the original section of all Discuz! forums (hence the name default forum). It can also store topics, posts, etc. However, most forums have created other sections later and left this one empty. In other words, essentially the default forum is still a normal section, so it is not appropriate to use it to place AUTOEXEC.BAT. Moreover, it seems that a normal computer cannot boot from drive B (the boot disk can only be drive A or C), so B:\AUTOEXEC.BAT cannot be automatically executed when booting. The current AUTOEXEC.BAT is made by expanding the existing data table. If more custom scripts need to be supported, expanding the existing data table is not enough, and a new data table needs to be added. There are no commands related to reading private messages under DOS and CMD, so I haven't thought about what command and form to use for operation yet (under Unix, there are commands like WRITE to read and write messages, but it doesn't seem to be a DOS/CMD command).

M$ also has Exchange for DOS, and there is also M$ Mail (MAIL.EXE). In fact, it's not impossible to port the mail/uucp commands from *nix.

[ Last edited by Roy on 2007-1-23 at 05:53 AM ]

Sending private messages can use net send or others

reading private messages?

treating emails as files - display with dir list/type

just to reduce the complexity of development

maybe it would be better to split into two relatively independent file systems

for example, allocate one or two drives specifically for the private message box

---------------------------------------------------

as for free scripts

not very clear about the so-called extension table and new table

but according to my understanding

treating them all as a common file for processing

it seems that a unified data table structure can be used to implement

---------------------------------------------------

Roy has appeared

does it mean that the traditional Chinese version of 950 is also worth looking forward to?

Originally posted by qzwqzw at 2007-1-23 11:38 AM:
You can use net send or others to send private messages.

To read private messages?

Treat emails as files - list with dir / display with type.

Just to reduce the complexity of development.
Probably split into two relatively independent...

I also considered net send, but it doesn't seem quite suitable. Because the private messages in the forum have both a subject and content, and the content can be several paragraphs, just like a post. But using net send on the command line can only send very simple text, which is not very practical. More importantly, net send is just an independent function, only for sending but not receiving. It always feels incomplete. Even if we use special means to list with the DIR command, it still feels a bit awkward because these two functions seem unrelated, lacking consistency and a unified operation interface.

When I saw Roy mentioned MS Mail and the MAIL command in Unix above, I had an idea. Let's see if it's feasible:

MAIL: Display the inbox situation and unread messages.
MAIL ALL: Display all messages in the inbox, including unread and read ones.
MAIL : Display the message content.
MAIL TO xxx: Send a message to xxx, where xxx can be multiple people, separated by commas.

My original idea was

To use file commands to manage emails as files

Email commands are only used to implement sending and receiving

There are possibilities for implementation in drafts/editing/categorizing/filtering/ignoring

-----------------------------------------------------------

But that's okay

Anyway, there is no standard for email sending and receiving in CMD

You can set it however you want

What is done first may become a de facto standard

And my idea is to spread the scope a bit

A short message system doesn't need to be made into an email system

---------------------------------------------------------------

In this case

User profiles/subscription to topics probably need new commands to be added

Of course, I have another plan, which is to enhance the NET command. In addition to supporting sending short messages with the NET SEND command, a new NET RECEIVE command is added to view unread short messages. Using NET RECEIVE [number] can display the content of the short message. In addition, we can also consider adding NET SESSION to display the list of online users. I don't know which plan is more appropriate.

Since they are all newly added commands, naturally, judge according to your own needs. The mail is good for its simplicity (I once considered using pm). And I prefer a command to implement a relatively independent function only. I don't have much liking for integrated commands like for/if/set/net. The user list is suggested to use net view or net user. Of course, it still needs to be considered as a whole according to your future development plans.

I see that there are at least three schemes for the implementation of the private message system now. I'll summarize the advantages and disadvantages of each scheme:

Scheme 1: Use NET SEND to send messages, and treat the messages as files to view with the DIR command.
Advantages: Simulates the SEND option of the NET command in DOS/CMD, and realizes a unified reading platform for messages and posts.
Disadvantages: The methods of sending messages and reading messages are independent of each other, lacking consistency. Although it's good to realize the unity of messages and posts, it may also ignore some problems, and it's relatively troublesome to implement. When both are treated as a file system, all existing file-related commands (such as CD, DIR, TYPE, EDIT, FIND, etc.) also need to be modified to fully support the new file system (equivalent to loading programs like NTFSDOS under DOS, and these programs need to provide file operation interfaces for drives like NTFS that DOS can't directly recognize).

Scheme 2: Add a MAIL command to specifically handle private messages.
Advantages: Simple and flexible, easy to operate, and relatively complete in functions.
Disadvantages: Not a usual existing command in DOS/CMD, equivalent to using a new command to handle an independent system.

Scheme 3: Use NET SEND to send messages, and add a RECEIVE option to the NET command to view messages.
Advantages: Utilizes the NET command under DOS/CMD for operation, and is enhanced to meet actual needs, as well as maintains the consistency of private message operations.
Disadvantages: As an integrated command, it may not be as simple and flexible as a separate command.

The above is for reference to facilitate judgment.

Originally posted by qzwqzw at 2007-1-23 11:38:
Roy has appeared

Does it mean that the traditional Chinese version of 950 is also worth looking forward to?

Now we need to separate the language from the main system first to reduce the amount of data to be transmitted before I can add CP950...
I will start working on it this weekend at the earliest... Let's see the situation ;)

Now it officially supports the function of sending and receiving short messages!

Regarding the final implementation method, I have thought about it for a long time. Among them, the rationality of the first scheme proposed by qzwqzw is still relatively good. The main reason is that I originally considered that the content was relatively complex and the time was tight, so it might be difficult to implement for a while. However, in the end, it was decided to use this scheme to implement sending and receiving short messages.

Now the inbox will be used as drive G (that is, the next one after the original last drive). The short messages in it are completely consistent with the management form of the posts in each section. You can use commands like DIR, TYPE to list, view and other operations on it. <New> means new messages, which can be filtered using the switches of DIR, just like the posts. However, the FIND command currently does not support finding the content in this drive (will give a prompt).

To send a short message, you can use the form of the NET SEND command. For example, NET SEND a,b will send to two users a and b, and then the system will automatically prompt to enter the title and content.