public class FileSelector {

 public static File showOpenDlg(Component parent, String[] exts){
 
  JFileChooser chooser = new JFileChooser();
 
  chooser.setFileFilter(new FileFilterImpl(exts));
 
  chooser.setCurrentDirectory(new File(System.getProperty("user.dir")));
 
  int returnVal = chooser.showOpenDialog(parent);

     if(returnVal == JFileChooser.APPROVE_OPTION) {
      return chooser.getSelectedFile();
     }
    
     return null;
 }
 
 public static File showSaveDlg(Component parent, String[] exts, String displayName){
 
  JFileChooser chooser = new JFileChooser();
 
  chooser.setFileFilter(new FileFilterImpl(exts));
 
  chooser.setCurrentDirectory(new File(System.getProperty("user.dir")));
 
  chooser.setSelectedFile(new File(displayName));
    
  int returnVal = chooser.showSaveDialog(parent);

     if(returnVal == JFileChooser.APPROVE_OPTION) {
      return chooser.getSelectedFile();
     }    
     return null;
 }
}

public class FileFilterImpl extends FileFilter{
 
 public String[] exts;
 
 public FileFilterImpl(String[] exts){
  this.exts = exts;
 }

 public boolean accept(File f)
 {
  if (f.isDirectory()) {
   return true;
  }
 
  String extension = getExtension(f);
 
  if(extension == null)
   return false;
 
  for(int i=0; i < exts.length; i++){
   
   if(extension.toLowerCase().equals(exts[i]))
   return true;
   
  }

  return false;
 }

 public String getDescription(){
 
  StringBuffer sb = new StringBuffer();
 
  for(int i=0; i < exts.length; i++)
  {
   if(i == (exts.length-1))
    sb.append(exts[i]);
   else
    sb.append(exts[i] + ", ");
  }
   return sb.toString()+" File Selection";
 }

 public String getExtension(File f) {
        String ext = null;
        String s = f.getName();
        int i = s.lastIndexOf('.');

        if (i > 0 &&  i < s.length() - 1) {
            ext = s.substring(i+1).toLowerCase();
        }
        return ext;
    }

 public String getTypeDescription(File f) {
 
  String extension = getExtension(f);
  String type = null;
 
  if (extension != null) {
   
   for(int i=0; i < exts.length; i++){
    if(exts[i].toLowerCase().equals(extension))
     return extension.toUpperCase() + " File";
   }
  }
 
  return type;
 }

}

#include <Winsock2.h>
#include <Iphlpapi.h>
#include <Icmpapi.h>
#include <stdio.h>
#include <windows.h>

bool sendIcmpEcho(TCHAR * dstAddr,  //목적지 IP Addr
     DWORD tmOut,                              //요청 타임아웃
     LPVOID pData,                             //데이터
     DWORD dataSize,                        //데이터 사이즈
     ULONG * status)                         //응답 상태코드
{
 HANDLE hIcmpFile = null;
 DWORD dwRetVal = 0;
 LPVOID ReplyBuffer = null;
 bool bRet  = false;

 if((hIcmpFile = IcmpCreateFile()) == INVALID_HANDLE_VALUE)
  return bRet;

 ReplyBuffer = (VOID*) new byte[sizeof(ICMP_ECHO_REPLY) + dataSize];

 if((dwRetVal = IcmpSendEcho(hIcmpFile, inet_addr(dstAddr), pData, dataSize,
     NULL, ReplyBuffer, dataSize + sizeof(ICMP_ECHO_REPLY), tmOut)) != 0)
 {
 
  /*
  ICMP_ECHO_REPLY * p = (ICMP_ECHO_REPLY *)ReplyBuffer;

  printf("st Address %d\n",p->Address);
  printf("st Status %d\n",p->Status);
  printf("st RoundTripTime %d\n",p->RoundTripTime);
  printf("st DataSize %d\n",p->DataSize);
  printf("st Reserved %d\n",p->Reserved);
  printf("st Data %s\n",p->Data);
  */
 
  bRet = !bRet;
  *status = ((ICMP_ECHO_REPLY *)ReplyBuffer)->Status;
 }

 delete[] ReplyBuffer;
 CloseHandle(hIcmpFile);

 return bRet;
}

Link to iphlpapi.lib, ws2_32.lib

별로 세밀한 제어?를 할 수는 없지만 .. ICMP Echo를 이용해 특별한 일을 할 일은 없을 듯 하여, 이 정도로도 충분히 사용가능 할듯하다. IcmpSendEcho2()를 이용하면 이벤트를 이용해
비동기 처리도 가능하다.

