This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I'm writing a script for Caseware, the accounting software my Company uses, and I need to kill a process that hangs and messes up the compression of files on the server. The problem is it needs to be written in jscript and I havn't had a lot of experience with it.
I've been looking around for code examples people use to kill process but I couldn't find much. I did find an example of someone calling an .exe from jscript and I thought I'd try it using the taskkill.exe in windows, but it didn't seem to work.
Here's the block of code that I used.
function OnFileClose()
{
w = new ActiveXObject("WScript.Shell");
w.run("taskkill.exe /im iexpore.exe");
return true;
}
I'd appreciate any examples people have or suggestions.
Thanks.
Update: I've done some more testing on the script and I've figured out that it actually executes taskkill.exe, but it isn't passing the /im parameter.
Shouldn't that be iexpLore.exe rather than iexpore?
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 4 years ago.
Improve this question
PREFACE
I tried to put as much effort and work into this question as I reasonably could, so if you could at least read it through, I would highly appreciate it; I, also, have tried researching this question, but I never seemed to find anything useful, in terms of anything that directly answered my question; I do not know if this is right place for this question, even though it is related to programming, it is more related to operating system development and the Linux kernel, and if there is a better place for this question that I am unaware of, please move it there; feel free to do whatever, edit the question if need be, I do not care, I just need an answer to this question, because this is stressing me out.
The following is some background on why I am asking this question; if you are uninterested, and if you just want to see what I am asking, then skip to the 'MY QUESTION' label; I thought that I would put this is here, so that anyone who is reading this question would know why I am asking this question.
BACKGROUND
I have recently begun setting up an operating system development project; and after I get some things ready, it will be only me working on it, as of right now, and I plan to write the whole thing (yes, I know it will take a whole lot of work, but I can try, right? :p), including the bootstrapping, the CLI, and most of what is necessary to have to either my own kernel or Linux kernel function; GUI and much more; granted, eventually I may end up having a team, but that is for the future.
MY QUESTION
My question, which is actually consists of three parts, and I narrowed them down to specifically those thee things, which are the following:
(1) If I were to build everything else, and use the Linux kernel as-is, and if I were to not tie the other parts of the system into the kernel, but use the kernel for I/O and system calls, would I be violating the GPL in any way, and would I think need to open source the rest of my code?
(2) If I were to only use the kernel for I/O and for system calls, but not have the code that I wrote actually interface with any kernel functions, would that still be considered linking?
(3) If I were to do the above, would that be considered a derived work, when I wrote everything else, but used Linux as the system's kernel?
All these legal issues are making my head spin and extremely confusing to me.
No
No
No
The linux kernel considers the system calls a boundary, and code that communicates with the kernel via system calls is not covered by the licensing of the kernel. So, the user space code you write is not a derivative work of the kernel.
There's also a set of header files provided by the kernel, collectively named the UAPI headers which you can use without having your code become a derivative work
This is covered at https://www.kernel.org/doc/html/v4.17/process/license-rules.html and https://github.com/torvalds/linux/blob/master/LICENSES/exceptions/Linux-syscall-note
If you need legal advice though, contact a lawyer.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I'm using ReSharper 6.1. Great tool, but one thing annoys me and I can't figure out how to change it: I think the order of options presented when an abbreviation breaks style rules is backward. Our codebase is littered with variable and method names containing "XML," "ID," etc. ReSharper catches these (which I like) but instead of offering to change the name as its first option, it uses the 'add xyz to abbreviations list' as the first option.
This ordering drives me nuts because I frequently add an abbreviation that I don't want by accident. Then I have to spend some time clicking through the config menus to remove the abbreviation. When I do catch myself before adding it, I have to hit the down arrow to reach the option I want; I'm a Vim/VsVim user, so as a rule I try to avoid use of the arrow keys.
So - does anyone know how I can switch the order of the suggestions, or even disable the 'add xyz...' option entirely? Thanks!
I don't believe there is a way to do this.
There was a thread on JetBrains asking about this exact issue, but no resolution. They did open a usability ticket, so you can always throw your support behind it.
According to this post, this issue should be resolved in version 7.01
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
So, I'm almost 100% self taught in programming (save for a course in C after I had already taught myself C). This means that to keep myself programming, I have to be constantly finding materials (i.e. tutorials) on the web (I'm poor). Unfortunately, I've found myself stuck in a sort of limbo, where I understand the basics of programming (in theory, I'm able to grab a new language and get comfortable enough to solve a few Project Euler problems, as is evident by my time spent here) but I'm not able to get any deeper than that, like GUI programming or web interfacing.
I don't know if it's just me, but there seems to be a sort of great divide in terms of the level of difficulty in the tutorials on the internet. All I can find fall under either Maddeningly Easy or Maddeningly Difficult. Are there no intermediate tutorials out there? The kind that say, okay, you've seen this before, here's some code but we'll explain what's happening. But I digress.
Given my lack of ability to breach the practicality gap in terms of programming, I find myself stagnating. I can only teach myself the first six Project Euler problems in so many languages. I need to find something, some sort of project, before my spark dies out. I'm worried about it. I know this is such a broad question, but... can anyone help me out? Point me in some sort of direction?
You need to start making things. You can start out small, but find a project that you can contribute to or that you want to work on yourself.
If you can't think of anything "useful" to make, then start writing simple games: a tetris clone, a top-down shooter, something like that. It doesn't have to have AAA graphics but even a simple game like tetris will teach a lot about the more complex structure of a program, user interface, and that sort of thing. But at the same time there's nothing so complicated than you'll get completely stuck.
Passion is not something that will die out that easily. There are tons of local user groups/developer groups that you can join to learn from them (most of them are free) To get to some of what you defined as intermediate problem, getting a job is definitely the best solution. You could work on Dave Thomas's coding kata. For difficult ones, you can do some facebook puzzles (they get real hard at the second level and up, easily take hours to days to solve)
A couple of suggestions which I might offer, as they have worked for me in the past, when in the same situation:
1) Get involved in an Open Source Project.
One of the best ways to learn programming is to read/review/refactor code created by other programmers. You learn new tricks, as well as good style guides for formatting your code in later work, and start building a good understanding of a pile of packages which you can roll together to create solutions down the track.
2) (If you aren't already) Get a Job as a Programmer.
The single greatest kind of learning experience I have had when it comes to programming is when I need to extend my skillset to solve a particular problem. Being put in a role where you are given a problem, which, when you start, is beyond your skills and then creating a solution using experimentation, sourcing existing solutions online, referring to documentation, asking a learned colleague, etc. is great. It is almost like a trade apprenticeship - you learn as you go and sooner or later you can handle 95% of the solutions autonomously.
One thing I have seen said time and time again on various blogs and forums is that trying to be highly skilled in a wide range of languages is an almost impossible challenge - it is better to pick one (or maybe two) and then practice, practice, practice to develop it's associated skillset to a great degree.
Perhaps you should start working on REAL WORLD projects for either friends or family.
This will give you positive feedback for your efforts and a sense of "acheivement" when the job is finished.
Great programming theory is all very good, but without introducing some kind of "reward cycle" I can understand how frustrated you could become.
You need to start and finish a project that's a large enough to force you to learn different things, but small enough to actually finish. Here are some ideas:
Jabber client
RSS reader
Twitter client
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 13 years ago.
I don't know if I am a bad programmer because I often make mistakes when outputting information on a site, things like "thanx for subscribing to our service" instead of "Thanks for subscribing to our service".
I think this is because I usually don't concentrate on the spelling, my main focus is to get the functionality running perfectly. Please give me your opinion, do you concentrate on the spellings or the functionality?
If I'm writing a message which will be visible to users, I'll make sure it's clear and correct. If I'm writing a message which will only be visible to other developers, I'm slightly less careful - in particular, typos aren't really a problem, so long as I express myself clearly.
Fortunately my spelling/typing/grammar is reasonably good anyway, so I don't need to think too hard about this, but I think it is important for customer-facing text.
Developers often aren't very good at writing messages for users. It can be hard to put yourself in the position of someone who really has no idea about what's going on in the background: they just want to get their email (or whatever it is) working. If you're lucky, you may be able to get a technical writer to help compose appropriate text.
IMO attention must be paid to both. Cool logic and reliability are no excuse for crappy texts.
You could separate checking the resource from changing the source. When you do changes first change the code, test everything, then proofread the resources.
The CTO at my last job was dyslexic, and a completely brilliant programmer and manager. Every now and then I would go and make a spelling correction to one of his method or variable names (C# handles the refactoring pretty well) and it didn't really matter that much.
When there's user interface work it's much more important to spell things correctly coz it looks very shabby to have a misspelled UI.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have always been astonished by Wine. Sometimes I want to hack on it, fix little things and generally understand how it works. So, I download the Wine source code and right after that I feel overwhelmed. The codebase is huge and - unlike the Linux Kernel - there are almost no guides about the code.
What are the best-practices for understanding such a huge codebase?
With a complex code base the biggest mistake you can make is trying to be a computer. Get the computer to run the code, and use a debugger to help find out what is going on.
Figure out how to compile, install and run your own version of Wine from the existing source code.
Learn how debug (e.g. use gdb) on a running instance of your version of Wine.
Run Wine under the debugger and make cause it to demonstrate the undesired behaviour.
The fun part: find where the code execution path goes and start learning how it all goes together.
Yes, reading lots and lots of code will help, but the compiler/debugger/computer can run code a lot faster than you.
A professor once told us to compare such a situation with climbing a mountain. You might be listening to someone who did this and tells you what it's like to look out into the country. And you believe without hesitation that that's a spectacular sight.
However, you have to start climbing yourself for real understanding what the view from the top is like.
And it's not that important to climb all the way to the top. It might be perfectly suficient just to reach a fair height above ground level.
But don't ever be afraid of start climbing. The view is always worth any efforts.
This has always been a nice analogy for me. I know this question was more about specific tips on how to efficiently deal with code bases once you started climbing. But nevertheless it instantly reminded me of our physics classes way back then.
(This is an answer I posted to a question a while back. I modified it a bit to fit this question.)
Experience has shown me that there are 3 major goals you have when learning a legacy system:
Learn what the code is supposed to do.
Learn how it does them.
(crucially) Learn why it does them the way it does.
All three of those parts are very important, and there's a few tricks to help you get started.
First, resist the temptation to just ctrl-click (or whatever your IDE uses) your way around the code to understand everything. You probably won't be able to keep everything in perspective in your mind this way, especially when each line forces you to look at multiple other classes in order to understand what it is, so you need to be able to hold several levels of the stack in your head.
Read documentation where possible; it usually helps you quickly gain a mental framework upon which to build everything that follows.
Run test cases where possible.
Don't be afraid to ask someone who knows if you have a question. Granted, you shouldn't waste others' time with inane queries, but if there's something that you simply don't understand (this is especially true with more conceptual questions like, "Wouldn't it make much more sense to implement this as a ___" or something), it's probably worth finding out the answer before you mess something up and don't know why.
When you do finally get down to reading the code, start at a logical "main" place and go from there. Don't just read the code top to bottom, or in alphabetical order, or anything (this is probably obvious).
The best way to get acquainted with a large codebase is to dive in. Many projects have a list of easy tasks that need to be done, and they're usually reserved to help ease people in. You should find and work on some of these; you'll learn a lot about the general code outline and structure, contribute to the project, and get an easy payoff that will help encourage you to take on larger tasks.
Like most projects, WINE has good resources available to its developers; IRC, wiki, mailing list, and guides/overviews. With most daunting codebases, it's not so scary after the first few fixes. WINE is truly large, and much like the kernel, I doubt there's any expert in all systems; don't feel like you need to be either. Start working on something that matters to you and take it from there.
I've started a few patches to WINE myself, and it's a good community and good structure. There's lots of very helpful debug messages, and it's a really cool project to work on, so that helps you hit it longer too.
We all appreciate your valor and willingness to help with WINE (it needs it). Thanks, and good luck.
Dig in. Think of a question you'd like to have answered, and try to find the answer. When you get tired of reading code, go read the dev mailing list, the developer's guide, or the wiki.
Unfortunately, there's no royal road to understanding a large code base. If you enjoy that sort of thing (I do) you're in for some fun. If not, guide books won't really help, so you aren't really that much worse off.
Look for one peculiar feature you are interested to improve. Search for its implementation. Once you found it, pull on that straw and all the rest will follow.
The best way is through comments.
I'm being ironic, as you understand tiny bits of the beast add comments so you can follow your trail.
The other developers will also enjoy it if you add the missing guides in the code.
Try to implement some tiny little change in the code, something that will be visible to you. That might be figuring out a workable way to output debugging statements (and figuring out where the output appears), it might be changing the default size of windows or desktop color, or something. Once you can make something happen in the codebase, you've scratched the surface of understanding and can begin to move on toward more complicated things. At that point, select a goal of something slightly more useful that you'd like the code to do, and implement that. Or check out the project's bug tracker and look for something small to start with.
Document as you go, and write unit tests as you go, and refactor as you go. When you figure out what a routine does, comment it!!
As others have suggested, dig in! Read all the available documentation you can absorb. Then see if you can find other people who are interested or knowledgeable and learn with/from them. It helps to have people to bounce ideas off of and ask questions.
For C source code, once you get a feel for what areas of the code you'd like to work on, generate ctags and cscope databases for that code. These tools make it a lot easier to jump around and understand the code. Many text editors (one example is gvim) have support for ctags and cscope so you can jump around easily.
(warning: shameless marketing ahead)
For Java developers using Eclipse, there's nWire. It is an Eclipse plugin for navigating and visualizing large codebases.
A good way to understand a large system is to break it down into it's constituent parts and focus on a specific paths through the application.
Your debugger is your friend here, set a breakpoint in the thread you want to investigate then step through it line by line looking at which each part does... hope that helps...