I gone through many questions here and in the other website I still having following questions .
I am implementing a simple system call ,for this the files I have changed as follows
1. /arch/x86/kernel/syscal_table_32_S
2. /include/asm-x86/unistd_32.h
3. /include/linux/syscalls.h
I have doubt in the 2nd file because this ,I am not sure this file(/include/asm-x86/unistd_32.h) to modify or any other file ,as I know the file which containing the system calls number,We have to add our sys call and the last number + 1 ,the doubt here is this file(/include/asm-x86/unistd_32.h) doesn't contain the limit line (#define NR_syscalls <last syscall no + 1>) but there is another file (/include/asm-sh/unistd_32.h),which contain the syscall numbers and also the limit line.
So ,kindly tell me which files to modify with a simple example.
I implemented new syscalls on the linux-kernel 3.2 and modified following files:
1. /arch/x86/kernel/syscal_table_32.S
2. /arch/x86/kernel/syscal_table_64.S
3. /arch/x86/include/asm/unistd_32.h - contains NR_syscalls for ia32
4. /arch/x86/include/asm/unistd_64.h
5. /arch/x86/include/asm/<new_file_with_syscall>
6. /arch/x86/include/asm/Makefile
The syscall itself I called with syscall(NUMBER_OF_SYSCALL) function.
Related
in the doc, they have mentioned that nNumberOfLinks is "The number of links to this file. For the FAT file system, this member is always 1. For the NTFS file system, it can be more than 1."
The number of links to the file means what ? if that file used as the destination of 3 symlinks then nNumberOfLinks is 3 . or it has some other meaning.
Looking into the implementation of GetFileInformationByHandle in the ReactOS source code,
https://doxygen.reactos.org/da/d02/dll_2win32_2kernel32_2client_2file_2fileinfo_8c_source.html We can see the field nNumberOfLinks gets populated as follows (error checking removed).
errCode = NtQueryInformationFile(hFile,
&IoStatusBlock,
&FileStandard,
sizeof(FILE_STANDARD_INFORMATION),
FileStandardInformation);
lpFileInformation->nNumberOfLinks = FileStandard.NumberOfLinks;
As per the documentation of FILE_STANDARD_INFORMATION https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_file_standard_information.
NumberOfLinks
The number of hard links to the file.
So nNumberOfLinks will be the number of hard links, as mentioned by dxiv in the comments.
I am trying to take over some projects involving DEC BASIC, A.K.A. VAX BASIC, A.K.A. Alpha BASIC. I am really hoping to run into someone with experience here. I have been through the user manual for VAX/Alpha BASIC through and though but I can't figure out how to debug shareable code.
I can create, compile and link shareable code, I can debug the code that references the shareable code, but I can't debug the shareable code. Any help would be greatly appreciated.
The commands I am using to compile and link are:
$ BASIC/DEBUG/NOOPTIMIZE COMPARE_DATES_TEST.BAS,COMPARE_DATES.BAS
$ LINK/SHAREABLE/DEBUG COMPARE_DATES.OBJ,COMPARE_DATES_SUB/OPT
$ LINK/DEBUG COMPARE_DATES_TEST,COMPARE_DATES_MAIN/OPT
$ RUN COMPARE_DATES_TEST
The contents of the two option files are:
$ type COMPARE_DATES_SUB.OPT
! COMPARE_DATES_SUB.OPT
SYMBOL_VECTOR=(COMPARE_DATES=PROCEDURE)
$ type COMPARE_DATES_MAIN.OPT
! COMPARE_DATES_MAIN.OPT
COMPARE_DATES/SHAREABLE
My shareable code has a bug, but I don't know where, the debugger reports:
— SRC: module COMPARE_DATES_TEST$MAIN -scroll-source————————————————————————————
1: EXTERNAL INTEGER FUNCTION COMPARE_DATES(STRING,STRING)
2: DECLARE STRING A$, B$
3: A$ = "01-APR-18"
4: B$ = "15-MAY-2017"
5:
-> 6: PRINT COMPARE_DATES(A$, B$)
7: END
— OUT -output———————————————————————————————————————————————————————————————————
stepped to COMPARE_DATES_TEST$MAIN\COMPARE_DATES_TEST$MAIN\%LINE 3
stepped to COMPARE_DATES_TEST$MAIN\COMPARE_DATES_TEST$MAIN\%LINE 4
stepped to COMPARE_DATES_TEST$MAIN\COMPARE_DATES_TEST$MAIN\%LINE 6
%BAS-F-SUBOUTRAN, Subscript out of range
-BAS-I-FROFUN, In external function COMPARE_DATES
-BAS-I-FROMOD, In module COMPARE_DATES_TEST
break on unhandled exception preceding 18446744071563830960
— PROMPT -error-program-prompt——————————————————————————————————————————————————
%DEBUG-I-SOURCESCOPE, source lines not available for %PC in scope number 0
Displaying source for 6\%PC
DBG>
Too long for a comment: You compiled with /NOOPTIMIZE, so I would have expected that a STEP/INTO when at line 6, PRINT COMPARE_DATES(A$, B$), would have stepped to COMPARE_DATES in your shareable image. I don't know why that's not the case, here. The debugger is right, you don't have the sources for DEC$BASRTL. Your shareable image is not installed, it is in your address space. It seems PRINT has problems with the passed argument. I would try a SET IMAGE COMPARE_DATES; SET MODULE/ALL; SET BREAK COMPARE_DATES at the initial debugger prompt. That makes all debug symbols of the shareable image known and sets a breakpoint in your function. And then a GO should get you into your function. (I noticed, that you have the same names for the function, the source module and the shareable image. This shouldn't be a problem.)
I have a Fortran 77 code like this, more or less:
nMaxRow=100
nMaxStep=100
! initialization of the matrix if Step=1
do step=1,nMaxStep
if (step.eq.1) then
do ii=1,nMaxRow
do jj=1,nMaxStep
A(ii,jj)=0
end do
end do
end if
!now for each step and for each row update the cell of the matrix
do ii=1,nMaxRow
A(ii,step)=X(ii) !X(ii) is a number associated with the specific ow at that specific step
end do
!Now I want to write the updated matrix at this step into a text file,
!How can I do that????
end do !close the do step...
Is it possible to update the values of the matrix and write the updated matrix at that specific step into a text file? I mean, without appending the results each step...
I found out that for Fortran 90 the 'REPLACE' command exists... but I couldn't find anything similar for Fortran 77.
One simple idea would be deleting the file just before writing a new one... but I don't like it and I don't know how to do it anyway.
If the file is already open (from the previous writing), you can just go the the start of the file using
rewind(unitnumber)
and start writing again. It will delete the original content of the file and start again. If you wan't to go back just be several records, you can use backtrace(), but you probably don't want that here.
If it isn't open, just open it and start writing. Unless you open it of appending, it will overwrite the original content.
I am trying to write a multi stage boot loader using NASM and gcc.
For this purpose I am referring grub boot loader source.
I have written a stage1 loader, but stuck at over writing partition
tables of MBR.
In grub stage1.S, they are using code like this to skip partition tables:
. = _start + STAGE1_PARTEND
.word STAGE1_SIGNATURE
How can I do that in NASM?.
using times it will over write the partition tables.
So please help me.
Assigning a value to . is treated the same as a .org directive (see this page).
Thus, the code you pasted is changing the current origin to _start + STAGE1_PARTEND and placing a word with the value STAGE1_SIGNATURE there.
So in NASM code you should be able to do something like:
fill: times _start+STAGE1_PARTEND-$ db 0
dw STAGE1_SIGNATURE
; .word is 16 bits on x86 (regardless of .code16 / .code64)
Also see this example in the NASM manual showing how to pad a BIOS boot sector this way, as a replacement for MASM-style org or GAS-style . = new_position actually seeking and filling with padding in a flat binary output file.
times STAGE1_PARTEND-($-_start) db 0
dw STAGE1_SIGNATURE
Right, Nasm will accept only one "org" directive. The Nasm equivalent of "." is "$", but I don't think that'll help you either. I don't have the GRUB code on hand, or I'd look. Where does the partition table "come from"? If it's read from disk, there may be a signature already in place(?). Perhaps you can simply "stop" the Nasm code before overwriting the partition table and leave the existing sig in place? Nasm will do almost "anything you want", but this may be an exception. It won't "move" (skip) and assemble more at a new place as (G)as is apparently doing here - at least not readily. I may need to download the GRUB code to figure out a workaround. Possibly something like...
; stage1 code
; possible padding here?
%incbin "partition_table.bin"
dw (SIG) ; if not part of the .bin code?
... or something.
I have a folder with these files:
alongfilename1.txt <--- created first
alongfilename3.txt <--- created second
When I run DIR /x in command prompt, I see these short names assigned:
ALONGF~1.TXT alongfilename1.txt
ALONGF~2.TXT alongfilename3.txt
Now, if I add another file:
alongfilename1.txt
alongfilename2.txt <--- created third
alongfilename3.txt
I see this:
ALONGF~1.TXT alongfilename1.txt
ALONGF~3.TXT alongfilename2.txt
ALONGF~2.TXT alongfilename3.txt
Fine. It seems to be assigning the "~#" according to the date/time that I created the file. Is this correct?
Now, if I delete "alongfilename1.txt", the other two files keep their short names.
ALONGF~3.TXT alongfilename2.txt
ALONGF~2.TXT alongfilename3.txt
When will that ID (in this case, ~1) be released for use in another shortname. Will it ever?
Also, is it possible that a file on my machine has a short name of X, whereas the same file has a short name of Y on another machine? I'm particularly concerned for installations whose custom actions utilize DOS short names.
Thanks, guys.
If I were you, I would never rely on any version of any file system driver (be it Microsoft's, be it another OS's) to be consistent about the algorithm it uses to generate short file names. The exact behavior of the Microsoft Fastfat and NTFS drivers is not "officially" documented (except as somewhat high level overviews) thus are not part of the API contract. What works today might not work tomorrow if you update the driver.
In addition, there is absolutely no requirement that short names contain tilde characters - see for example this post by Raymond Chen.
There's a treasure trove of info to be found about this topic in the MSDN blogs - for example:
Registry key to force Windows to use short filenames
NTFS curiosities (Part I): Short file names
Also, do not rely on the sole presence of alphanumerical characters. Look at the Linux VFAT driver which says, for example, that any combination of uppercase letters, digits, and the following characters is valid: $ % ' ` - # { } ~ ! # ( ) & _ ^. NTFS will operate in compatibility mode with that...
The short filename is created with the file. The algorithm works like this (usually, but see moocha's reply):
counter = 1
stripped_filename = strip_dots(strip_non_ascii_characters(filename))
shortfn = first_6_characters(stripped_filename)
while (file_exists(shortfn + "~" + counter + "." + extension)) {
increment counter by 1
if more digits are added to counter, shorten shortfn by 1
/* e.g. if counter comes to 9 and shortf~9.txt is taken. try short~10.txt next */
}
This means that once the file is created, it will keep its short name until it's deleted.
As soon as the file is deleted, the short name may be used again.
If you move the file somewhere else, it may get a new short name (e.g. you're moving c:\somefilewithlongname.txt ("c:\somefi~1.txt") to d:\stuff\somefilewithlongname.txt, if there's d:\stuff\somefileelse.txt ("d:\stuff\somefi~1.txt"), the short name of the moved file will be somefi~2.txt). It seems that the short name is only persistent within a given directory on a given machine.
So: the short filenames will be generated by the filesystem, usually by the method outlined above. It is better to assume that short filenames are not persistent, as c:\longfi~1.txt on one machine might be "c:\longfilename.txt", whereas on another it might be "c:\longfish_story.txt"; also, when a file is deleted, the short name is immediately available again.
I believe MSDOS stores the association between the long and the short name in a per directory file.
It does not depends on the date/time.
If you move your files in a new directory... this will reset the algo mentionned by Piskvor applies itself again
In the new directory (after a move), you will get:
ALONGF~1.TXT alongfilename1.txt
ALONGF~2.TXT alongfilename2.txt
ALONGF~3.TXT alongfilename3.txt
even though alongfilename2.txt has initially been created third.
This link says how NTFS does it. I would guess it's still the same idea on more recent version.
In Windows 2000, both FAT and NTFS use
the Unicode character set for their
names, which contain several forbidden
characters that MS-DOS cannot read. To
generate a short MS-DOS-readable file
name, Windows 2000 deletes all of
these characters from the LFN and
removes any spaces. Because an
MS-DOS-readable file name can have
only one period, Windows 2000 also
removes all extra periods from the
file name. Next, Windows 2000
truncates the file name, if necessary,
to six characters and appends a tilde
( ~ ) and a number. For example, each
non-duplicate file name is appended
with ~1 . Duplicate file names end
with ~2 , then ~3, and so on. After
the file names are truncated, the file
name extensions are truncated to three
or fewer characters. Finally, when
displaying file names at the command
line, Windows 2000 translates all
characters in the file name and
extension to uppercase.
When the files are provided by a network server which is running Samba, then the short names are generated by the server, and they do not follow a predictable pattern.
So it is not safe to assume that you can predict the form of the short name.
G:\>dir /x *.txt
Directory of G:\
08/25/2009 12:34 PM 1,848 S2XYYV~1.TXT strace_output.txt
03/01/2010 05:32 PM 325,428 TEY7IH~O.TXT tomcat-dump-march-1.txt
03/11/2010 12:01 AM 5,811 DI356A~S.TXT ddmget-output.txt
01/23/2009 01:03 PM 313,880 DLA94Q~K.TXT ddm-log-fn.txt
04/20/2010 07:42 PM 7,491 A50QZP~A.TXT april-20-2010.txt