ftp 접속해서 up/down하는 일이 빈번할 때
귀찮아서 만들었던 스크립트...
하지만 그 후론 사용 할 일이 없더라는..
애써 정한 사용처는 블로그 포스팅..ㅡ.ㅡ;;;

---------------------------------------------------
#!/bin/sh

INIT_DIR=.
HOST=59.xx.xxx.xx
USER=userName
PASS=passwd
LOG_NAME=.ftp.log

ftp -v -n <<EOF_FTP_CMD > $LOG_NAME
open $HOST
user $USER $PASS
binary
prompt off
cd $INIT_DIR
mput
$@
quit
EOF_FTP_CMD

cat $LOG_NAME
rm -rf $LOG_NAME
---------------------------------------------------

<From : The Old New Thing> How do 16-bit programs start up? 

Back in 16-bit Windows, MS-DOS cast a long and dark shadow. The really ugly low-level munging was very much in the MS-DOS spirit. You opened files by setting up registers and issuing an int 21h, just like in MS-DOS. Although the interrupt went to Windows instead, Windows maintained the MS-DOS calling convention. Process startup followed the same "real men write in assembly language" philosophy.

All the parameters to a 16-bit program were passed in registers. The entry point to a 16-bit process received the following parameters on Windows 3.1:

Hey, nobody said that 16-bit Windows was designed for portability.

The first thing a 16-bit program did was call the InitTask function. This function receives its parameters in registers, precisely in the format that they are received by the program entry point. The InitTask function initializes the stack, the data segment, the heap, retrieves and prepares the command line, recovers the nCmdShow parameter that was passed to WinExec, all the normal startup stuff. It even edits the stack of the caller so that real-mode stack walking works (critical for memory management in real-mode). When InitTask is all finished, it returns with the registers set for the next phase:

Once InitTask returns, the stack, heap, and data segment are "ready to run," and if you have no other preparations to do, you can head right for the application's WinMain function. Minimal startup code therefore would go like this:

    call    far InitTask
    test    ax, ax
    jz      exit
    push    di      ; hInstance
    push    si      ; hPrevInstance
    push    es      ; lpszCmdLine selector
    push    bx      ; lpszCmdLine offset
    push    dx      ; nCmdShow

    ... some lines of code that aren't important to the discussion ...

    call    far WinMain ; call the application's WinMain function

    ; return value from WinMain is in the AL register,
    ; conveniently positioned for the exit process coming up next

exit:
    mov     ah, 4Ch ; exit process function code
    int     21h     ; do it

Why wasn't the application entry point called main? Well, for one thing, the name main was already taken, and Windows didn't have the authority to reserve an alternate definition. There was no C language standardization committee back then; C was what Dennis said it was, and it was hardly guaranteed that Dennis would take any special steps to preserve Windows source code compatibility in any future version of the C language. Since K&R didn't specify that implementations could extend the acceptable forms of the main function, it was entirely possible that there was a legal C compiler that rejected programs that declared main incorrectly. The current C language standard explicitly permits implementation-specific alternate definitions for main, but requiring all compilers to support this new Windows-specific version in order to compile Windows programs would gratuitously restrict the set of compilers you could use for writing Windows programs.

If you managed to overcome that obstacle, you'd have the problem that the Windows version of main would have to be something like this:

int main(int argc, char *argv[], HINSTANCE hinst,
         HINSTANCE hinstPrev, int nCmdShow);

Due to the way C linkage was performed, all variations of a function had to agree on the parameters they had in common. This means that the Windows version would have to add its parameters onto the end of the longest existing version of main, and then you'd have to cross your fingers and hope that the C language never added another alternate version of main. If you went this route, your crossed fingers failed you, because it turns out that a third parameter was added to main some time later, and it conflicted with your Windows-friendly version.

Suppose you managed to convince Dennis not to allow that three-parameter version of main. You still have to come up with those first two parameters, which means that every program's startup code needs to contain a command line parser. Back in the 16-bit days, people scrimped to save every byte. Telling them, "Oh, and all your programs are going to be 2KB bigger" probably wouldn't make you a lot of friends. I mean, that's four sectors of I/O off a floppy disk!

But probably the reason why the Windows entry point was given a different name is to emphasize that it's a different execution environment. If it were called main, people would take C programs designed for a console environment, throw them into their Windows compiler, and then run them, with disastrous results.