I want to set my process as critical. I understand all the risks, just want to know what to call.
I tried the RtlSetProcessIsCritical method and it worked as it should. Though i tested it on Windows XP virtual machine, one website claimed that RtlSetProcessIsCritical was first presented on Windows 8, and that I need to call NtSetInformationProcess instead. So what do I call? Is there really any difference between those two functions?
one website claimed that RtlSetProcessIsCritical was first presented on Windows 8
That is incorrect. It is available in Windows XP and 7, as well.
However, even to this day, RtlSetProcessIsCritical() is still undocumented by Microsoft. Which means, you really should not be using it at all. But, you have already decided to use it, so...
Is there really any difference between those two functions?
RtlSetProcessIsCritical simply calls NtSetInformationProcess() internally. RtlSetProcessIsCritical() is in NTDLL.DLL, whereas NtSetInformationProcess() is in NTOSKRNL (the Windows Kernel), so the former will just call the latter.
Related
I have a working module on linux and one of the client wants it on windows.
There is very good discussion on similar topic here(https://ask.slashdot.org/story/04/08/12/1932246/cygwin-in-a-production-environment), I guess it leaning towards avoiding cygwin for productions but its about 13 years older discussion,there might have been issues but in about 13 years I hope cygwin might have been improved,matured and good for production use.
The code compiled just fine and seems to work ok under cygwin so its very tempting to take it forward rather than redoing it in windows native code.
But if there are really any unsolvable known issues and people are avoiding it for productions I would like to know.
The code heavily uses pthreads,sockets in no-wait
I've used Cygwin a fair bit, and have found it mostly unproblematic. I am aware of some of the reported problems, but haven't experienced them myself. Some things on Cygwin are much slower than the same code on Linux -- I notice this most with directory scans, but that probably isn't the only thing. People complain about fork() being slow, but that isn't really a surprise, as 'forking' isn't a native concept in Windows. If you're just using fork() to launch subprocesses, then conceivably the whole fork/exec thing could selectively be replaced with calls to native Windows APIs.
A potential limitation of Cygwin is that it requires Cygwin at run-time or, at least, a chunk of Cygwin infrastructure. MinGW might remove this restriction, but at the cost of leaving you to make a larger number of compatibility-related changes in your code (file locations, for example). The last time I looked, MinGW didn't have tooling as extensive as Cygwin, either, but it's probably good enough for many purposes.
I guess another possibility to consider these days is the Windows Subsystem for Linux (WSL) on Windows 10. I've found that code that builds for Cygwin usually builds and runs without changes on WSL, but I haven't really figured out what the relative advantages and disadvantages of Cygwin and WSL are.
I've not noticed problems with pthreads in Cygwin, MinGW, or WSL; although I guess any problems are likely to depend on the exact way you use threads. I can't comment on the no-wait socket issue, because that isn't something I've tried.
Incidentally, both Cygwin and MinGW will allow you to call native Windows API, and other functions in DLLs, if you need to. So the possibility exists to create a sort of "hybrid" application that uses POSIX-type functions and also Win32 APIs. This might be useful if it turns out that some things are much faster with Win32 functionality. I'm not sure this is possible with WSL.
I should say that my comment about time consuming updates refers as much to the need to perform a full Windows update as well as apt-get updates prior to running a wsl
script which will go past midnight. Running a separate memory recovery script every 4 hours or so is a partial solution. I have "only " 6GB RAM.
In this question I'm asking of one specific bit of functionality of readline:
The Readline library includes additional functions to maintain a list of previously-entered command lines, to recall and perhaps reedit those lines
Now on Windows with Visual Studio you ain't need no stinking readline. You can use fgets and arrow keys will happily recall what you typed previously. Of course you can edit these too.
On linux the very same code (fgets in a loop ) does not work like this. Up arrow is shown as ^[[A and left and right arrows also does not allow you navigating the line as shown by experiment and also described here.
My question is, what part of Windows makes the editing possible?
I think it can be either conhost.exe or how fgets, et al, are implemented. Somehow I suspect that it's the former. In any case, I'd like to know how exactly it works if it's documented anywhere, etc. For example, what other keys, apart from arrows have a special meaning and processed differently instead of being returned as par of the buffer fgets writes to.
The documentation for DOSKEY lists the special keys.
I am not aware of any documentation explaining that in 32-bit Windows this functionality is built into the console and that doskey.exe is merely an interface to it. However, it is easy to confirm that this functionality does not depend on the running console application using the C runtime library or having been launched from the command-line shell.
It is a reasonable guess that the actual code implementing this feature lives inside conhost.exe on current versions of Windows, but of course that's an implementation detail, subject to change without notice. From the programmer's perspective, all that matters is that DOSKEY functionality is present on any console window, and is available whenever the application is in cooked mode.
Note that cooked mode is the default setting. Therefore, console applications will have DOSKEY functionality unless the application specifically disables it.
I need to write some C functions that will be called by a java program running on a CenOS Linux server, as part of a web application. The server is a hosted dedicated server sitting in another physical location, far away from me.
Do I need to develop the C stuff on the server directly, that is, doing development tunneling into the server? Or can I develop the C program on a Mac or Windows PC in my office, then once everything is working fine, store the final results on the server for use? If the latter, does it limit the choices for development environment in any way? That is, which compiler I should use, or any settings in the IDE or compiler I need to worry about since the development environment will be different than the production environment?
If I use Xcode version 3 on a Mac, it uses GCC by default, whereas Xcode version 4 uses LLVM-GCC to compile. Does the choice of compiler matter assuming I'm using C99 standard things? I don't want the code to be dependent on the development environment since I can't guarantee it'll stay the same in the future. Can I switch the compiler manually in Xcode somehow to verify the code works in GCC as well as LLVM?
Ignoring windows, things are pretty portable across mac/linux. If you develop it on mac in whatever development environment you want (I personally use TextWrangler and GCC from the command line.
Once you develop your software, it's a simple matter of copying the file to your remote server and compiling it there.
You may or may not need to change a few things. The only portability issue I've run into was mac's socket() using PF_ instead of AF_ (Mac will still accept AF_ but it doesn't advertise it in it's manpage, and other systems will not necessarily accept PF_) and sranddev() not being available on some systems; both of which were very easily resolvable.
If, however, you wanted to write the software directly on the remote box, its definitely not a hard thing to do, I would just ssh there and take your pick of text editors (usually vi or emacs) and compilers (usually gcc).
In general, for programs that are just traditional unix command line things, I tend to avoid Xcode as much as possible because it likes to hide things, and IMO its a good thing to actually understand what is going on behind the scenes. (Especially if you use other *nix systems.)
Whatever you do, it will need to be recompiled on the server.
You can probably create code that's runnable/testable under both environments, although you may have to #ifdef around compatibility issues. How much of that, if any, depends a lot on what you're actually writing.
Does the choice of compiler matter assuming I'm using C99 standard things?
Yes: Microsoft, AFAIK, still doesn't fully support C99 (but maybe that's changed in the latest MSVC). Also, you have to resist the temptation of using non-standard features just because they are there. OTOH, a local build env might force you to write portable programs.
The choice depends on how your program is going to communicate with the larger system, but developing at least parts locally is probably the most convenient option.
I looked at some other questions on SO and its not clear if c is built on top of, under, or alongside the WINAPI. Like for example could someone write something in pure c that was able to open a window, or would they need to use the windows api?
I noticed similarities between the c (library?) version of opening a file (fopen) vs the windows API version (CreateFile) which makes me wonder if one is just a wrapper for the other. Does anyone know?
If windows is running; is a programmer forced to program using the windows api to get something running on it or can the programmer not use the windows api at all and directly access the hardware (ie. does the windows operating system protect access to the hardware)?
Which is more portable between different versions of windows of windows ce. The documentation I found (which has now changed) used to say that CreateFile only goes back to version 2.0 of windows ce (here: http://msdn.microsoft.com/en-us/library/ms959950.aspx -
Notice the note on the link at the very bottom that shows the supported version information has been changed). So what is one supposed to use for windows ce version 1? In other words is programming using c functions or the functions labeled WINAPI more likely to work on all versions of windows CE?
I read the following in a book about programming windows ce and it confused me, so all of the above questions can be understood better in context of making sense of the following:
Windows CE supports the most of the same file I/O functions found on Windows NT and Windows 98. The same Win32 API calls, such as CreateFile, ReadFile, WriteFile and CloseFile, are all supported. A Windows CE programmer must be aware of a few differences, however. First of all, the standard C file I/O functions, such as fopen, fread, and fprintf, aren't supported under Windows CE. Likewise, the old Win16 standards, _lread, _lwrite, and _llseek, aren't supported. This isn't really a huge problem because all of these functions can easily be implemented by wrapping the Windows CE file functions with a small amount of code.
My understanding of wrapping is that you have to have something to wrap, given how it appears that win16 and c library are not available is he stating to wrap the CreateFile function to make your own c-like version of fopen? (The only other thing I am aware of is assembly, and if that is what he was suggesting to wrap it wouldn't be written in such a casual manner.)
Given the above, what is the dependency relationship between c language (syntax, data structures, flow control), the c function library (ex. fopen), and the windows api (ex. CreateFile)?
C existed long before Windows did. The Windows API is a bunch of libraries written in C. It may or may not be possible to duplicate its functionality yourself, depending on what Microsoft has documented or made available through the API. At some level it is likely that fopen() and CreateFile() each call the same or a similar operating system service, but it's unlikely that one is a strict wrapper for the other. It would probably be difficult to bypass the Windows API to access the hardware directly, but anything is possible given enough time and programming effort.
C doesn't know anything about GUIs, and VERY little about operating systems at all. Anything you do graphics-wise in C is through the use of libraries, of which the win32 api is an example.
The windows API is implemented in the C programming language. Functionality provided by the C standard libraries, such as fopen, is portable because it is compiled down to the appropriate assembly code for different architectures by different compilers. Windows API functions such as CreateFile only work on machines running Windows and are therefore not portable.
In theory it's possible to write C that talks directly to the hardware. Back in the days of MS-DOS (for one example) quite a few of us did on a fairly regular basis (since MS-DOS simply didn't provide what we needed). Edit: On some small embedded systems, it's still quite commonplace, but on typical desktop systems and such this has mostly disappeared.
Two things have changed. First, modern systems such as Linux and Windows are much more complete, so there's a lot less need to deal directly with the hardware. Second, most systems now run in protected mode, so normal user code can't talk directly to the hardware -- it has to go through some sort of device driver.
Yes, most of the C library uses the underlying OS so (for example) on Windows, fopen and fwrite will eventually call CreateFile and WriteFile, but on Linux they'll eventually call open and write instead.
I noticed similarities between the c (library?) version of opening a file (fopen) vs the windows API version (CreateFile)
Not surprising. They do similar things.
[is] one is just a wrapper for the other? Does anyone know?
You can't find out because the source code is owned and kept as a trade secret.
It doesn't matter which is more "fundamental". You use the windows API from a windows program. You use C API's from C programs.
Notice that it doesn't matter. You can use C API's or Windows API's intermixed.
If windows is running; is someone forced to use the windows api to get something running on it or can they bypass windows entirely and directly access the hardware?
"Directly access the hardware"? What does that mean? If windows is running, then.... well... Windows is running. Windows mediates your access to the hardware.
Use bootcamp or GRUB or some other bootloader to bypass Windows and have "direct access to the hardware".
If they can, is it possible to damage the hardware if you don't know what your doing?
What does this mean? Are you asking if you can "damage" some rotating media (i.e., disks) by misusing their drivers? You can corrupt your hard disk no matter what OS you're running or not running. A privileged account and dumb software can write bad data on a disk. Does that count as "damage"?
Which is more portable?
What does that mean? To another Windows computer? To a computer not running Windows? What are you asking about? Please clarify your question to define what you mean by "portable".
between different versions of windows
Since different Windows are mutually incompatible, I generally suggest using only the POSIX standard libraries and avoiding all Windows API's.
However, some Windows variants (e.g. Windows mobile for phone vs. Windows "Server") are essentially totally incompatible. There is very little reason for any piece of software to run on both OS's. Portability doesn't much matter. Why try to run a phone app on a server?
Edit
So theres the c language on the bottom (closest to the hardware), then the windows API next, then the C library on top of the Windows API?
This doesn't make sense. You're mixing up two unrelated things. The "language" and the "libraries" have little to do with each other.
Also, the API is not the operating system. So by using Windows "API" all the time, you're making this more confusing than it needs to be.
Here's a way to look at this.
The Windows Operating System has several API's. There are underlying function libraries that are not part of the application interface. They're "internal".
It has a native Windows API. Callable from C.
It has a POSIX API. Callable from C. In some cases, the Posix API generally uses the Windows API.
Most operating systems, including Windows are written in C (and or assembler). The Library is then modified for each operating system to do the basic stuff. (Sockets, Files, Memory, etc ...).
The WINAPI is just a bunch of libraries (written in C and/or Assembler) that allow access to functionality within the OS.
It is not Windows related, after you changed your question, I think what you are trying to understand is the bootstrapping of an OS (Windows or other).
The book Operating Systems Design and implementation discusses the implementation of Minix (Which Linux is based on).
the WINAPI provides an interface that developers in C can use in order to use the WINAPI functionality. C++ programs can also use it.
Operating systems such as Windows contain WINAPI libraries that provide access to some operating system functionality and sometimes contact with Hardware, these libraries are written in C
Carl Norum pointed out that C existed long before Windows, but don't forget that the Windows API kind of started with the MS-DOS API, which kind of started with the CP/M API. C only existed a short time before CP/M.
Lots of answers seem to imply that the Windows API is built on C, but that seems doubtful too. __stdcall is a synonym for PASCAL, which was a keyword in Microsoft's C compilers because the Windows API was built on Pascal. __cdecl is the default for function calls in C and C++ programs compiled by Visual Studio but it doesn't work on calls to APIs.
The relationship between C and the Windows API is that they are capable of working with each other.
As a fun note, you can really get a handle on the 'power' of the Windows API by taking a look at AutoIt http://www.autoitscript.com/autoit3/. AutoIt is a great little scripting language that can create GUIs, run command line apps, manipulate windows and processes, etc. Yes, it does File I/O and networking.
I have written a small custom web server application in C running on Linux. When the application receives a request it calls fork() and handles the request in a separate process, which is chrooted into a specific directory containing the files I want to make available.
I want to port the application to Windows, but neither fork() nor chroot() are available on this platform, and there don't seem to be any direct equivalents. Can you point me to a simple (and preferably well written) example of code that will provide this functionality in Windows? My C isn't all that good, so the simpler the better.
First of all, the Windows equivalent of chroot is RUNAS which is documented here. If you need to do this from a program, then studying this C++ source code should help you understand how to use the Windows API. It is not precisely the same as chroot() but Windows folk use it to create something like a chroot jail by creating a user with extremely limited permissions and only giving that user read permission on the application folder, and write permission on one folder for data.
You probably don't want to exactly emulate fork() on Windows because it doesn't sound like you need to go that far. To understand the Windows API for creating processes and how it differs from fork(), check Mr. Peabody Explains fork(). The actual current source code for Cygwin's fork implementation shows you the current state of the art.
The Microsoft documentation for CreateProcess() and CreateThread() are the place to look for more info on the differences between them.
And finally, if you don't want to learn all the nitty-gritty platform details, just write portable programs that work on Windows and Unix, why not just use the Apache Portable Runtime library itself. Here are some docs on process creation with some sample code, in C, to create a new process.
There's no such thing as fork() on Windows. You need to call CreateProcess() - this will start a separate process (mostly equivalent to calling fork() and then immediately exec() for the spawned process) and pass the parameters to it somehow. Since you seem to have all the data to process in a dedicated directory you can make use of lpCurrentDirectory parameter of CreateProcess() - just pass the directory path you previously used with chroot() there.
The absolutely simplest way of doing it is using Cygwin, the free Unix emulation layer for Windows. Download it and install a complete development environment. (Choose in the installer.) If you are lucky, you will be able to compile your program as is, no changes at all.
Of course there are downsides and some might consider this "cheating" but you asked for the simplest solution.
Without using a compatibility framework (Interix, Cygwin, ...) you're looking at using the Windows paradigm for this sort of thing.
fork/vfork is a cheap operation on UNIXes, which is why it's used often compared to multi-threading. the Windows equivalent - CreateProcess() - is by comparison an expensive operation, and for this reason you should look at using threads instead, creating them with CreateThread(). There's a lot of example code out there for CreateThread().
In terms of chroot(), Windows doesn't have this concept. There's libraries out there that claim to emulate what you need. However it depends why you want to chroot in the first place.
Reading comments, if it's simply to stop people going up the tree with ../../../../(etc), chroot would do the job, but it's no substitue for parsing input in the first place and making sure it's sane: i.e., if too many parents are specified, lock the user into a known root directory. Apache almost certainly does this as I've never had to create a chroot() environment for Apache to work...
Using fork/chroot is simply not how things are done on Windows. If you are concerned about security in subprocesses, maybe some form of virtualization or sandboxing is what you want to use. Passing complex information to the subprocess can be done by some form of RPC-solution.
It sounds to me as if you have designed your application in the Unix way, and now you want to run in on Windows without having to change anything. In that case, you may want to consider using Cygwin, but I'm not sure if/how Cygwin emulates chroot.
Consider SUA ( aka Windows Services for Unix ). It has nearly everything you need to port applications.
man chroot(interix)