Jump to content
  • Advertisement

dwahler

Member
  • Content Count

    69
  • Joined

  • Last visited

Community Reputation

313 Neutral

About dwahler

  • Rank
    Member
  1. dwahler

    Reasons why applications are non-portable

    The above is all correct, but maybe I can help make it a little more concrete. One difference is the executable formats. A "binary" executable file is actually an archive that gives the OS instructions on how to load the program into memory. This includes: which sections of the file should be loaded where; what access level they should use (global variables should be writable, code shouldn't); what shared libraries to link to, and how to patch up the references to them; etc. Linux uses a format called ELF to store all this information, Windows uses a different one called PE, and other operating systems no doubt have their own standards. (On Linux, you can use the "objdump" program to inspect the full headers of a binary file.) If all your code does is computation and memory access, this is all that matters. But a useful program also needs to interact with resources provided by the OS to communicate with the outside world. The low-level details of this are also OS-specific. On Linux, any time you want to ask the kernel to do something like read a file, you need to do a system call. In x86 Linux, this is done by putting values in certain registers and executing an "int 0x80" instruction that jumps to a special privileged entry point. Other operating systems and processor types do it differently. If you're programming in a high-level language, this level of detail is normally hidden from you. For instance, Linux implements the POSIX API that provides functions like open(), read(), and write(). When you compile a C program, the linker looks in the standard C library and plugs in the assembly code that performs the underlying syscall. So if you stick to the standard APIs, your binaries won't be portable, but your source code will be. You can just compile on a different platform and the standard library for that machine. This only works for POSIX-compliant OSes, though. So for instance, if you try to transplant a program from Linux to Windows, this way, it will fail because Windows doesn't know anything about the open() function. It has something called OpenFile() that mostly does the same thing, but a bit differently. There are also bigger differences: creating a new process in Unix involves the fork() function, which simply has no direct equivalent in Win32. And don't even get started on the differences between GUI systems! If you want to write a cross-platform program, the usual answer is to use libraries that handle the platform differences for you. For instance, you can use the POSIX API and simulate it with Cygwin, although that's a bit clunky. For GUIs, you can link with GTK, Qt or WxWidgets, each of which has multiple "back-ends" for different windowing systems.
  2. That makes sense. Read up on what reinterpret_cast does. Hint: it does not convert data from one type to another. Your code is telling the compiler to treat the integer value Version as a memory address and read 4 bytes from that location. Since 0x00000003 isn't a valid virtual address, the process crashes. My guess is you intended to write either the sequence of bytes "00 00 00 03" or "03 00 00 00". In either case, the correct, portable way to do that is one byte at a time with bitwise operations.
  3. The obvious answer is to change the dimensions of the JPEG output to match the window size. If that's not an option, you'll have to decide on some combination of scaling and/or cropping to convert between the sizes -- something like pan and scan might be what you're looking for.
  4. dwahler

    make just... makes

    Make is fine. There are plenty of other alternatives out there that have different approaches or more features, but make is the lowest common denominator that most people are familiar with. The problem is that you're not setting up your rules properly. The left-hand side should be the name of the file you're trying to generate, and the right-hand side should be a list of all the files it depends on. That way, make can check the timestamps and only build the target if it's out of date compared to its dependencies. There are lots of different ways to structure your rules, but one fairly simple approach looks like this: OBJS = $(BINDIR)/common.o $(BINDIR)/pixmapbuffer.o ... # other variables go here... # this is just a shortcut project: $(BINDIR)/project $(BINDIR)/project: $(OBJS) g++ -o $(OUTPUT)/project $(OBJS) # template to build .o files from corresponding .cpp $(BINDIR)/%.o: $(SRCDIR)/%.cpp g++ -c -o $@ %< # additional dependencies $(BINDIR)/common.o: $(SRCDIR)/common.h $(BINDIR)/pixmapbuffer.o: $(SRCDIR)/common.h $(SRCDIR)/glx.h ... (It's possible to have g++ generate the "additional dependencies" section automatically, but it's sort of tricky to get it right; check out edd's link if you're interested.) Note that you don't need to recreate the symlink from project to $(BINDIR)/project every time you rebuild the project.
  5. [font="arial, verdana, tahoma, sans-serif"]In multithreaded code, sleeping for a time interval is almost never the right thing to do. If your code is waiting for something to happen, wait for that event. In your case, it sounds like your thread should sleep until either (a) data is available on the COM port, or (b) some other part of your application has queued a message to be sent. You can use WaitForMultipleObjects to wait for one of those conditions to hold.[/font]
  6. Did you check the document for the readLine() method? In particular: Quote:Returns: A String containing the contents of the line, not including any line-termination characters, or null if the end of the stream has been reached In case this doesn't make the problem obvious: when a request is being processed, the runServer1() and sendData() methods are executing simultaneously. What happens at the end of sendData()? What does this do to the second iteration of the server's request-handling loop?
  7. Quote:But we get exceptions on the server You will have a lot more luck getting help with your problem if you post the exception and stack trace. Speaking of which, get rid of all those calls to "System.err.println(... + e.toString())" and replace them with "e.printStackTrace()". Or better yet, if you're not going to handle the exceptions other than by crashing the program, don't catch them in the first place.
  8. dwahler

    Making a blurry screen

    This is definitely possible in Linux using Compiz. e.g. http://www.toosweettobesour.com/wp-content/uploads/2008/05/screenshot1.png
  9. dwahler

    2D Graph Generation

    Do you mean a lattice graph? The simplest example has a vertex for each integer lattice point from (1,1) to (m,n), where two vertices are joined by an edge if (and only if) they are adjacent points, i.e. they differ by 1 in either the x or y coordinate. If that's not what you're looking for, you probably need to be more specific.
  10. Which, when solved, gives f(n) = 3/2 * (3^n + 1).
  11. Check again. As JesusGumbau said, section 3.4 of the paper describes that problem and how to solve it.
  12. If you want to avoid requiring an internet connection, your options are severely limited. The only way you can distinguish licensed and unlicensed users is by checking some kind of unique hardware ID, like the MAC address of the network card. This is fairly easy to forge (by changing OS settings or patching your program), and is vulnerable to failure if the user changes their hardware. If you choose not to rely on a unique ID, then there is no way whatsoever to distinguish between two people's devices, and your situation is completely hopeless. It's not that I can't think of a better one; it's that one doesn't exist even in principle. There's no way for software to tell which human being owns the hardware it's running on. By the way, the "key generation" algorithm you linked to is nothing more than a trivial hash function, and is easily breakable even without looking at the program's source code.
  13. You're going to need some point of interface between your software and the public phone network. There are two main ways to accomplish this: one is to get a hardware interface (technically called an FXO) that plugs into a standard analog phone line, and communicates with your software via a kernel driver. The other is to subscribe to a voice-over-IP provider and communicate with their server over the Internet, probably using the SIP protocol. As far as I know, either one of these approaches can be used with Asterisk.
  14. dwahler

    Weighted Graph using a matrix

    What output are you getting, and what output do you expect? If you're saying the output is the same every time you run the program, then that's to be expected; you're giving the RNG the same seed each time.
  15. dwahler

    mac-style fisheye effect

    There isn't really any "theory" to it. You'll just want to calculate the distance from the mouse pointer to the center of each box, and compute a scaling factor that is roughly 1 at large distances and increases as the distance decreases. The simplest example is probably the function scale=k/distance+1 (where k is a constant), limited to a reasonable maximum value. You can use other functions that might give smoother results, depending on how exactly you want the sizes to change. P.S. This isn't a fisheye effect, since there's no nonlinear distortion, only scaling.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!